linux-kernel - 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: <20140416185936.GJ31074@redhat.com>
Date:	Wed, 16 Apr 2014 14:59:37 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Simo Sorce <ssorce@...hat.com>, David Miller <davem@...emloft.net>,
	Tejun Heo <tj@...nel.org>, Daniel Walsh <dwalsh@...hat.com>,
	"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 Wed, Apr 16, 2014 at 11:13:31AM -0700, Andy Lutomirski wrote:
> On Wed, Apr 16, 2014 at 11:06 AM, Vivek Goyal <vgoyal@...hat.com> wrote:
> > On Wed, Apr 16, 2014 at 09:31:25AM -0700, Andy Lutomirski wrote:
> > I am not sure how same issue with happen with cgroups. In the case of
> > socket example, you are forcing a setuid program to write to standard
> > output and that setuid program will run in same cgroup as caller and
> > will have same cgroup as caller. So even if somebody was using cgroup
> > information for authentication, atleast in this particular case it
> > will not be a problem. Both unpriviliged and priviliged programs has
> > same cgroups.
> >
> 
> I'm not sure that there's an actual attackable program.  But I also
> see no reason to be convinced that there isn't one, and the problem
> can easily be avoided by requiring programs to explicitly ask to send
> their cgroup.

If you can't prove that there is something fundamentally wrong with
passing cgroup info to receiver, there is no reason to block these
patches either.

We can't fix the problems which we can't see. You are saying that I 
don't know what kind of problem can happen due to cgroup passing. Still
that does not mean none of the problems exist. So let us not pass cgroup
info by default and ask client to opt in.

I don't think this is a very convincing argument.

To me, if we can't see anything fundamentally wrong with passing cgroup
info, we should take these patches in. And once we figure out that there
is are problematic use cases, then implement SO_NOPASSCGROUP and
SO_NOPEERCRED  and allow problematic clients to opt out.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/