Automatically ensure we don't accept passing arbitrary arguments when elevating privileges via sudo

Too often, when we edit our sudo configuration, we forget to forbid passing arbitrary arguments (which can be done, in a command specification, either by specifying the allowed arguments, or by ending the command with "" to express that no argument is allowed). See the related issues for a few recent examples. This matters for example when starting GTK apps: in that case, being allowed to pass arbitrary arguments gives arbitrary code execution to the caller, in the environment that has elevated privileges.

Maybe we could have automated tests that attempt to run the simple reproducers for past vulnerabilities, and fail. Success = I see the sudo prompt asking for a password (as opposed to being allowed to do whatever I'm asking with no password). Hint: -n.

We can make this issue public once the newly reported vulnerabilities in this area have been patched.

Scope:

• Avoid regressions in this area for existing sudo config & existing programs.
• Don't write a new sudo config parser.
• Users: amnesia, tails-persistent-storage, tails-upgrade-frontend: worth it to do others?

Alternatively: check output of sudo --list (not super machine-readable actually) or libraries that parse sudo config.

Idea:

• Cucumber scenario that:
  • demands that for every file in /etc/sudoers.d, there is a file encoding an automated test; it's expected and assumed that this automated test verifies that the sudo config does not allow running the relevant program(s) with arbitrary arguments
  • runs these tests

Expected cost/benefit: Low Hanging Fruit

Generate sudo config from YAML

Alternatively, possibly better, generate our sudo config from YAML, making accepting arguments opt-in and requiring a justification for it. Example:

- "common"
  - raw_config:
    - "Defaults: XXXX"
- "Upgrader"
  - raw_config:
    - "Default!IUK: env_keep_=XXX"
    - reason: "XXX"
  - exec:
     - user: t-u-i
     - command: /usr/local/bin/moo
     - as: root
     - arguments: any
     - reason: "please prove this is risky, what can possibly go wrong?"

Notes:

• We should minimize how much we use raw_config: it allows bypassing the requirement for a justification. In particular, we should not use Cmnd_Alias: instead we should duplicate the corresponding exec sections.