linux-kernel - Re: [PATCH 0/2] net: Implement SO_PEERCGROUP and SO

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: <20140423155512.GA24651@redhat.com>
Date:	Wed, 23 Apr 2014 11:55:12 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	David Miller <davem@...emloft.net>
Cc:	linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
	netdev@...r.kernel.org, tj@...nel.org, ssorce@...hat.com,
	lpoetter@...hat.com, kay@...hat.com, luto@...capital.net,
	dwalsh@...hat.com
Subject: Re: [PATCH 0/2] net: Implement SO_PEERCGROUP and SO_PASSCGROUP
 socket options

On Tue, Apr 22, 2014 at 04:05:58PM -0400, David Miller wrote:
> From: Vivek Goyal <vgoyal@...hat.com>
> Date: Tue, 15 Apr 2014 17:15:44 -0400
> 
> > This is another version of patchset to add support passing cgroup
> > information of client over unix socket API.
> 
> I'm marking this patch series as "changes requested" in patchwork
> because if we still end up adding this feature SO_PASSCGROUP needs to
> be changed to behave like SO_PASSCRED.

Does this concern of passing of real uid apply to cgroups also. Even
if somebody tricks suid program to write to fd setup by under priviliged
program how would that pgram force setuid program to change cgroup.

To me passing cgroup information looks more like "pid" information where
we pass the actual pid of setuid program and not the pid of parent who
setup fd.

How would one trick setuid program change cgroup? If not, then this class
of attack does not seem to apply to SO_PASSCGROUP.

So I think real discussion here should be how "cgroup" information should
be used and not necessarily whether we should be passing cgroup
information of sender. This information is already available. One can
do SO_PASSCRED, get pid, get /proc/pid/cgroup and use cgroup in whatever
way they want.

If that's buggy, should we block /proc/pid/cgroup interface because cgroup
info of a process can be used in improper way.

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/