Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751686AbaDPDsW (ORCPT ); Tue, 15 Apr 2014 23:48:22 -0400 Received: from mail-lb0-f172.google.com ([209.85.217.172]:46822 "EHLO mail-lb0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750998AbaDPDsQ (ORCPT ); Tue, 15 Apr 2014 23:48:16 -0400 MIME-Version: 1.0 In-Reply-To: <20140416002010.GA5035@redhat.com> References: <1397596546-10153-1-git-send-email-vgoyal@redhat.com> <1397596546-10153-3-git-send-email-vgoyal@redhat.com> <20140416002010.GA5035@redhat.com> From: Andy Lutomirski Date: Tue, 15 Apr 2014 20:47:54 -0700 Message-ID: Subject: Re: [PATCH 2/2] net: Implement SO_PASSCGROUP to enable passing cgroup path To: Vivek Goyal Cc: Tejun Heo , Daniel Walsh , "linux-kernel@vger.kernel.org" , lpoetter@redhat.com, Simo Sorce , cgroups@vger.kernel.org, "David S. Miller" , kay@redhat.com, Network Development Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Apr 15, 2014 5:20 PM, "Vivek Goyal" 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 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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/