On 5/27/19 5:11 PM, Ian wrote: > > On 5/27/19 12:08 PM, Ian wrote: >> >> Does apparmor have the same problem as selinux where there are "security >> aware" programs that don't properly honor enforcement settings, or is this >> an inheritance problem that I'm not correctly addressing? >> >> >> > Adding "attach_disconnected" to the flags parameter of the init-systemd > profile was required to get the system to fully boot. I assume this was > necessary because of the transition from initramfs, however the "ALLOWED" > audit log entries really threw me there -- that and my ability to run lots of > other commands without issue in that "emergency" mode didn't make this an > obvious fix. > yes this is a pita, and logs getting dropped make it worse. I don't have a good solution in the short term. Long term, the audit parts are getting reworked and will be able to do better dedup and caching to reduce auditing load, and allow for devs to create a large log buffer to properly profile early boot.
> This initramfs transition is a tricky bit of business -- that it is > I assume I'll want to have a different profile for systemd for the chrooted > system and that when the apparmor service starts, that is probably best but may not be necessary depending on the privileges you are granting > the profile will get replaced, however I thought that profile changes like > this aren't seen by currently executing processes -- one has to restart the > process for the change to take effect? Actually as long as the profile is already attached to the task, profile replacement will be picked up. However there is no guarantee that it will be atomic across all tasks. That is to say the update happens on a best effort case, and the old and new version of the profile may be alive at the same time for a window. Exactly how long depends on locking and scheduling etc. Profiles for a task will only be updated when the task is running, etc. What currently can't be done is changing the confinement of a task from one profile to another. The task must be either "security aware" and do this it self or be re-execed. > Then there's the timing of when journald and auditd starts. Ideally I'd like > to keep the full-permission profile I set up in inittamfs for systemd, but > then somehow deny any type of inheritance once the AppArmor service starts. > you should be able to achieve this with just a profile load in the apparmor service. Replacing the existing profiles that were already loaded from the initrd. It of course has the above mentioned limitations > Any advice on how to proceed? -- If it is true that all child processes will, > by default, inherit the permissions from the init-systemd profile unless I > add deny rules -- I'm back at square one with a blacklist setup. > > it will depend on your init-systemd profile. If it uses ix for exec transitions then every child will inherit its confinement. However if you use px or even pix and have profiles definied for those children then they should have different confinement and you should be okay. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
