[apparmor] Patching a system profile for a specific user

Sat Jan 11 12:14:45 UTC 2020

On 1/10/20 2:07 PM, Sylvain Leroux wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> 
> Hi everyone,
> 
> I'm a seasoned Linux administrator but I have little prior experience
> with AppArmor.  FWIW, I already have asked this question on the
> SuperUser StackExchange web site this afternoon [1],  but it received
> little interest, and I now have little hopes to have an answer there.
> 
> Our Linux Debian boxes have a standard policy for the Thunderbird
> email client in `/etc/apparmor.d/usr.bin.thunderbird`
> 
> One user needs Thunderbird to have read access to the files stored in
> his `${HOME}/signature.d/` folder. Is there a way to create a
> user-specific profile that _includes_ the default profile settings,
> but granting extra access the the needed files? I didn't find any
> reference about that particular use case, and my first attempts were
> unsuccessful. But I can't say if my syntax was wrong, of if this
> wasn't possible at all. Here what I tried:
> 
> 
> ```
> $ cat "${HOME}/.apparmor.d/usr.bin.thunderbird"
> 
> #include </etc/apparmor.d/usr.bin.thunderbird>
> 
> profile thunderbird @{thunderbird_executable} {
>   owner @{HOME}/.signature.d/** r,
> }
> 
> $ sudo systemctl restart apparmor
> 
> ```
> 
> 
> This doesn't seem to change anything. At such point I don't think the
> user-specific profile is read at all. 
> 

correct. user defined policy is not yet supported, but is on the road map,
and is something we have been working towards, several of the necessary
parts like policy namespace, and stacking have landed but there is
still some work to be done.

> Could you help me fixing that?

maybe. It depends on what is considered an acceptable solution to you.
Unfortunately atm this is not nice and simple to do, the single rule
suggested in the other email is the easy solution atm.

There are a couple different approaches to this, and currently all of
them require a sys admin defined policy, and a way to attach the
policy to the user.

The basic idea is that you create a policy namespace(1) for the user
who has special policy and place the user into that namespace.

A choice will also have to be made whether regular system policy
should apply to the user, and whether profile stacking(2) can be used
or not.

This is all clear as mud I am sure. So a short explanation of each

1. Policy namespaces
The policy namespace allows for you to have different version of policy
loaded at the same time. This could be different versions of a profile
like thunderbird or an entirely different set of profiles. Policy
namespaces are hierarchical. There is the root namespace that system
policy is loaded into.

Policy namespaces have a name that currently always begins with a
: and ends with : or :// (they can be used interchangeably so it
doesn't matter which you use)

eg.
  :user_tom:thunderbird
  :user_tom://thunderbird

Currently policy namespaces have the limitation that once a process
enters the namespace, the parent namespace is not visible to tasks
within the namespace. The name of the namespace is not visible either
so to the tasks within the namespace they will just see

  thunderbird
instead of
  :user_tom:thunderbird

admin tasks in the parent namespace can see every thing. This works
well for system containers like LXD, but there are situations where
this isn't what you want (yes we have plans to fix this).

I should note that each policy namespace gets it own unconfined. So
that tasks can be put into a different namespace and still be
be unconfined, and will attach to that policy namespaces profiles.

So how do we create a policy namespace and put a task into it?

You can create a policy namespace manually using the shell using
mkdir (1), or the best solution for you, by loading policy into it.

Creating a profile with the below template in /etc/apparmor.d/
will create the namespace and load the profile to it as part of
regular policy load.

:ns1:thunderbird @{thunderbird_executable} {
   ...
}

to start a task in the namespace you can use aa-exec

aa-exec -p :ns1:thunderbird -- thunderbird

this is of course not what you want but is building toward it.

2. Policy stacking

Policy stacking allows a task to be confined by multiple profiles
at the same time. When introspecting the label (confinement) of a
task it is identified by the sequence of //&

eg.

  log_admin//&thunderbird

stacking can be used in conjunction with policy namespaces to allow
some tasks to be confined by both the system policy and by the a
custom user policy at the same time.

This does have a limitation however in that if the system has a
thunderbird policy and the user has a thunderbird policy they will
both get applied at the same time.

  thunderbird//&:user_joe:thunderbird

when profiles are stacked, you get the boolean intersection of
permissions so your user won't get the extended permissions from
:user_joe:thunderbird because the system thunderbird profile
doesn't have them and will end up denying them.

You can play with stacking by using aa-exec

eg.

  aa-exec -p unconfined//&:user_joe:thunderbird -- thunderbird

3. Placing a user into the namespace.

You have 2 ways to put the user into the namespace automatically,
you can use pam_apparmor(3) or modify the users shell.

The use of pam_apparmor is not currently recommended because any
thing that calls the pam stack must be confined by a profile with
all the transitions defined as hats. This means for most use cases
total system confinement. You can see more details by looking at
the referenced wiki page.

The other solution is to modify the users shell to a custom
shell that wraps the aa-exec command. Something like

  $ cat /bin/special_bash
  #! /bin/bash

  /usr/bin/aa-exec -p :ns1:unconfined -- /bin/bash

And then modify /etc/passwd for that user, so using the user
foo as an example you would have

  foo:x:1001:1001:,,,:/home/foo:/bin/special_bash

4. Putting it all together

You now have two choices, either using stacking + namespaces OR
just namespaces.

4.1 Just namespaces

make copies of all the system policy and modify it to use a
policy namespace.

You set up the user transition as above.

This approach has the issue that ipc rules may fail because
profile and :ns1:profile are not recognized as being the same

4.2 Stacking + namespaces

You will need two user namespaces a default namespace for most
users and a custom namespace for the modified profile.

Move the thunderbird profile into the default namespace and
then copy that into the custom namespace. Modify both profiles
giving them unique namespace names. Here I will just use "default"
and "custom". But you can choose what ever you want

:default:thunderbird @{thunderbird_executable} {
   ...
}

:custom:thunderbird @{thunderbird_executable} {
   ...
}

make your modification to the :custom:thunderbird profile.

Setup two wrappers similar to setting up the namespaces

  $ cat /bin/default_bash
  #! /bin/bash

  /usr/bin/aa-exec -p :default:unconfined -- /bin/bash

  $ cat /bin/custom_bash
  #! /bin/bash

  /usr/bin/aa-exec -p :custom:unconfined -- /bin/bash

and change all users shells to use default_bash or custom.

Yep its gross. Sorry.

So what are we doing to fix this? The are multiple improvements
coming that will make this a lot easier. I can't commit to a
time frame for any of them.

1. Updated pam_apparmor that will be able to use newer apis.
   Allowing you to configure setting up namespaces for users.

2. Opening up profile loads to users. Users will only be able
   to load policy to a user specific namespace. And policy
   will have to be setup to allow it, but user defined policy
   is coming. Hopefully this year.

3. A user attachment conditional, allowing you to define system
   profiles for different users.

when combined this will provide a lot of flexibility with how
to deal with stuff like this.

(1): https://gitlab.com/apparmor/apparmor/-/wikis/AppArmorNamespaces
(2): https://gitlab.com/apparmor/apparmor/-/wikis/AppArmorStacking
(3): https://gitlab.com/apparmor/apparmor/-/wikis/pam_apparmor

> 
> Thanks a lot,
> - - Sylvain Leroux
> 
> 
> 
> [1]
> https://superuser.com/questions/1516181/configure-apparmor-to-allow-file-access-on-a-per-user-basis
> 
> - -- 
> - -- Sylvain Leroux
> - -- sylvain at chicoree.fr
> - -- http://www.chicoree.fr
> -----BEGIN PGP SIGNATURE-----
> 
> iQJIBAEBCAAyFiEEl5bRd1eLmzy/wTZWq1gfHR9hxSIFAl4Y9bUUHHN5bHZhaW5A
> Y2hpY29yZWUuZnIACgkQq1gfHR9hxSITsQ/9E2fDh2LtM/rlkKhE8oIkeWQCvv0b
> d91TWmvVp5N0XFtrxSWrLRGrQTuwIhYGUPQWn7FX5M/9yiqO2ZdxTcy/VZ5WK5mE
> 16/QHziU8HwLL+4eGZAHLI5Q81Fjq2Zx2Lyin21r6tiQn/Tc1CMS5WqnkUqMUZ3V
> JjRXmQwfg+VAzsY8w+lDVK1iFRNzcGvcCbiEcDSzXsB+QfEA5R0xtTB5Z63+U7Kw
> z2qG1X8SpcIJMgg7M7v6x2wl8LKNEnb/PoXfdX+HV0KBh+IRipJk/sgCyuJs19cd
> hgdCtGVbOKxM+daTZnH6DKVWnCujaTTo5kBVPduuDCFyBT7iP1hUwe08NnC8rmLc
> x6W+gsQ6YZ1UQo/36iHXUrF+tohsSn0JvJR4yu1XEb93jthnnZeWFj+naX/DAbAa
> m7fAqgUwHMyETz3xIRxwdKTc/wQOh+2rVf83JWfuIyV0HauK9JMsXjS5dKZYH3fp
> iHA6mZmOPw8ZlWcSzOP7JYbIJSd/E/G6mudLL8CRGhCshuX+dXnLBDJDZJVzqch6
> 6hGKShK1fyGID5NU2iEmuyeo+KgpSHBu2AY2uhqmNfPEwKeOPyF6YzU9NNzjCqh6
> O3T6uQ1rUFslj9KNMvuCquvIJr3M79rykLkT6pnyTkBaj72NnA4M/hVNi2IrSuAz
> CZ+tQnWZZn3GGls=
> =5AQW
> -----END PGP SIGNATURE-----
> 