http://bugzilla.opensuse.org/show_bug.cgi?id=991901 http://bugzilla.opensuse.org/show_bug.cgi?id=991901#c12 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS Christian Boltz <suse-beta@cboltz.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(suse-beta@cboltz. | |de) | --- Comment #12 from Christian Boltz <suse-beta@cboltz.de> --- (In reply to Franck Bui from comment #11)
Sorry for the delay...
(In reply to Christian Boltz from comment #9)
I'll hand over this bug to the systemd maintainers since I believe it should be fixed in systemd ;-)
The short version is that lots of daemons (for example samba and apache) request capability sys_admin because of the way they communicate with systemd (sd_notifyf).
You probably meant capability "net_admin" instead of "sys_admin".
Right, sorry for confusing it.
Those daemons still work without granting this capability and can even talk to systemd, so it would be nice if we wouldn't need to grant that powerful capability to lots of daemons.
So what is exactly the problem here if it still works without granting capability "net_admin" ?
Is it just a matter of warnings or more ?
Short version: security warnings equal to "more" ;-) Longer version: In theory it's "just" about the log entries. I'm not sure if I'd call these log entries a "warning" ;-) but I understand that you could interpret them as such. In practise you really don't want to have DENIED log entries. Think of them as a red warning light, because they could indicate that a program has been hacked and tried to do funny[tm] things. I mean, do you really enjoy it if samba requests permissions that would allow to change your IP address and routing? ;-) (just for completeness, DENIED log entries can also mean that your AppArmor profile is "just incomplete".) To avoid these log entries (without changing systemd), you basically have two options: - allow net_admin in the AppArmor profile, which will allow more than the program actually needs. I probably don't need to mention that capability net_admin allows to change your IP, routing etc. (see capabilities(7) for details) so granting it superfluously weakens security. - deny net_admin in the profile - this silences the warnings, but if one day the program really needs that capability, the logging will still be silenced and you'll have a hard time to find out why the program doesn't work as expected. Both options are far from perfect.
Admittedly we could try SO_SNDBUF first and fallback to SO_SNDBUFFORCE but I'd like to understand the problem first.
The problem is exactly the order. systemd first tries SO_SNDBUFFORCE, and because that option needs capability net_admin (see capabilities(7)), we see the DENIED logs for net_admin. It should first try to use the door handle (SO_SNDBUF), and only kick in the door (SO_SNDBUFFORCE) if that fails. In practise, this should avoid SO_SNDBUFFORCE and therefore the need (and log entries) for capability net_admin. Noel's comment #2 looks like a good explanation of the technical details. The line numbers changed slightly, fd_inc_sndbuf() is now https://github.com/systemd/systemd/blob/master/src/basic/socket-util.c#L827
Disclaimer: my apparmor knowledge is mostly null :)
I'm not sure if I know more about the systemd internals than you know about AppArmor ;-) The very quick and rough summary is that an AppArmor profile is a whitelist of what a program is allowed to do (file permissions, capabilities etc.), and if it tries something not allowed in the profile, this will be denied and logged. <shameless plug> To get started with AppArmor, I can recommend my AppArmor Crash course - either the slides on blog.cboltz.de, or the video from oSC16. </shameless plug> -- You are receiving this mail because: You are on the CC list for the bug.