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.
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.
For "sudo -n" we only want to reject a command if user input is
actually required. In the case of PAM at least, we may not need
to interact with the user. Bug #956, GitHub issue #83
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
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 setting is an argument to the sudoers plugin, similar to how
sudoers_file, sudoers_mode, sudoers_uid, etc. are implemented.
The default value is true.
This adds audit plugin support to the sudoers module, currently
only used for accept events. As a result, the sudoers file is now
initially parsed as an audit plugin.
In the past we've relied on the various .c files to include the
system headers that define types that the sudo_*.h headers require.
This is fragile and can cause issues when includes get re-ordered.
This is used for PAM authentication to make sure pam_end() is called
via sudo_auth_cleanup() when the user authenticates successfully but
sudoers denies the command. Debian bug #669687
