linux-kernel - Re: [KERNEL] Re: [KERNEL] [PATCH] 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:	Wed, 11 Nov 2015 05:54:41 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Andy Lutomirski <luto@...capital.net>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	Kees Cook <keescook@...omium.org>,
	Christoph Lameter <cl@...ux.com>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Richard Weinberger <richard.weinberger@...il.com>,
	Austin S Hemmelgarn <ahferroin7@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks  security in
 systems  using  capabilities

On Wed, Nov 11, 2015 at 11:14:34AM +0100, Klaus Ethgen wrote:
> > If you are going to do that level of auditing, then
> > you can also check to make sure it's not trying to explicitly
> > manipulate the processes's capability mask to set the bit in the
> > ambient capability mask (which is just another malicious use of the
> > capability).
> 
> Well, you audit one version. What if the developer sees: "Oh, there is
> one new shiny thing in kernel, called ambient capabilities. Lets set
> them to all my capabilities. That looks great", after you audited the
> code..?

But the developer can also change what files they look at; in fact,
they are *more* likely to make that kind of changes during the normal
course of development; not deliberately or maliciously, but as part of
adding a new feature to their program.  If you don't have time to
audit to make sure they aren't using some new capability feature
(which you can do using the simple application of "grep"), you don't
have time to audit to make sure they haven't changed something which
will cause their use of CAP_DAC_OVERRIDE to be dangerous.

Which is why I maintain it is very wierd that you are paranoid about
the first concern, but are blithely unconcerned about the second,
which is more likely.  And it is *because* you are the one who have
this extremely strange and selective paranoia, and most other people
won't, it seems fair (to me) that you are the one that has to pay the
extra cost of working around the problem.  After all, if you're this
paranoid, you must building all of your binaries from scratch, too.

(Or else you have to trust lots of package maintainers or distro
release engineers.  I'll remind you that some of the more catastrophic
security problems have come from Debian maintainers, some of which
made patches in code they didn't completely understand, and which had
nothing to do with elevated privileges.)  So the cost of patching init
to set the securebit should be in the noise for you.

Cheers,

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