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.
This initramfs transition is a tricky bit of business -- I assume I'll
want to have a different profile for systemd for the chrooted system and
that when the apparmor service starts, 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? 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.
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.
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
