The kdbuswreck [LWN.net]

The kdbuswreck

Posted Apr 25, 2015 1:06 UTC (Sat) by wahern (subscriber, #37304)
In reply to: The kdbuswreck by Cyberax
Parent article: The kdbuswreck

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.

to post comments

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.