On 5/31/19 2:59 PM, John wrote:
Because when no-new-privs landed it was mandated that the LSMs not over ride
it. No new-privs is not part of apparmor but the broader kernel, and was
provided as a way to for a task to lockdown privileges to the current set.
prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
It was added with seccomp (3.5) so that the task could do setup and then lock
its sandbox/security env down. At the time the LSMs were told it should apply
to them as well. With seccomp use expanding and systemd now setting it this has
unfortunately caused several problems for LSMs and selinux successfully added a
setprivs ability that allows them to selectively override. AppArmor does
currently allow transitions under no-new-privs but only when the transition is
provable a subset of the tasks confinement (3.5 - 4.12 unconfined is allowed to
transition to a profile, 4.13 - 4.16 is limited to strict subset of current
confinement, basically you can extend a profile stack, 4.17 - 5.2 to a subset
of confinement at the time nnp is set). We do have plans to add our own ability
to have a permission to override no-new-privs but that has not landed upstream
yet.
>/Running pstree at the same time as apt shows the following order:
systemd, sshd, sshd, sshd, bash, sudo, bash, apt, gpgv (and http,
http), gpgv />//>/root at 1546-w-dev
<https://lists.ubuntu.com/mailman/listinfo/apparmor>:/etc/apparmor.d#
cat usr.lib.apt.methods.gpgv />/profile usr.lib.apt.methods.gpgv /usr/lib/apt/methods/gpgv
flags=(complain) { />/ #include <local/whitelist> />/} />//>//>/root at 1546-w-dev
<https://lists.ubuntu.com/mailman/listinfo/apparmor>:/etc/apparmor.d#
cat usr.bin.apt_key />/profile usr.bin.apt_key /usr/bin/apt-key flags=(complain) { />/ #include <local/whitelist> />/} />//>//>/Have I ran into this?
https://lists.ubuntu.com/archives/apparmor/2018-November/011846.html />//
unfortunately, yes. I can point you at a test kernel for the nnp override but,
I will need
to get up a userspace that can work with it. I'll see what I can do this
weekend.
if I use "/** px" for init-systemd and all other discrete profiles, am I
correct in concluding that each child process does a domain transition?
I.E. using that pstree output from above, by the time gpgv executes, the
following transitions happen:
unconfined -> init-systemd -> usr.sbin.sshd -> bin.bash -> usr.bin.sudo
-> bin.bash -> and so on?
Does the nnp issue occur after a certain depth is reached, or is
something else triggering this? What I don't get is that each process
should have the same profile permission requests. Are there additional
permissions I need to add to my "whitelist" file?
Also, if nnp locks things down, does that mean ux only works if the
parent process is itself unconfined? I.E. this isn't possible:
unconfined -> px -> ux? If that is possible, maybe I could somehow get
apparmor to initially transition to ux before px?
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
