Discussion:
Apparmor in containers
(too old to reply)
Matthias Pfau
2018-04-10 16:16:48 UTC
Permalink
Raw Message
Hi there,
we use apparmor on our production systems and want to test the setup in our test environment based on systemd-nspawn.

Therefore, I installed apparmor on the host (debian stretch) and updated GRUB_CMDLINE_LINUX in /etc/default/grub to enable apparmor. I can use apparmor on the host system. However, within my containers, apparmor can not be started.

`journalctl -kf` does not print anything when invoking `systemctl start apparmor` on the container and `systemctl status apparmor` just returns  "ConditionSecurity=apparmor was not met".

Is it possible to run apparmor in a container?

Cheers,
Matthias
Lennart Poettering
2018-04-12 09:48:21 UTC
Permalink
Raw Message
Post by Matthias Pfau
Hi there,
we use apparmor on our production systems and want to test the setup in our test environment based on systemd-nspawn.
Therefore, I installed apparmor on the host (debian stretch) and updated GRUB_CMDLINE_LINUX in /etc/default/grub to enable apparmor. I can use apparmor on the host system. However, within my containers, apparmor can not be started.
`journalctl -kf` does not print anything when invoking `systemctl start apparmor` on the container and `systemctl status apparmor` just returns  "ConditionSecurity=apparmor was not met".
Is it possible to run apparmor in a container?
Uh, I have no experience with AA but to my knowledge none of the
kernel MACs (AA, SMACK, SELinux) are virtualized for container
environments, i.e. there can only be one system policy, and containers
tend to be managed under a single context only as a whole.

But I'd be happy to be proved wrong, as I never touched AA, so I don't
really know.

If AA should indeed be virtualizable for containers then making nspawn
support it is likely very easy, but I have my doubts it is...

Please contact the AA community, and ask them whether AA containers
can load their own policies. If yes, then please file an RFE issue
against systemd, asking us to add support for this, with links to the
APIs. best chance to get this implemented quickly would be to file a
patch too, we'd be happy to review that.

Lennart
--
Lennart Poettering, Red Hat
Filipe Brandenburger
2018-04-12 15:18:41 UTC
Permalink
Raw Message
Hi,

Actually, it seems AppArmor has support for containers and can have a
specific profile for inside the containers only.

Docker does support it:
https://docs.docker.com/engine/security/apparmor/

Agree it shouldn't be too hard to hook this into nspawn... I don't really
use AppArmor or know it well though, so I'm not best placed to test it...

Cheers,
Filipe
Post by Matthias Pfau
Post by Matthias Pfau
Hi there,
we use apparmor on our production systems and want to test the setup in
our test environment based on systemd-nspawn.
Post by Matthias Pfau
Therefore, I installed apparmor on the host (debian stretch) and
updated GRUB_CMDLINE_LINUX in /etc/default/grub to enable apparmor. I can
use apparmor on the host system. However, within my containers, apparmor
can not be started.
Post by Matthias Pfau
`journalctl -kf` does not print anything when invoking `systemctl start
apparmor` on the container and `systemctl status apparmor` just returns
"ConditionSecurity=apparmor was not met".
Post by Matthias Pfau
Is it possible to run apparmor in a container?
Uh, I have no experience with AA but to my knowledge none of the
kernel MACs (AA, SMACK, SELinux) are virtualized for container
environments, i.e. there can only be one system policy, and containers
tend to be managed under a single context only as a whole.
But I'd be happy to be proved wrong, as I never touched AA, so I don't
really know.
If AA should indeed be virtualizable for containers then making nspawn
support it is likely very easy, but I have my doubts it is...
Please contact the AA community, and ask them whether AA containers
can load their own policies. If yes, then please file an RFE issue
against systemd, asking us to add support for this, with links to the
APIs. best chance to get this implemented quickly would be to file a
patch too, we'd be happy to review that.
Lennart
--
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Loading...