linux-kernel - Re: [KERNEL] Re: [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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 5 Nov 2015 11:01:07 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Klaus Ethgen <Klaus+lkml@...gen.de>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	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] Re: [KERNEL] Re: Kernel 4.3
 breaks security in systems using capabilities

On Thu, Nov 5, 2015 at 9:48 AM, Klaus Ethgen <Klaus+lkml@...gen.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Am Do den  5. Nov 2015 um 18:34 schrieb Serge E. Hallyn:
>> > Am Do den  5. Nov 2015 um 17:15 schrieb Serge E. Hallyn:
>> > > I think if you follow your idea to its logical conclusions, you end
>> > > up wanting set SECURE_ALL_BITS | SECURE_ALL_LOCKS, which will include
>> > > SECURE_NO_CAP_AMBIENT_RAISE, disabling ambient capabilities.
>> >
>> > That I did miss out and seems to be the solution for the problem. So
>> > adding cap_secure_all_bits,cap_secure_all_locks=ep to every binary that
>> > gets other caps should solve it?
>>
>> No that doesn't work, you have to use prctl to set those bits.  If you
>> can get your system to be fully rootless, you can have init or initramfs
>> do this for you.  It'll mean that root and setuid-root binaries have no
>> automatic privileges beside owning host (proc/sys) files.
>
> So this is not helping much. But for me it is at least an idea to how to
> have abient capabilities _and_ full control for admin. It would be an
> un-capability but at least would allow the admin to change the
> behaviour.
>
> Another one, that would be much better would be something like
> cap_ambient_cap capability to explicitly allow the use of ambient
> capabilities.
>
> I have to say that I do not know much about prctl. Just reading the man
> page currently. But this seems to be about the second way of taking away
> rights from UID 0 instead of explicitly giving rights to selective
> binaries.

OK, everyone, take a deep breath please.

Somewhere very high up on my personal list of generally applicable
security advice: do not turn security knobs for the warm fully
feelings.  Let me repeat that in all caps: DO NOT TURN SECURITY KNOBS
FOR THE WARM FUZZY FEELINGS.

When a whole bunch of us designed and iterated on how ambient caps
would work, we were very careful that they would *not* break
pre-existing assumptions that SUID programs could make.  Securebits
are very different: they very much do break pre-existing assumptions.
See, for example, CVE-2014-3215 [1], which is a local privilege
escalation made possible a because setuid binary turned security knobs
for the warm fuzzy feelings.

So, no, barring a really good reason and a very convincing argument
about why it would be safe, I won't ack any attempt to add xattr knobs
to change privilege evolution rules like that.  If you really want to
turn knobs to make your system feel safer and be safe at the same
time, please learn exactly what all the knobs do first and, while
you're at it, please think carefully about how they interact.

--Andy

[1] See http://openwall.com/lists/oss-security/2014/04/29/7 and much
related discussion
--
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/