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.
Use strlen(), not sizeof(), on "problem parsing sudoers" since it
is a tranlated string and not a constant.
This was caught by the existing overflow checks.
For command_matches_all() we should only perform the setid check
if the file exists and intercept is enabled. Otherwise, we can end
up returning an error if the fully-qualified command does not exist.
Fixes a regression introduced in sudo 1.9.0 with the support for
digests in conjunction with "sudo ALL".
We don't check the owner or permissions on a sudoers file that is
specified as an argument to visudo by default. However, the owner
and mode of files included via @includedir were still checked. This
commit makes the owner and permissions checks for filed included
via @includedir follow the same as for the original sudoers file.
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.
It is easier to maintain these tests in script form. The output
now more closely matches that of the other tests. The harness
script can be invoked directly and supports running specific tests.
This means we no longer display the lecture unless the user is going
to enter a password. Authentication methods that don't interact
with the user via the terminal don't trigger the lecture.
Previously, the warning was displayed when a user was not in the
sudoers file, or was present but not listed for the local host.
The new behavior is to display the warning if a command is denied
and mail is sent to the administrator. Whether or not mail is sent
is controlled by the "mail_*" flags in sudoers. The warning text
is now "This incident has been reported to the administrator." which
is hopefully less confusing. The message will not be printed if
either the "mailto" or "mailerpath" sudoers settings are disabled.
