Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities

[Klaus Ethgen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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.

All right.

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

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

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

iQGcBAEBCgAGBQJWQyLcAAoJEKZ8CrGAGfasSH0L/1NLo4fxZoEL1PNDCKCcmlUW
8h3ThJhdNQqu8xRl47Q6RW/K7tv0My/blihNZEzIn6ssmTXd8JIlP3uHfz+XA2aZ
FbduAc2KOoW8H1ItYbWL4hnJq94/Pvp+0vOBMSG+fKL/09A8X8RmiAiCsnX6Eirl
64WCk1dyDILWPpkQ0w7XKy4DA69AX7DSBLpYCANwOsFzIZR0Npx3VinF55kVHE53
9g3x8+NifOLJ3qPkSwUg+U86AOWlQhnsI3EQJYwJ+WLnkrHEoKHvBlDDRqfNMoRK
c1IqgD9ISnjPf1PO+MQ2CQ0kE8VdTXNaZKU4PvFFzJJE1iAa2SgJjY/tXLgmHaQ/
RCs6RoJkZ/8VbpmOFcALNJuIIWjaG6GUii296MnvYPE2VnJXQ3NoUDsRlmA5jRBA
klmbWAOz5pBknx5AE8zjgAyHQ/trpNxHnW+OBtfhxqoohTIZJxHIDxZD6MuSNVVs
dw9MJf/pR6T4xN70H9oFG7eb7Ic3E92IFkSsM9Vvng==
=P+pQ
-----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/