linux-kernel - Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities

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, 5 Nov 2015 08:19:32 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Klaus Ethgen <Klaus+lkml@...gen.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Richard Weinberger <richard.weinberger@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Christoph Lameter <cl@...ux.com>,
	Andy Lutomirski <luto@...nel.org>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	Kees Cook <keescook@...omium.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems
 using capabilities

On Thu, Nov 5, 2015 at 2:19 AM, Klaus Ethgen <Klaus+lkml@...gen.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi,
>
> sorry for the delay.
>
> Am Mo den  2. Nov 2015 um 20:45 schrieb Andy Lutomirski:
>> > Well, the think that changed is that the ambient capabilities can be set
>> > by any process if the pI and pE are matching for a process. But then,
>> > that capabilities are inherited via execve to even programs that don't
>> > have any capability setting. That allows every subprocess to (mis-)use
>> > it.
>>
>> That's true.  I don't see why it's a problem, given that the parent
>> can already use or mis-use it however it wants, and the child won't
>> get the capability without explicit action by the parent.
>
> Well the parent can but usually is not aware of to what it gives this
> ambient capabilities to.
>
> Exactly here is the point. There are many applications out there that
> needs to be SUID root. Many of them only cause the developer has
> something inside like "if getuid() != 0". So in future I suspect many of
> such tools that even don't need to give capabilities to childs, are
> setting all available capabilities in ambient capabilities before
> starting do do something.
>
> With the present way, that was no problem (for OSS). You take away the
> SUID, set the capabilities and if the tool complains about not being
> root, look into the code and remove that stupid thing. With ambient
> capabilities, no one will see that the tool is doing such stupid thing
> as setting all capabilities unless some trouble is seen.

SUID is, always has been, and always will be a minefield.  People
writing SUID programs need to do it right.  When the kernel adds a new
API, doing it right includes not adding a buggy call to the API.

The ambient capability code explicitly zeros pA when running a SUID
binary to avoid problems in which a SUID binary has unexpected ambient
capabilities.

IMO the right long term solution is to just stop using SUID and to
stop using any other mechanism that grants new privileges of any sort
when execve is called.  (Windows already works like that, and it's
never been a problem.)  When you can boot a distro with no_new_privs
set everywhere (including init) and everything works, then I'll think
we've made considerable progress.

In the mean time, developers of SUID and similar programs (including
anything with file caps and a whole bunch of stuff under SELinux, etc)
need to be very careful.  Ambient capabilities don't change that at
all.

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