[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5320CAEC.6030008@amacapital.net>
Date: Wed, 12 Mar 2014 14:00:28 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Vivek Goyal <vgoyal@...hat.com>, linux-kernel@...r.kernel.org,
cgroups@...r.kernel.org, netdev@...r.kernel.org,
davem@...emloft.net, tj@...nel.org
CC: ssorce@...hat.com, jkaluza@...hat.com, lpoetter@...hat.com,
kay@...hat.com
Subject: Re: [PATCH 2/2] net: Implement SO_PEERCGROUP
On 03/12/2014 01:46 PM, Vivek Goyal wrote:
> Implement SO_PEERCGROUP along the lines of SO_PEERCRED. This returns the
> cgroup of first mounted hierarchy of the task. For the case of client,
> it represents the cgroup of client at the time of opening the connection.
> After that client cgroup might change.
Even if people decide that sending cgroups over a unix socket is a good
idea, this API has my NAK in the strongest possible sense, for whatever
my NAK is worth.
IMO SO_PEERCRED is a disaster. Calling send(2) or write(2) should
*never* imply the use of a credential. A program should always have to
*explicitly* request use of a credential. What you want is SCM_CGROUP.
(I've found privilege escalations before based on this observation, and
I suspect I'll find them again.)
Note that I think that you really want SCM_SOMETHING_ELSE and not
SCM_CGROUP, but I don't know what the use case is yet.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists