netdev - Re: [PATCH 2/2] net: Implement SO_PASSCGROUP to enable passing cgroup path

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140417161253.GC15749@redhat.com>
Date:	Thu, 17 Apr 2014 12:12:53 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Daniel J Walsh <dwalsh@...hat.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Simo Sorce <ssorce@...hat.com>,
	David Miller <davem@...emloft.net>, Tejun Heo <tj@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	lpoetter@...hat.com, cgroups@...r.kernel.org, kay@...hat.com,
	Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH 2/2] net: Implement SO_PASSCGROUP to enable passing
 cgroup path

On Thu, Apr 17, 2014 at 08:41:15AM -0700, Daniel J Walsh wrote:

[..]
> The two use cases for this patch are:
> 
> 1 Logging, to make sure the cgroup information gets correctly attributed
> to the caller. 
> 
> 2 Potentially reveal different information to the caller based on the
> cgroup information. 
> 
> Imagine you want to set up an apache web server that is going to use
> sssd for authentication data.  You might want to reveal a limited set of
> users to the apache service process based on the fact that it is running
> in the apache.service.slice.  If the apache service does the equivalent
> of getent passwd I want to give it different information then say sshd
> did the same calls.

Dan,

So in first case we should be fine with both SO_PEERCGROUP and
SO_PASSCGROUP. cgroup information is not being used as some sort of
security attribute and decide who can access what.

Second use case looks more like that cgroup information is being used
as some sort of security attribute to decide who gets to see what
information.

cgroup retrieved from SO_PEERCGROUP and used as an identifier to
decide who can access what should be safe. This is similar to doing
security checks at open(2) time.

Andy's contention is that cgroup information received using SO_PASSCGROUP
is not safe to use for some sort of authorization. And reason being that
socket file descriptors can be passed around and one can trick an 
priviliged process to write to that descriptor, making receiver believe
that priviilged process is asking for some info.

Now there are caveats to it. So far all the examples I have seen are
the ones where setuid program will run in same cgroup as client. So even
if we trick setuid program to write to socket fd, cgroup information
remains same.

I think problem will happen only in advance cases where priviliged
program is running in some other cgroup and if it accepts file
descritors and writes to them. I don't know if it is a common practice
or not.

May be we should just make it very clear that if cgroup information
is being used for any kind of authorization purposes, then use only
SO_PEERCGROUP. Limit SO_PASSCGROUP cgroup info for usages like logging.

Thanks
Vivek
--
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