netdev - Re: [PATCH 5/5] net: Use netlink_ns_capable to verify the permisions of netlink messages

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: <87ioow6pt6.fsf@x220.int.ebiederm.org>
Date:	Fri, 23 May 2014 16:25:09 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Jiri Benc <jbenc@...hat.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Miller <davem@...emloft.net>,
	"Jorge Boncompte \[DTI2\]" <jorge@...2.net>,
	Vivek Goyal <vgoyal@...hat.com>,
	Simo Sorce <ssorce@...hat.com>,
	"security\@kernel.org" <security@...nel.org>,
	Network Development <netdev@...r.kernel.org>,
	"Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: [PATCH 5/5] net: Use netlink_ns_capable to verify the permisions of netlink messages

Jiri Benc <jbenc@...hat.com> writes:

> On Wed, 7 May 2014 16:45:10 -0700, Andy Lutomirski wrote:
>> It looks like Zebra is mucking with its effective set.  It creates the
>> socket w/o effective caps, raises them to bind (no clue why), lowers
>> them post-bind, then raises them again to sendto.  Presumably the new
>> checks cause the sendto to fail b/c the socket()-time credentials were
>> insufficient.
>> 
>> I don't see why it bound w/ elevated permissions, since I don't think
>> this is important.  And it never connected at all.
>> 
>> Hence my suggestion that we check permissions at connect time instead
>> of socket() time and that we just check send-time permissions on an
>> unconnected socket.  Yes, this is awful.
>
> AFAIK this is still unresolved and this seems to be the only solution
> proposed so far that fixes the security problem and does not break
> zebra. Or have I missed something and the conclusion is zebra needs to
> be modified to comply with the changed semantics?

I have not seen consensus that what Zebra is doing makes sense to
support.

What Zebra is doing (opening a socket without privilege and then sending
privileged messages over that socket) smells.  This is effecting
performing trusted operations over an untrusted channel.

I can not see why that would ever be a desirable application
architecture.

There is also historical precedent for what the kernel is doing as it is
effectively checking SO_PEERCRED.

Furthermore I have not seen even a bad implementation of a way to
remember who called connect, and the possibility of needing different
permission checks for send vs sendto makes any implementation I can
think of nasty and ugly.  Which generally translates into complicated
and not secure.

So short of someone having a better idea it looks like Zebra is broken
until it is patched to open sockets with privilege when Zerbra is going
to send privileged messages over those sockets.

Eric

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