Previously, check_user_runcwd() would return true if the runcwd
matched the user's cwd, even if sudoers specified a different one.
The user-specified runcwd was ignored but it is better to error out
in this case. It is now also possible to use "sudo -D" with the
directory specified in sudoers.
The lack of setting to NULL is a holdover from when command_info was a local variable and not a global one. However, we given how other global variables are set to NULL, it is best that we do the same here to avoid potential issues should sudoers_policy_store_result be called again after the first time failed, otherwise we could get a double-free.
We just need a way for the policy (and visudo) to override the
default sudoers path. This adds a getter to be used in file.c when
sudoers is first opened.
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().
This change introduced in sudo 1.9.13 is not actually needed. The
"list" pseudo-command checks are performed via runas_matches_pw()
which does not use runas_pw. GitHub issue #248
If sudo calls execve(2) directly the accept info will not be sent.
We also need the sudo front-end to wait until the command finishes
to send the exit status.
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.
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.
Having "sudo ALL" permissions in no longer sufficient to be able to
list another user's privileges. The invoking user must now have
"sudo ALL" for root or the target user.
GitHub issue #134
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.
This makes it possible to use a different PAM configuration for
when "sudo -A" is used. The main use case is to only use PAM modules
that can interact with the askpass program. GitHub issue #112.
The front-end uses this to decide whether or not to enable SELinux.
If selinux-rbac is true _or_ if it is not present and selinux_role or
selinux_type are set, SELinux support is enabled.
Previously, SELinux support was only enabled if a role was specified.
Now that sudoers free old values of NewArgv and command_info the
fuzzer needs to reset those values. Otherwise we end up with
stashed values that have already been garbage collected.
By default, sudoers will not require authentication of commands run
via an intercepted session. To require authenticaton of subsequent
commands, enable intercept_authenticate in sudoers.
This causes "intercept" to be set to true in command_info[] which
the sudo front-end will use to determine whether or not to intercept
attempts to run further commands, such as from a shell. Also add
"log_children" which will use the same mechanism but only log (audit)
further commands.
