On Wed, Apr 16, 2014 at 10:29:08AM -0700, Andy Lutomirski wrote: [..] > >> Admittedly cgroups aren't currently as important as uid, but if this > >> changes, then SO_PASSCGROUP, as currently written, will have *exactly* > >> the same problem. > > > > Which is easy to foil by using SO_PEERCGROUP and find out who originally > > opened the socket, which is why that is also available! > > Then please remove SO_PASSCGROUP.
SO_PASSCGROUP is important because SO_PEERCGROUP does not work with unix datagram sockets. Again going back to logging example, if some clients are logging to unix datagram sockets, SO_PASSCGROUP is the only option to figure out cgroup of client. > > >> The issue here is that the receiver sets SO_(PASS|PEER)CGROUP, forcing > >> the sender to identify or authenticate itself. The sender might not > >> want to identify itself. > > > > You need to explain, why, on a host, when an application connects to > > another, it is ok to make it anonymous. If you do not want to expose > > yourself, do not talk to other applications in the first place. > > Why is anonymity harmful here? I don't have a great argument off the > top of my head for why it's necessary, but neither do I see why it's > bad. So once we have example where anonymity helps, we can implement SO_NOPASSCGROUP to take care of it. > And I think a lack of anonymity is asking for trouble (see > below). I read the example, below. I don't get where the *lack of anonymity* is a problem. You just seem to referring to the fact that SO_PEERCGROUP will not be reliable if after opening a connection fd was passed to a program in a different cgroup. And that's one reason why SCM_PASSCGROUP is also implemented so that these kind of issues can be avoided. So I fail to see what's the relation to *anonymity* in your example. > > > > >> the sender might not intend to authenticate. Certainly no existing > >> callers of connect or write intend to authenticate using their cgroup, > >> since current kernels don't have those semantics. > > > > This is a passive check, it's the receiver that wants to make decisions > > about who is connecting, again if you do not want to "disclose" > > information do not connect in the first place ? > > > > Let's say I have a receiver. I'll call it journald, since I think > that's one of the eventual use cases. > > Let's also say I some random program on my box. It is willing to > answer requests on behalf of anyone else with the same uid, and it > will happily open a given unix socket and send the requester the file > descriptor. Such a program is a bit odd, but it's perfectly safe > right now. > > Now add a malicious program into the mix. It asks the daemon to open > /run/systemd/journal/socket. Then it starts writing to the fd. > > Whoops, now the malicious program can impersonate the helper. This > happens because SO_PEERCGROUP (and journald's use of SO_PEERCGROUP) > caused connect(2) to produce a descriptor that carries a permission > that the descriptor did not carry in the past, and because the caller > of connect(2) did not need to opt in to the new behavior. > > I still haven't seen any explanation for what's wrong with requiring > senders to ask the kernel to transmit their cgroup. If nothing else, additional complexity and ovhead. Extra pair of messages need to be exchanged to request and then provide the information. How would it work in logging example? Every time logger receives a message, is it supposed to send another message to client to send SCM_CGROUP? That does not sound right. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
