[apparmor] Apparmor full system policy - Dracut module?

[John Johansen]

On 1/27/19 12:49 PM, intrigeri wrote:
> Hi Jacek,
> 
> Jacek:
>> What should the correct code of the Apparmor policy module look like to
>> Dracut?
> 
> I'm not aware of any actual implementation of what this document

nothing released, there was a wip and I have rolled an initrd startup
by hand a few times. I have done nothing with drcut as this work was
more around supporting ubunut phone image builds.


> suggests, but had I to write it, I would start there:
> 
>   https://gitlab.com/apparmor/apparmor/blob/master/parser/rc.apparmor.functions
> 
Well it depends on what release you want this to work on.

If you are targeting 2.13 or newer, I wouldn't instead I would point you to the
out of tree aa-load (its not complete yet) and the library function
aa_kernel_interface_load_policy.

Those will load cache policy, directly without the whole need to call out to
the parser, and compile policy and the extra constraints that places on
startup.


> … keeping in mind that dracut starts systemd very early, and most of
> the dracut code is run by systemd units as part of initrd.target, so
> instead of a dracut module, you could probably load AppArmor policy
> from a systemd unit that's WantedBy=initrd.target. See for example
> how policy is loaded in Debian post-initramfs:
> 
>   https://salsa.debian.org/apparmor-team/apparmor/blob/debian/master/debian/apparmor.service
> 
> … which uses:
> 
>   https://gitlab.com/apparmor/apparmor/blob/master/parser/apparmor.systemd
> 
> … which delegates all the heavy lifting to
> parser/rc.apparmor.functions mentioned above.
> 

If you want to be able to do total system confinement (eventually)
copying selinux is the way to go. Dracut will either need to copy the
cache files into the initrd/ramfs.

And then systemd can load them.

Basically the plan has been to split policy load into an early load
phase that only touches cache, no need for text policy, includes,
compiler and all their dependencies, and a later phase similar to the
current apparmor init, that makes sure all the time stamps are good
and will recompile/reload updated policy if it needs to.


>> Question about Apparmor full system policy.
>> I mean loading all Apparmor policy profiles, not just Init.
> 
> Now I'm confused. May I ask what you're trying to achieve?
> Is it really full system policy, i.e. *all* processes are confined?
> Or "only" early loading of policy?
> 
Well one requires the other. You can do early policy loads with
current policy and avoid the problems with say dns starting before
apparmor so it is unconfined.

Total system confinement will require an early policy load, but
is more an issue of policy development. Well that and fixing some
apparmor issues around namespacing.

I wouldn't recommned to doing total system confinement yet. Its
not what it should be yet. You can do it, but apparmor isn't quite
ready to support it.

With that said early policy load is a good first step, and would
fix some of the problems we have today with certain services starting
before apparmor.