Re: [systemd-devel] Apparmor in containers

[Filipe Brandenburger]

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


On Thu, Apr 12, 2018 at 2:48 AM, Lennart Poettering 
wrote:

> On Di, 10.04.18 18:16, Matthias Pfau (matth...@tutanota.de) wrote:
>
> > 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
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Using lldb in coredumpctl?

[Lennart Poettering]

On Do, 12.04.18 07:48, Ryan Gonzalez (rym...@gmail.com) wrote:

> coredumpd has definitely become one of my favorite systemd components since
> it makes debugging segfaults far easier than otherwise. However, for various
> reasons, I prefer using LLDB to GDB. Unfortunately, coredumpctl's gdb
> command is hardcoded to run, well, GDB.
> 
> My idea: what if there were a 'coredumpctl lldb' command, which did the same
> thing as 'coredumpctl gdb', except...instead running LLDB.
> 
> Of course, this could be done with a new switch, but 'coredumpctl gdb
> --lldb' seems a little idiosyncratic...

Hmm, three ideas:

1. we could add "coredumpctl run" which will extend the command line
   you have with the path to the unpacked coredump: "coredumpctl run
   lldb" would then do what you want (at least under the assumption
   that lldb is fine with just taking the coredump as argument?)

2. we could add a --debugger= switch or so similar to what you
   proposed. Plus a new verb "debug" that is an alias for "gdb", to
   make it less idiosyncractic for you.

3. add support for $SYSTEMD_DEBUGGER or so, which would be like #2 but
   you could set for your entire login session

Of course any combination of the above would work too.

Please file an RFE issue on github requesting this, maybe linking to
this mail...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Using lldb in coredumpctl?

[Ryan Gonzalez]

coredumpd has definitely become one of my favorite systemd components since 
it makes debugging segfaults far easier than otherwise. However, for 
various reasons, I prefer using LLDB to GDB. Unfortunately, coredumpctl's 
gdb command is hardcoded to run, well, GDB.


My idea: what if there were a 'coredumpctl lldb' command, which did the 
same thing as 'coredumpctl gdb', except...instead running LLDB.


Of course, this could be done with a new switch, but 'coredumpctl gdb 
--lldb' seems a little idiosyncratic...


--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Apparmor in containers

[Lennart Poettering]

On Di, 10.04.18 18:16, Matthias Pfau (matth...@tutanota.de) wrote:

> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel