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.
For compat binaries, use the upper 32-bits as the next word instead
of calling ptrace(2) to get it. This reduces the number of ptrace(2)
calls when reading argv and envp for compat binaries.
We align the start of the string table to a word boundary to help
prevent overlap when writing the pointers. However, the actual
strings themselves don't need to be aligned.
In compat mode, if argc is odd, writing the last pointer of argv will
overlap with the address of argv[0], so leave an extra word in between.
Also remove incorrect comments about PTRACE_PEEKDATA unaligned access.
If we try to use the compat word size we can end up in a situation
where a subsequent PTRACE_POKEDATA overwrites part of what we've
already written since it always writes in sizeof(long) units.
We need to define the ptrace register struct ourselves for the
32-bit system since there is no good way to get it from the system
headers. Currently only implemented for x86_64 and aarch64.
