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]
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 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