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: <1397759013.2628.86.camel@willson.li.ssimo.org>
Date:	Thu, 17 Apr 2014 14:23:33 -0400
From:	Simo Sorce <ssorce@...hat.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Vivek Goyal <vgoyal@...hat.com>,
	Daniel J Walsh <dwalsh@...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, 2014-04-17 at 10:35 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 10:33 AM, Simo Sorce <ssorce@...hat.com> wrote:
> > On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
> >>
> >> Not really.  write(2) can't send SCM_CGROUP.  Callers of sendmsg(2)
> >> who supply SCM_CGROUP are explicitly indicating that they want their
> >> cgroup associated with that message.  Callers of write(2) and send(2)
> >> are simply indicating that they have some bytes that they want to
> >> shove into whatever's at the other end of the fd.
> >
> > But there is no attack vector that passes by tricking setuid binaries to
> > write to pre-opened file descriptors on sendmsg(), and for the other
> > cases (connected socket) journald can always cross check with
> > SO_PEERCGROUP, so why do we care again ?
> 
> Because the proposed code does not do what I described, at least as
> far I as I can tell.

Ok let me backtrack, apparently if you explicitly use connect() on a
datagram socket then you *can* write() (thanks to Vivek for checking
this).

So you can trick something to write() to it but you can't do
SO_PEERCGROUP on the other side, because it is not really a connected
socket, the connection is only faked on the sender side by constructing
sendmsg() messages with the original address passed into connect().

So given this unfortunate circumstance, requiring the client to
explicitly pass cgroup data on unix datagram sockets may be an
acceptable request IMO.

Perhaps this could be done with a sendmsg() header flag or simplified
ancillary data even, rather than forcing the sender process to retrieve
and construct the whole information which is already available in
kernel.

Simo.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ