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:	Wed, 16 Apr 2014 09:31:25 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Simo Sorce <ssorce@...hat.com>
Cc:	David Miller <davem@...emloft.net>,
	Vivek Goyal <vgoyal@...hat.com>, 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 9:13 AM, Simo Sorce <ssorce@...hat.com> wrote:
> On Wed, 2014-04-16 at 07:37 -0700, Andy Lutomirski wrote:
>> On Wed, Apr 16, 2014 at 5:57 AM, David Miller <davem@...emloft.net> wrote:
>> >
>> > Please, just stop.
>>
>> No.
>>
>> This thread is proposing an ABI.  This means that, if the ABI ends up
>> in Linus's kernel, then it has to be supported forever.  Now is the
>> time to find and fix any issues with it before they become much harder
>> to fix.
>
> Ok, but so far I haven't seen a single objection from you that has solid
> grounds.

CVE-2013-1959 was caused by a new kernel feature causing a call to
write(2) to behave as though the caller was authenticating itself to
something else where, in previous kernels, write(2) did not
authenticate.

Admittedly cgroups aren't currently as important as uid, but if this
changes, then SO_PASSCGROUP, as currently written, will have *exactly*
the same problem.

>
> The only one that *may* be reasonable is the "secret" cgroup name one,
> however nobody seem to come up with a reason why it is legitimate to
> allow to keep cgroup names secret.
>
> And if you can come up with such a good reason the SO_NOPASSCGROUP
> option seem the right solution.
>
>> This ABI is especially tricky because programs will use it even if
>> they don't explicitly try to.  So just adding the ABI may break
>> existing assumptions that are relevant to security or correctness.
>
> It's not clear to me what you mean by this, either you explicitly use
> SO_PASSCGROUP or not, it's not like you can involuntarily add a flag ...
>

The issue here is that the receiver sets SO_(PASS|PEER)CGROUP, forcing
the sender to identify or authenticate itself.  The sender might not
want to identify itself.  Even if you don't buy any secrecy arguments,
the sender might not intend to authenticate.  Certainly no existing
callers of connect or write intend to authenticate using their cgroup,
since current kernels don't have those semantics.

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