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]

Date:	Thu, 17 Apr 2014 10:26:09 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Simo Sorce <ssorce@...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, Apr 17, 2014 at 10:12 AM, Vivek Goyal <vgoyal@...hat.com> wrote:
> On Thu, Apr 17, 2014 at 09:55:08AM -0700, Andy Lutomirski wrote:
>> On Thu, Apr 17, 2014 at 9:48 AM, Simo Sorce <ssorce@...hat.com> wrote:
>> > On Thu, 2014-04-17 at 09:37 -0700, Andy Lutomirski wrote:
>> >> On Thu, Apr 17, 2014 at 9:24 AM, Simo Sorce <ssorce@...hat.com> wrote:
>> >> > On Thu, 2014-04-17 at 09:11 -0700, Andy Lutomirski wrote:
>> >> >>
>> >> >> No.  The logging daemon thinks it wants to know who the writer is, but
>> >> >> the logging daemon is wrong.  It actually wants to know who composed a
>> >> >> log message destined to it.  The caller of write(2) may or may not be
>> >> >> the same entity.
>> >> >
>> >> > This works both ways, and doesn't really matter, you are *no* better off
>> >> > w/o this interface.
>> >> >
>> >> >> If this form of SO_PASSCGROUP somehow makes it into a pull request for
>> >> >> Linus, I will ask him not to pull it and/or to revert it.  I think
>> >> >> he'll agree that write(2) MUST NOT care who called it.
>> >> >
>> >> > And write() does not, there is no access control check being performed
>> >> > here. This call is the same as getting the pid of the process and
>> >> > crawling /proc with that information, just more efficient and race-free.
>> >>
>> >> Doing it using the pid of writer is wrong.  So is doing it with the
>> >> cgroup of the writer.  The fact that it's even possible to use the pid
>> >> of the caller of write(2) is a mistake, but that particular mistake
>> >> is, unfortunately, well-enshrined in history.
>> >>
>> >> >
>> >> > I repeat, it is *not* access control.
>> >> >
>> >>
>> >> Sure it is.
>> >>
>> >> Either correct attribution of logs doesn't matter, in which case it
>> >> makes little difference how you do it, or it does matter, in which
>> >> case it should be done right.
>> >
>> > Well journald can *also* get  SO_PEERCGROUP and log anomalies if the 2
>> > differ. That is if the log happens on a connected socket.
>> >
>> > If the log happens on a unix datagram* then SO_PEERCGROUP is not
>> > available because there is no connect(), however write() cannot be used
>> > either, only sendmsg() AFAIK, so the "setuid" binary attack does not
>> > apply.
>> >
>>
>> Or you could only send SCM_CGROUP when the writer asks sendmsg to send
>> it, in which case this whole problem goes away.
>
> Sending SCM_CGROUP explicitly is also sending cgroup info at write(2) time
> and if receiver uses that info for access control, it can be problematic.
>

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.

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