On Apr 20, 2015 8:22 AM, "Lennart Poettering" <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote: > > On Mon, 20.04.15 08:08, Andy Lutomirski (<a href="mailto:luto@amacapital.net">luto@amacapital.net</a>) wrote: > > > On Apr 20, 2015 7:57 AM, "Lennart Poettering" <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> > > wrote: > > > > > > On Fri, 17.04.15 09:14, Andy Lutomirski (<a href="mailto:luto@amacapital.net">luto@amacapital.net</a>) wrote: > > > > > > > My point here is that there's no real shortage of downsides to this > > > > scheme, and there still appears to be little to no benefit. > > > > > > Well, let's turn this around. You seem to really dislike caps. And you > > > vaguely claim security holes, which we have shown know don't > > > exist. So, now, can you clearly explain why precisely you dislike them > > > so much still? And something more technical then "systemd shouldn't > > > use them" or "i don't like them", or "they should only be used in the > > > kernel", because these are not technical reasons, they are just claims > > > of personal taste. > > > > > > 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). > > > 2. The set of caps that exist is controlled by the kernel, whereas the set > > of dbus methods is large and controlled by userspace. Caps can't scale to > > accommodate flexble userspace policies. > > 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. > > > 3. They don't appear to add value, and avoiding unnecessary complexity is > > good. > > Well, I disagree on this. I think they are better because more > fine-grained than "uid == 0" checks. > > > 4. They suck. This is a technical issue -- the kernel doesn't allow > > flexible assignments of caps to processes. This is a problem for kernel > > API users and it will be a problem for you. > > Not a technical reason, unlike you claim. Just a personal taste issue. Sure it is. Caps are defined in the kernel sources and, as seems to have been covered pretty well in this thread, the list of caps is very far from what a userspace dbus service would want to check. --Andy > > Honestly, I don't think the issues you raise are very convincing.... > > Lennart > > -- > Lennart Poettering, Red Hat