[apparmor] AppArmor and /etc/

[intrigeri]

Hi everyone,

Thank you all for helping me understand the landscape
we're discussing!

Meta: going through my backlog in order to plan my DebCamp. So I'm
trying hard below to scope the discussion more tightly, hoping there's
a conclusion I can implement later this month.

I'll reply to John and Jamie in a single email.

Jamie Strandboge:
> On Mon, 2018-01-08 at 02:17 -0800, John Johansen wrote:
>> On 01/07/2018 07:22 AM, intrigeri wrote:
>> > 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.

I see, interesting. So I think we are kinda discussing two different
things:

 - the cache as it is handled in Debian currently, i.e. never shipped
   by packages, always generated at runtime and updated as needed

   It may not be the best way to handle it in general (and it
   definitely is not an option at all for some specific use cases),
   but this is what we currently have in /etc on Debian/Ubuntu, and
   that I would like to move away this year.

 - a binary version of the policy, shipped to the end-user as-is, and
   that should be treated as essentially immutable; I'm also
   interested in this topic (e.g. because at Tails we want to include
   pre-compiled policy in the ISO at some point) but given where we're
   starting from in Debian, there's zero chance Debian Buster ships
   with this kind of data.

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

As you needed in the message I'm replying to, we run
After=local-fs.target, so I don't understand this part. I know you
have experience with shipping AppArmor policy (and the corresponding
cache) in /var so I'm sure I'm missing something. To enlighten me, can
you please explain why this is a requirement or point to examples of
why it's a tricky problem?

FTR, according to Christian [1], openSUSE uses /var/cache/apparmor/
for the profile cache and /usr/share/apparmor/cache/ for the
read-only/packaged version.

[1] https://gitlab.com/apparmor/apparmor/merge_requests/134

> 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).

For pre-generated binary cache shipped by the vendor or some other
software distribution mechanism, well, maybe, although /usr feels like
a better place and should work just as well once the initrd has
mounted it. Anyway, for now I'm personally more interested in tackling
the "cache in /etc causes all sorts of trouble" problem.

I see very little benefit in moving a dynamically generated/updated
binary cache from /etc to /lib (with 2.13, a new cache directory is
generated when you reboot on a new kernel or with a different feature
set). The main pros I can think of are mostly contingency measures
rather than real benefits, e.g. being nicer to software/processes that
assume that /etc contains mostly smallish plaintext files, or
software/processes that assume that tracking changes in /etc is
a meaningful way of identifying system config changes. That's already
something but to be frank, it's not enough to motivate me to drive
this change in the Debian packaging, hence my question above about why
/var would cause trouble :)

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

If I'm not mistaken, regardless of where we put the cache, those who
want to load policy in initrd will need to copy it there when they
generate their boot images, so I think that use case should not be
affected by whichever conclusion we reach on this thread.

Regarding Before=sysinit.thread, I'm not aware of any attempt, in the
Debian/Ubuntu ecosystem, to confine stuff that runs
Before=sysinit.target. I'm not surprised given
1. how small the attack surface is at this point of the boot process;
2. the kind of privileges most early boot services need.
If someone ever wants to confine some of those services anyway,
I suspect that loading the policy at initrd time will be much easier
than ordering apparmor.service correctly vs. other early
boot services.

So my current understanding is that moving the binary cache from /etc
to /var:

 - would solve some of the problems we have
 - would not help solve some of the other problems we don't solve yet,
   but would not necessarily make it harder either

So I'll this to my list of candidate work items for DebCamp, unless
someone explains me why "binary policy is on the same partition as the
text policy" should be part of the constraints of the
Debian/Ubuntu packaging.

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

Glad we're having at least part of this problem in common :)

Does snap v2 assume it has exclusive access to /var/cache/apparmor?
I hope not.

Cheers,
-- 
intrigeri