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.
Since this flag isn't set, the sudo_mode variable gets invalidated and
running the 'sudo' command seems to error out with message
'sudoers_policy_check: invalid mode flags from sudo front end: 0x80001"'
The checks are now performed in the check_policy, list, validate
and invalidate functions instead of as part of the open function.
We can't perform the checks in open because we don't yet know what
operation is going to be performed.
