a) play with triggers TBD. So far triggers are for "if a file is placed in this directory, run a trigger". Maybe we can have other types, I haven't investigated further.
right triggers are interesting, but I think we need to do more investigation, and doubt they are something we can use for 25.10 b) disable all profiles What if the opt-in is in two steps: 1) install bin:apparmor.d; 2) enable the profile you are interested in this kind of violates the whole install and it works/enabled ethos. We don't need to enable ssh after install, etc. With that said, apparmor.d is also different than a service, and its current state it has known issues. c) a stupid idea, but maybe... Could we have a template systemd service for each profile, of the form [email protected], which would load just the specified profile? It would be a oneshot service, which would load just that %i profile (%i in the systemd unit file is how the profile would be referenced). But it would still need to be enabled somehow (can't think of a way to do it automatically when an application is installed), so it's like (b) above. And the existing mechanism to enable/disable a profile is simple enough already. this would actually be counter productive. It would slow down policy loads, and more importantly hinder some of the work around sharing of policy at compile and load. Eg. if we have pre-built policy and the compile has grouped several profiles together into a single atomic load set, we would still have a symlink for detection and load, but doing a single unit load, means the that the unit doesn't know if the other shared elements in the set are also going to be loaded, and that set will be reload by each systemd unit, that participates in the shared set. Which mean either potentially multiple loads of a large set of profiles, or not using cache sets which can be used to reduce policy size. Doing a single load allows detection of the shared load condition and early dedup (different than the dedup needed for containers), while also allowing for better policy size reduction via sharing or rulesets and state machines. I should also note that we are working towards shared caches that aren't grouped, but the single load will be needed to dedup loading of these separate cache components. Out of the 3 presented solutions 2 does seem the most viable in the short term even though it has its own problems. Something like 2 might be needed anyways with triggers, because they will need to do more than just load the appropriate profile, they will also have to enable/disable so is in the correct state for loads during boot. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2121409 Title: [FFE] add a new apparmor.d package containing several apparmor profiles To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2121409/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
