The kdbuswreck

1)

> 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.

2)

> 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.