The replacement execve() function was passing the global environ
to exec_wrapper() instead of the envp parameter. This caused the
command to be run with the wrong environment on AIX systems, and
possibly others, when intercept or log_subcmds was enabled.
Bug #1030.
It is not possible to change the syscall return value on MIPS
so we cannot support full intercept mode.
Another complication on MIPS is that if a system call is invoked
via syscall(__NR_###), v0 holds __NR_O32_Linux and the real syscall
is in the first arg (a0) and other args are shifted by one.
- Document the AppArmor userspec option in the sudoers man pages.
- Add information about the --with-apparmor build configuration option
to INSTALL.md.
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.
Define a new sudo setting, `apparmor_profile`, that can be used to pass
in an AppArmor profile that should be used to confine commands. If
apparmor_profile is specified, sudo will execute the command using the
new `apparmor_execve` function, which confines the command under the
provided profile before exec'ing it.
Add a new build flag, --with-apparmor, that builds sudo with AppArmor
support. Modify the build script for Debian and Ubuntu to enable this
flag by default.
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.
When ptracing a process, we receive the signal-delivery-stop signal
before the group-stop signal. If sudo is running the command in
the same terminal, we need to wait until the stop signal is actually
delivered to the command before we can suspend sudo itself. If we
suspend sudo before receiving the group-stop, the command will be
restarted with PTRACE_LISTEN too late and will miss the SIGCONT
from sudo.
It should also work on s390 but this has not been tested.
I have not added a compat mode to trace 31-bit binaries on s390x
due to the lack of a test system.
Use PTRACE_SETREGSET with NT_ARM_SYSTEM_CALL instead just like we
would for a 64-bit binary. Newer Linux headers don't define
PTRACE_SET_SYSCALL for aarch64.
Mips is a bit different in that most Linux distros appear to use
the n32 ABI on 64-bit CPUs. We don't currently support tracing a
64-bit binary from a 32-bit sudo. We could suport tracing o32
ABI binaries in compat mode, though.
