On Apr 20, 2015 9:07 AM, "Lennart Poettering" <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote: > > On Mon, 20.04.15 08:51, Andy Lutomirski (<a href="mailto:luto@amacapital.net">luto@amacapital.net</a>) wrote: > > > > > > I will grant you that they aren't particularly expressive, and I will > > > > > grant you that one day there might be better concepts. But that's not > > > > > a strong reason not to support them really, that's just a reason to > > > > > later add support for something better. > > > > > > > > Technical reasons: > > > > > > > > 1. They can't be usefully delegated to a namespace. > > > > > > Not sure I can parse that. If you use the bus to communicate across > > > namespace boundaries then each side lacks caps for the other. Great, > > > that's how it should be. And same as for uid checks btw... if a uid > > > cannot be translated, then it will not be passed! > > > > No. You're right for nspawn-style namespaces, but not for namespaces more > > broadly. Namespaces are a great way to drop various privileges, but your > > use of caps prevents certain uses (e.g. confining your hypothetical > > time-setting daemon in a namespace). > > I have seen no use of userns for sandboxing normal daemons so far. I > have seen tons of daemons using caps for such sandboxing. Sandstorm.io I bet Chromium will follow suit, and don't forget Docker and similar tools. > > maybe if userns in its current iteration doesn't mix as well as you'd > like it with caps this is indication that userns might need some more > polish, and not that caps are necessarily the bad guy here? > Nope, userns works just fine. > I mean, as the one who added most of the sandboxing features we expose > in systemd .service files currently (including things like > ReadOnlyDirectories=, PrviateTmp=, PrivateNetwork= which are all based > on kernel namespacing), I completely fail to see how we could even > expose user namespace like this in a good way that would hold water? > Capability-based sandboxing on the other hand is much easier to > handle, and in many cases a highly efficient way to sandbox stuff. Two > examples: There's a world outside systemd and, in that world, programs would like to be able to sandbox themselves. Userns is wonderful for that purpose. > > systemd-networkd drops privileges, becomes the "systemd-network" > user, only retains CAP_NET_ADMIN. That's actually already a really > good sandbox! > > systemd-timesyncd drops privileges, becomes the "systemd-timesync" > user, only retains CAP_SYS_TIME. And that's actually a really good > sandbox too! > > Both daemons are network facing, hence sandboxing things like this is > actually of quite some importance, and it *works*! Today! And it is > easy! easy enough for most administrators to grok it easily! And > because of that it is actually *good* security! Except that if it's too coarse-gained, it fails to actually separate privileges. > > And please don't discount these two daemons as irrelevant > examples. They are highly relevant, since they run on a good chunk of > Linux systems, as one of the few daemons that run really everywhere. > > Caps *do* have good uses, please don't claim otherwise. They are a > *lot* more relevant on today's system than userns at least! > > (Note that I am not saying that userns are really a bad idea or so, I > just would like to ask you to keep things in perspective: caps are > *good* -- even though they could be much better. And they are a ton > more useful and used than userns right now) > > > > OK, they are not very expressive, I granted you that already. But they > > > are still more expressive than "uid == 0". > > > > > > That they are not expressive is something I can agree with, as > > > mentioned above, but I don't consider this a real issue not to using > > > them. I mean, it would be great if we had something better in the > > > kernel, like capsicum or whatever, but we don't. And since caps are > > > pretty well supported otherwise on Linux, and they are better then > > > simple uid == 0 checks, I think they should be supported by kdbus too. > > > > This is a bad excuse. Given that you're designing something new, you have > > plenty of room to do better. > > We are not really in the business in designing comprehensive new > access control systems that can be used for in-kernel and in-userspace > subsystems. > > Sure, we also have bus policy, but that given it's non-interactive > logic it's not really suitable for the uses where we need uid or caps > checks, i.e. dynamic access control within called methods that need to > check different privileges dynamically. > > Lennart > > -- > Lennart Poettering, Red Hat