Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities
From: Klaus Ethgen
Date: Wed Nov 11 2015 - 06:14:24 EST
-----BEGIN PGP SIGNED MESSAGE-----
Am Mi den 11. Nov 2015 um 11:54 schrieb Theodore Ts'o:
> 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.
The only thing you can do is to do all you can. And lowering SUID use to
selective capability use is one important step in that direction.
There is no way to have a all secure system. You can only do the most
Nevertheless, I object a _new_ feature that brings some security
concernes. So it is not uncommon, to work on that.
> 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.)
Thats true. For example openssh patching debacle just to support some
accomodativeness on the cost of security. Upstream refused that patch
but they still have it in debian. That was when I did start packaging my
own openssh package in my own "debian-security" repository. However,
that is a single package (in fact, I have a few there). With every
package that has to be fixed the load goes more in the direction of not
being capable anymore to handle it.
Also that discussion here is, especially from the fact that english is
not my main language, time-consuming. But I was thinking (and still
hope) that kernel developers are not that stupid than some debian
maintainers. I still hope that they are not so stubborn to ignore a
use-case that is already used by some out there and only focusing on a
use-case that is used nowhere.
> So the cost of patching init to set the securebit should be in the
> noise for you.
As it is to provide a patch that does it right. (As I did already.)
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <Klaus@xxxxxxxxx>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/