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 -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
