This means that _PATH_SUDO_CONF, _PATH_SUDOERS, _PATH_SUDO_LOGSRVD_CONF,
and _PATH_CVTSUDOERS_CONF can now specify multiple files. The first
file that exists is used.
This splits the code to find the command, perform a sudoers lookup,
ask for a password as needed, and perform post-lokup checks out
into sudoers_check_common(). The old sudoers_policy_main() has
been replaced by sudoers_check_cmnd() (called by sudoers_policy_check()),
sudoers_validate_user() (called by sudoers_policy_validate()) and
sudoers_list() (called by sudoers_policy_list()). The list_user
lookup is now performed in sudoers_list().
The value of user_args should not contain the command to be run in
"sudo -l command args", only the arguments of the command being checked.
This restores the pre-1.9.13 behavior. GitHub issue #249
Previously there would be one email for the open failure and a
separate one describing the parse error. Now a single email message
contains everything.
We use "--" to separate the editor and arguments from the files to edit.
If the editor arguments include "--", sudo can be tricked into allowing
the user to edit a file not permitted by the security policy.
Thanks to Matthieu Barjole and Victor Cutillas of Synacktiv
(https://synacktiv.com) for finding this bug.
privs. Previously, only root or a user with the ability to run any
command as either root or the target user on the current host could
use the -U option. For "sudo -l [-U otheruser] command", NewArgv[0]
is now set to "list" (just like "sudo -l") and the actual command
to be checked starts with NewArgv[1].
If log_input is set, log_{stdin,ttyin} will be set as well.
If log_output is set, log_{stdout,stderr,ttyout} will be set as well.
This provides more fine-grained control over I/O logging and makes it
possible to disable logging piped or redirected intput or output.
This fixes a bug where MODE_POLICY_INTERCEPTED was set too early
if the intercept option was set globally in sudoers. It should
only be set after the original command has executed.
sudoers now supports an APPARMOR_PROFILE option, which can be specified
as e.g.
alice ALL=(ALL:ALL) APPARMOR_PROFILE=foo ALL
The line above says "user alice can run any command as any user/group,
under confinement by the AppArmor profile 'foo'." Profiles can be
specified in any way that complies with the rules of
aa_change_profile(2). For instance, the sudoers configuration
alice ALL=(ALL:ALL) APPARMOR_PROFILE=unconfined ALL
allows alice to run any command unconfined (i.e., without an AppArmor
profile), while
alice ALL=(ALL:ALL) APPARMOR_PROFILE=foo//&bar ALL
tells sudoers that alice can run any command under the stacked AppArmor
profiles 'foo' and 'bar'.
The intention of this option is to give sysadmins on Linux distros
supporting AppArmor better options for fine-grained access control.
Among other things, this option can enforce mandatory access control
(MAC) over the operations that a privileged user is able to perform to
ensure that they cannot privesc past the boundaries of a specified
profile. It can also be used to limit which users are able to get
unconfined system access, by enforcing a default AppArmor profile on all
users and then specifying 'APPARMOR_PROFILE=unconfined' for a privileged
subset of users.
The hook can be used to log parser errors (sudoers module) or keep
track of which files have an error (visudo).
Previously, we only kept track of a single parse error.
When logging terminal input, if log_passwords is disabled and any
of the regular expressions in the passprompt_regex list are found
in the terminal output, terminal input will be replaced with '*'
characters until a newline or carriage return is found in the input
or an output character is received.
Since "cd" is a shell built-in command it cannot be run directly
via sudo. The user either needs to spawn a shell via "sudo -s"
or use the -D option to run a command in a specific directory.
There is no case where we should fail to find an editor just because
the values of EDITOR, VISUAL and SUDO_EDITOR are unavailable. Both
sudoedit and the "env_editor" sudoers setting are documented as
falling back on the hard-coded list of editors in the "editors"
sudoers setting. Bug #1000
