[apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...

[John Johansen]

On 6/3/19 1:40 PM, Ian wrote:
> 
> 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?
> 
Hrmmm I would not say a transition is guaranteed, rather a profile lookup is guaranteed. That lookup may very well result in the same profile as the current confinement (dependent on how attachments are defined). Other than that semantic yes.


> Does the nnp issue occur after a certain depth is reached, or is something else triggering this? 

A task invoking the no_new_privs prct

https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt

> 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?

I am not sure I understand the question. But maybe the explanation will help

For apparmor exec transitions you only need to consider the tasks current confinement. A parents confinement only matters in that its confinement is used inherited at time of fork and used at time of exec. Each profile has full control over how transitions are done so its local rule, eg.

  /** px,

is used to determine what transition, if any, should be done. px transitions will evaluate the best profile transition for the currently loaded profile set based on the attachment conditionals.

It is possible that a single profile will cover multiple different executables or be reused multiple times through and exec chain, like you have above.

However you are free to define your policy to do something else, via ix, ux, cx, and -> based transitions.

With policy namespaces it is possible to have different sets of profiles with different attachment sets. You can keep some exec hierarchy with children profiles, etc.

> 
> 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?
> 

The ux exception for nnp only works based on the current confinement at the time of the exec. So if the task doing the exec is unconfined it can transition to any profile. It does not depend on the parent tasks confinement beyond that in the fork exec model the forked child inherits its parents confinement at the time of the fork before doing the exec, but if the parent changed its own confinement between the fork and the childs call to exec the parents change of confinement would not affect the child's decision at exec.

Currently when a task is under nnp once a task has transitioned from unconfined to a profile it is impossible to go back to being unconfined. The nnp override (that has not landed) would make doing that possible.

Another potential solution that is currently available would be to use stacking and maybe use of apparmor namespaces, with 4.17+ kernels. This would allow you to keep a fixed confinement at the time of nnp, but have further transitions. It would look something like

  init-systemd//&usr.sbin.sshd -> init-systemd//&bin.bash -> init-systemd//&&usr.bin.sudo -> init-systemd//&bin.bash

In which case the confinement is guaranteed to be a subset of the confinement at the time of nnp (init-systemd) and the rest of the profiles in the stack.

however I don't think this is something you would want to do all the time and stacking currently can not be conditional upon nnp. Which makes this kind of setup difficult if not impossible to currently work with directly through apparmor policy, but it might be possible to make this work by having systemd set the apparmor confinement in the systemd unit with

AppArmorProfile=<confinement>

https://gitlab.com/apparmor/apparmor/wikis/AppArmorInSystemd

that way systemd can set the initial confinement and stack for the services it sets nnp on and apparmor policy does not have to conditionally respond to nnp