The kdbuswreck [LWN.net]

The kdbuswreck

Posted Apr 22, 2015 23:49 UTC (Wed) by ncm (guest, #165)
In reply to: The kdbuswreck by josh
Parent article: The kdbuswreck

This does not look at all like a system ready to pull.

This sort of system should be using tickets. On login, the process group leader would be issued all the tickets it needs, which can then be communicated over any (secure) medium to child processes, and thence to services. No ticket, no service. The kernel's role, then, is just to deliver ticketed requests: packets, in other words. Tickets can be transacted myriad ways to arrange just the services needed and authorized, and nothing more. E.g. a service might require a ticket which no single other process has, but that two processes together can construct for the occasion.

Capabilities, or any fixed list, will always be the worser of too broad and not broad enough.

to post comments

The kdbuswreck

Posted Apr 23, 2015 8:41 UTC (Thu) by smurf (subscriber, #17840) [Link] (1 responses)

You may well be right (Kerberos, anybody?), but waiting another year or more for a comprehensive ticket subsystem to materialize ^w be developed and debugged seems rather unproductive.

kdbus doesn't add anything to the way systemd handles capabilities, except remove the race condition inherent in checking for them. Passing them through kdbus also doesn't add any and privacy concerns because quite frankly, the knowledge whether or not a particular process does or does not have a particular capability is not a security hole; call me somewhat dumb but offhand I can't think of a way to make it into one.

Rejecting kdbus just because it uses caps is thus somewhat disingenious.

The kdbuswreck

Posted Apr 23, 2015 22:31 UTC (Thu) by luto (subscriber, #39314) [Link]

Not quite. Systemd doesn't use caps for dbus on non-kdbus systems.

The kdbuswreck

Posted Apr 23, 2015 14:41 UTC (Thu) by drag (guest, #31333) [Link] (12 responses)

Tickets sounds awesome to me.

In the most basic mode Systemd could pass tickts to launched processes through tags in service files. For backwards compatibility to dbus systemd then can examine the capabilities of a process and assign a set of tickets based on that.

Later on a more advanced of gaining tickets can be developed were the process itself is able to negiotiate with systemd-related daemon 'ticket granting service' ala kerberos-style system.

The upside of this from the kernel's perspective is that the tickets themselves are meaningless in terms of kernel privileges. They don't mean anything at all to the kernel in terms of what type of system calls the process can do or anything like that. All the kdbus does is just provide a simple way to share ticket information. Then it really is just metadata only relevent to systemd and systemd related privileged daemons.

They would be read-only from a individual process's perspective. Having a simple /proc/<pid>/ktickets file that would list them for userspace.

To avoid issues with 'nested' operating system namespaces a associated hash can be tied to the tickets so that some process can have it's privileges associated with a specific container and avoid issues when that information leaks out into parent containers/hosting namespaces.

From a userspace perspective this ticket system would be superior to using capabilities because it would offer a much larger amount of flexiblity.

Say, for example:

I am writing a embedded system for controlling hot air balloon. It would consist of a USB device attached to a Linux laptop that would provide various telementary data and other information about the state of the balloon to a 'balloon management daemon'.

For the UI it would be a simple python application running on the user's desktop and it would use kdbus to communicate with the daemon. I am interested in allowing other people to write their own UIs, but I want to make sure that some potentially malicious program or non-privileged user account won't be able to do fool around with the balloon.

So if we were using a ticket system I could provide a service file (or whatever) that would essentially say: "If user is part of 'balloon' group and then the processes launched by this service then assign 'balloon-priv:<host hash>:<time stamp>' ticket to process. Users and programs can easily check if they are getting the tickets correctly by checking out the /proc/<pid>/ktickets file. Kdbus itself wouldn't depend on that file, of course... it's just informational to show what kdbus metadata gets provided along with dbus messages.

...

If I was trying to depend on a capabilities system then what sort of capability would I want to use?

I think that if we see capabilities being used then you would have all sorts of crazy attempts by user space programs to overload capabilities and make the represent weird privileges that they were never intended to represent.... With pure-metadata tickets then that can allow flexiblity and allow userspace to evolve and change without forcing the kernel developers to make difficult choices about breaking backwards compatibility.

The kdbuswreck

Posted Apr 23, 2015 15:46 UTC (Thu) by fandingo (guest, #67019) [Link] (11 responses)

Kdbus already includes a seclabel that can easily fulfill this "ticketing" functionality. LSMs can evaluate this metadata and enforce policy.

People are getting way to carried away with the importance of the capability metadata. It's simply not used for much.

The kdbuswreck

Posted Apr 23, 2015 17:06 UTC (Thu) by drag (guest, #31333) [Link] (8 responses)

> LSMs can evaluate this metadata and enforce policy.

I thought this is about IPC and a way to provide a authentication method so that privileged daemons can carry out tasks on behalf of non-privileged applications?

What would forcing people to program LSMs accomplish here?

The kdbuswreck

Posted Apr 23, 2015 21:24 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

SELinux labels could be [mis]used as tickets. They are traditionally used only to restrict access, but that's just a policy decision.

The kdbuswreck

Posted Apr 23, 2015 22:31 UTC (Thu) by drag (guest, #31333) [Link] (4 responses)

*shrug*

I like the idea of just having a generic metadata that isn't tied into anything else and allow user space to decide the format and how it's interpreted. Just let the kernel provide the mechanism and not be responsible directing the policy (besides a very simple 'is Y allowed to listen to X message bus').

Tying other kernel security interfaces into it as part of IPC information packet seems like it would be a mistake. Especially since those LSMs or capabilities (or whatever) are not necessarily appropriate for every case were daemons have to make a choice in how to respond to process requests.

At least that way it seems that kdbus working in concert with systemd would have a way to maintain backwards compatibility without having to hard code that into the kernel for all of eternity. Which seems to me what Andy is shooting for here.

The kdbuswreck

Posted Apr 23, 2015 23:04 UTC (Thu) by jspaleta (subscriber, #50639) [Link] (3 responses)

i'm not seeing how kdbus mandates caps usage for all of eternity.

Here's my understanding that right now with the current patches
receiver decided if it needs to have caps info or not
sender decides if it wants to send over caps.

If they agree recv and sender get to talk via the bus. If they don't.. bus doesn't relay mesgs.

If in the future every single receiver and sender on the bus decided they no longer needed to care about caps they can just stop asking for that metadata to be sent over the bus. Right?

The kdbuswreck

Posted Apr 23, 2015 23:23 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

If the kernel API says that it passes caps, it is _really_ hard to change that later without breaking something in userspace that depends on it.

This is one of the big reasons people are unhappy with kdbus, it locks a lot of dbus specific policies into the kernel API

The claim is that the only thing that should talk to it is libdbus, but we've already seen that such a policy doesn't work against the userspace dbus, so why would it work against kdbus?

The kdbuswreck

Posted Apr 23, 2015 23:39 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

DBUS is extensible, so in future it's certainly possible to pass additional capabilities via custom methods. The old userspace simply won't be able to use it, but that's not a big deal.

It all seems like a storm in a teacup, the current capabilities are used only for very special actions like rebooting or manipulation of system services. Basically, they are more-or-less a direct replacement of "if (sender_uid == 0)".

The kdbuswreck

Posted Apr 30, 2015 10:17 UTC (Thu) by metux-its (guest, #102293) [Link]

Actually, I never understood why tiny side cases like reboots need all that complexity.

Anybody noticed that we already have per-process namespaces ?
Oh, and we've got file permission flags since aeons.

Why not just giving things like the shutdown/reboot service their
own communication channel (ie. socket), which is only made available
to certain users or processes ? Either via perms or mounts, or by
some key authentication ?

Anybody had a look at Plan9 ?
It really could be so simple ...

The kdbuswreck

Posted Apr 25, 2015 1:06 UTC (Sat) by wahern (subscriber, #37304) [Link] (1 responses)

I'm not that familiar with SELinux, so please excuse my ignorance.

1) I thought the only way to attach a label to a resource is by tagging a file or other specific resource in the first instance. Similar to POSIX capabilities. So, for example, you attach labels to an executable file. Or you attach labels to a port. But how do you attach labels to ad hoc resources? Presumably you could create an anonymous file using open(O_TMPFILE) or memfd_create. But don't you need some kind of privilege to create new labels? And how do you attach a label to a resource when your process isn't already so labeled? Would systemd have to re-execute itself every time a new privilege was defined, e.g. from a package update.

2) I thought the purpose of SELinux was to prevent processes from acquiring access to resources when the labels don't match up. So, for example, if systemd creates a new file descriptor, attaches the label "reboot" to it, how can it pass it to another process that isn't already tagged with the label, "reboot"? The reboot-privileged executable will have been invoked from a process that probably shouldn't have that capability.

Basically, the only difference I can see between SELinux and POSIX capabilities in this scenario is that SELinux has a much larger namespace for defining ad hoc capabilities, as well as a way more sophisticated way to group capabilities (i.e. roles). AFAICT neither solution works anything like Kerberos or Capsicum, in the sense of capabilities that you can freely (but explicitly) pass to other processes, including unrelated processes.

Most importantly, the latter are much more friendly from a programming perspective. As a general matter, the developer is the most knowledgable person--compared to a package maintainer, or system administrator--when it comes to defining, exchanging, and executing capabilities. It's the only practical way to achieve fine-grained separation of privileges, especially ad hoc privileges unrelated to specific, pre-existing global resources. Solutions like SELinux can then be used to further restrict privilege--in as much as they're identifiable system resources--based on local policy.

The kdbuswreck

Posted Apr 25, 2015 2:03 UTC (Sat) by fandingo (guest, #67019) [Link]

> But don't you need some kind of privilege to create new labels?

Yes, that's defined in the SELinux policy. This is exactly what QEMU with s_virt does.

> And how do you attach a label to a resource when your process isn't already so labeled?

The ability to set MLS levels is controlled by selinux policy. It's the domain transition that allows setexeccon(3).

> Would systemd have to re-execute itself every time a new privilege was defined, e.g. from a package update.

I'm not exactly sure what you mean here, but it shouldn't. Obviously, if systemd got new code to enable it do something new, then that part of systemd would need to be restarted. However, if that code was previously there, then no. SELinux policy would have blocked it in the past, but the package update to selinux-policy would be loaded into the kernel, and then, allow that action to succeed.

> So, for example, if systemd creates a new file descriptor, attaches the label "reboot" to it, how can it pass it to another process that isn't already tagged with the label, "reboot"?

Why would it do this? It doesn't make any sense. SELinux would prevent that process from performing issuing any syscalls with that FD. The process would need to be allowed to access this resource through selinux-policy with the "reboot" label or able to do a domain transition (relabel).

> Basically, the only difference I can see between SELinux and POSIX capabilities in this scenario is that SELinux has a much larger namespace for defining ad hoc capabilities, as well as a way more sophisticated way to group capabilities (i.e. roles). AFAICT neither solution works anything like Kerberos or Capsicum, in the sense of capabilities that you can freely (but explicitly) pass to other processes, including unrelated processes.

I think that you're missing the policy part of SELinux, and the allowed transitions that can be programmed.

> Most importantly, the latter are much more friendly from a programming perspective. As a general matter, the developer is the most knowledgable person--compared to a package maintainer, or system administrator--when it comes to defining, exchanging, and executing capabilities.

Then ship a SELinux policy with your program. If the developer knows what resources, sharing, and transitions are required, she just needs to define it in the policy.

It's certainly possible in SELinux to allow arbitrarily defined syscalls on open FDs, but restrict the opening of new ones, which I think is what you're getting at. However, that's normally how SELinux policies are defined.

The kdbuswreck

Posted Apr 24, 2015 13:21 UTC (Fri) by ncm (guest, #165) [Link] (1 responses)

Every time I read "caps aren't used for much", it reads "this is not an appropriate thing to shove into the kernel". Stuff in the kernel should be stuff that *is* used for much, _and_ that can't practically be done any other way.

Not being used for much, too, indicates that switching it over to a ticketed service would not be a big job.

The kdbuswreck

Posted Apr 24, 2015 14:55 UTC (Fri) by fandingo (guest, #67019) [Link]

I'm not sure what you mean by "stuff" and "this." Are you complaining about caps, kdbus, or kdbus' use of caps?

Caps *are* in the kernel, and with the slavish devotion to supporting things forever, they'll be there for the foreseeable future. The horse is out of the barn. (That being said, the problem with caps is more implementation thn design. If you want some sophisticated policy system, that's never what caps were designed to do.)

Kdbus will definitely be used for a ton of stuff.

> Not being used for much, too, indicates that switching it over to a ticketed service would not be a big job.

I still don't understand what this is supposed to mean. This metadata is attached to kdbus messages because it cannot be provided in an atomic, attestable manner otherwise. A Kerberos-like ticketing system doesn't need any of that. It's the sender that provides the ticket directly to the SS. Even if the kernel were the AS -- which doesn't make sense -- the kernel doesn't need to insert metadata all over the place.

That's the fundamental problem with this ticketing idea: It is neither based on data that the kernel has nor data that is useful to the kernel -- only to the sender, receiver, and authenticator.

I seriously don't understand where this ticketing idea originates or particularly how it relates to the issue at hand. It's like a kid in a candy story that starts yelling about wanting a pony. Umm, I guess it could be nice, but that doesn't help answer the question whether he wants chocolates or gummies.