The kdbuswreck
The kdbuswreck
Posted Apr 23, 2015 17:06 UTC (Thu) by drag (guest, #31333)In reply to: The kdbuswreck by fandingo
Parent article: The kdbuswreck
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?
Posted Apr 23, 2015 21:24 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
Posted Apr 23, 2015 22:31 UTC (Thu)
by drag (guest, #31333)
[Link] (4 responses)
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.
Posted Apr 23, 2015 23:04 UTC (Thu)
by jspaleta (subscriber, #50639)
[Link] (3 responses)
Here's my understanding that right now with the current patches
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?
Posted Apr 23, 2015 23:23 UTC (Thu)
by dlang (guest, #313)
[Link] (2 responses)
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?
Posted Apr 23, 2015 23:39 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
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)".
Posted Apr 30, 2015 10:17 UTC (Thu)
by metux-its (guest, #102293)
[Link]
Anybody noticed that we already have per-process namespaces ?
Why not just giving things like the shutdown/reboot service their
Anybody had a look at Plan9 ?
Posted Apr 25, 2015 1:06 UTC (Sat)
by wahern (subscriber, #37304)
[Link] (1 responses)
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.
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.
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.
The kdbuswreck
The kdbuswreck
The kdbuswreck
receiver decided if it needs to have caps info or not
sender decides if it wants to send over caps.
The kdbuswreck
The kdbuswreck
The kdbuswreck
Oh, and we've got file permission flags since aeons.
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 ?
It really could be so simple ...
The kdbuswreck
The kdbuswreck