[apparmor] AppArmor and /etc/

[Jamie Strandboge]

On Mon, 2018-01-08 at 02:17 -0800, John Johansen wrote:
> On 01/07/2018 07:22 AM, intrigeri wrote:
> > Hi,
> > 
> > … and sorry for the delay!
> > 
> > John Johansen:
> > > On 11/25/2017 08:16 AM, intrigeri wrote:
> > > > Marco d'Itri:
> > > > > Why are policies generally installed in /etc/ and not in 
> > > > > /usr/share/apparmor/?
> > > 
> > > It actually depends on the distro, eg. ubuntu touch moved the
> > > text
> > > policy to /var/lib/apparmor/ and the cache to /var/cache/apparmor
> > 
> > Interesting!
> > 
> > Then I'd like to try moving the cache to /var/cache on Debian and
> > Ubuntu to start with. This seems like a realistic goal for the
> > Buster
> > development cycle.
> > 
> 
> I'm not sure /var/cache is the right place, while the data certainly
> can be regenerated, its getting to the point that we should stop
> referring to it as cache. Its the binary version of policy and there
> are several cases where its required and falling back to regeneration
> will result in failure.
> 
> With that said /var/cache isn't terrible and is better that /etc/
> for most modern linux systems. I will also throw in the proviso that
> I don't mess with this area much and Jamie or Steve are better people
> to comment on this.
> 
It continues to be a tricky problem. I think mostly we really need to
make sure the binary policy is on the same partition as the text
policy. If we start thinking of it as binary policy, perhaps we can
instead put it in /lib. Eg, /lib/apparmor/policy. FHS adherents will
argue that this isn't the right place, but /etc is no better and the
FHS doesn't handle early boot well at all (this is presumably why
system uses /lib/systemd/system).

> 
> > Apart of the early boot dependency issue (which I think is not
> > really
> > one in practice as we run After=local-fs.target on Debian), is
> > there
> > any foreseeable problem I should be aware of?
> > Perhaps the Ubuntu folks have some insight to share based on their
> > past experience doing similar things?
> > 
> 
> the early boot dependency was a real issue that we did run into. But
> with the systemd rework I am not so sure it is anymore.

It is still an issue for very early boot, which would be the case with
full system policy. Note that in Debian/Ubuntu we use 'After=local-
fs.target', but we also have 'Before=sysinit.target' and so we aren't
currently dealing with this use case well since apparmor is going to
run in parallel with other early init processes.

> > Moving the text policy itself seems more involved and I doubt it'll
> > happen during the Buster development cycle.
> > 
> 
> meh, that is actually pretty easy too. You have to leave the
> /etc/apparmor/parser.conf in place but you can use it to override
> the defaults.
> 
> It only becomes a mess when you do a split policy like Ubuntu did
> with policy in /etc/ and in /var/lib/

For context, Ubuntu did this to separate system policy from click/snap
policy.

Note that Ubuntu can now remove /var/lib/apparmor/profiles since click
and snapd v1 are gone in Ubuntu. snap v2 manages its own profiles but
puts the cache in /var/cache/apparmor so Ubuntu would still want to
figure out how to load the caches from there.

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20180205/3643dd81/attachment.sig>