[apparmor] AppArmor and /etc/

[John Johansen]

On 11/25/2017 08:16 AM, intrigeri wrote:
> Hi,
> 
> (reposting here with Marco's permission)
> 
> Marco d'Itri:
>> I like the idea of enabling AppArmor by default in Debian,
> 
> Cool :)
> 
>> but I have 
>> some concerns about its usage of /etc/: being able to support systems 
>> with an empty /etc/ directory is a goal for containers and stateless 
>> servers, so it is seriously annoying that we adopted something which 
>> depends on a lot of new files in /etc/.
> 
> I understand and I totally agree.
> 
>> 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

the /etc/apparmor.d/ location is just the upstream project default
as its generic and should work on all distros, where /usr/ may not
be available during early boot etc.

Ideally with the policy versioning rework the location of the text
policy becomes less important as it will no longer needed in early
boot as only the binary version of policy will be used.

> I'm not sure, but I *guess* that's because of:
> 
> 1. History: shipping default configuration in /etc has been
>    a long-established practice.
> 
>    I much prefer the systemd approach, with default config shipped in
>    /usr and full support in all tools to override parts of it locally
>    (`systemctl edit', `systemctl cat', etc.).
> 

This is the reason

> 2. Our local override mechanism is incomplete
> 
>    Due to limitations in the policy language, some (rare) kinds of
>    rules cannot be overridden without editing the original rule, e.g.
>    https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/451422
> 
> 3. Our local override mechanism is Debian-specific
> 
>    AFAIK the "#include <local/$profile>" thing is the norm only on
>    Debian and derivatives. Christian, what do you do at OpenSUSE?
> 
Local over rides are more of packaging issue, and never played into
the original decision. If you wanted to override something you would
modify the profile text.

>> Why is /etc/apparmor.d/cache/ not somewhere else?
>> If the reason is to not have a dependency on /var/ being mounted
> 
> I bet this is exactly the reason (we want to load policy ASAP in the
> boot process), but I've been involved in this community only since
> 2013 so I can't tell for sure.
> 

right, /etc was one of the few places that was guaranteed to be
available in early boot. Its really not the right place for the
binary policy files but under old filesystem layout specs there
really wasn't a good place.

>> then please ship a proper CACHEDIR.TAG file to help backup software.
> 
> I didn't know about this. For the record, this is specified in
> http://www.brynosaurus.com/cachedir/spec.html and supported e.g.
> by GNU tar's --exclude-caches option.
> 
> This sounds like a great suggestion to me!
> 
> It seems that /etc/apparmor.d/cache is created by the Debian
> packaging, so presumably I could easily ship a CACHEDIR.TAG file
> in there.
> 
> What do others think?
> 

hrmmm, maybe cache files aren't always generated locally and we
have had cases of shipping precompiled policy. Some parts of the
policy versioning work are also going to make this easier, allowing
for multiple cache versions. Its another aspect to discuss as we
do the policy versioning work.

Its certain is something that a distro could decide setting regardless
of what the upstream project does.

>> If there is no "#include if exists" directive that could be used for 
>> the /etc/apparmor.d/local/* files then I believe that maintainers should 
>> be encouraged to ship empty files instead of each repeating the same 
>> "you may modify this" comment (currently we have both styles).
> 
> I don't think we have "#include if exists".
> 
We sort of do. If you do a directory based include, like
  include <local/>

files are only included if they exist, and there is no failure even if
the directory is empty.

where this fails is you basically need an empty dir per profile
unless the files are to be shared.

We don't currently have a file specific include that won't fail if
the file doesn't exist, but its an extension we could add.


> If we had one, then I think we should indeed drop these files
> entirely. There's a README in that directory, that's just as
> discoverable by users as these local override files, and would even be
> more discoverable if it was the only file shipped in
> /etc/apparmor.d/local/ by default. What do others think? If you agree
I would disagree that its more discoverable, but its not like you can't
have a comment pointing to it in the profile.

> it's a good idea, then I'll file a bug report on LP about adding one
> such directive (and will try to find someone whose C skills are better
> than me, in order to implement it).
> 
yes allow a condition if it exists include makes sense

> Until we have one such directive, then I think we should indeed DRY,
> ship empty files in there, and rely on the README being the only
> non-empty file by default in /etc/apparmor.d/local/.
> 
> In most cases this text is generated by dh_apparmor
> (/usr/share/debhelper/autoscripts/postinst-apparmor) so it's easy to
> fix this at the distro level: upload dh-apparmor, wait for all
> reverse-build-deps to be rebuilt, and at some point request binNMUs to
> get rid of the long tail. I can do the dh-apparmor upload. Marco,
> would you like to handle the next steps?
> 
>> Do we need an apparmor minipolicy?
> 
> This might be a little bit premature: I would start with improving the
> existing doc for package maintainers on the Debian wiki, and once we
> have enough of it and well-defined best practices, I'm happy to encode
> them in a more authoritative place.
> 
A minipolicy is something to work towards, its inline with moving policy
into the application packaging, possibly even a result of that work