On Apr 15, 2014 5:20 PM, "Vivek Goyal" <vgoyal@xxxxxxxxxx> wrote: > > On Tue, Apr 15, 2014 at 02:53:13PM -0700, Andy Lutomirski wrote: > > On Tue, Apr 15, 2014 at 2:15 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > > > This patch implements socket option SO_PASSCGROUP along the lines of > > > SO_PASSCRED. > > > > > > If SO_PASSCGROUP is set, then recvmsg() will get a control message > > > SCM_CGROUP which will contain the cgroup path of sender. This cgroup > > > belongs to first mounted hierarchy in the sytem. > > > > > > SCM_CGROUP control message can only be received and sender can not send > > > a SCM_CGROUP message. Kernel automatically generates one if receiver > > > chooses to receive one. > > > > > > This works both for unix stream and datagram sockets. > > > > > > cgroup information is passed only if either the sender or receiver has > > > SO_PASSCGROUP option set. This means for existing workloads they should > > > not see any significant performance impact of this change. > > > > This is odd. Shouldn't an SCM_CGROUP cmsg be generated when the > > receiver has SO_PASSCGROUP set and the sender passes SCM_CGROUP to > > sendmsg? > > How can receiver trust the cgroup info generated by sender. It needs to > be generated by kernel so that receiver can trust it. > > And if receiver needs to know cgroup of sender, receiver can just set > SO_PASSCGROUP on socket and receiver should get one SCM_CGROUP message > with each message received. I think the kernel should validate the data. Here's an attack against SO_PEERCGROUP: if you create a container with a super secret name, then every time you connect to any unix socket, you leak the name. Here's an attack against SO_PASSCGROUP, as you implemented it: connect a socket and get someone else to write(2) to it. This isn't very hard. Now you've impersonated. I advocate for the following semantics: if sendmsg is passed a SCM_CGROUP cmsg, and that cmsg has the right cgroup, and the receiver has SO_PASSCGROUP set, then the receiver gets SCM_CGROUP. If you try to lie using SCM_CGROUP, you get -EPERM. If you set SO_PASSCGROUP, but your peer doesn't sent SCM_CREDS, you get nothing. This is immune to both attacks. It should be cheaper, too, since there's no overhead for people who don't use it. --Andy -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
