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

[Klaus Ethgen]

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

Hi Guys,

Am Fr den  6. Nov 2015 um 19:18 schrieb Serge E. Hallyn:
> On Fri, Nov 06, 2015 at 06:56:20PM +0100, Klaus Ethgen wrote:
> > Am Fr den  6. Nov 2015 um 16:53 schrieb Theodore Ts'o:
> > > In the light of that, using things like ambient capabilities, or using
> > > setuid binary that immediately drops all caps that it needs, is
> > > probably the best we're going to get.
> > 
> > I do never want that! Even to think about such a way to give any shell
> > raised rights is horrible! And that horrible idea is it that makes all
> > the ambient capabilities that bad.
> 
> I sympathize with your point of view, but Christoph's use case really was
> a good one.

I don't think so. Read on...

> A piece of system configuration software needs to do some
> networking setup with some privilege, including calling scripts.  It can
> either do so as root or not at all - polluting every program that will end
> up getting called with fI is not only ugly but simply doesn't work (because
> scripts).  Saying that the whole thing must be written as self-contained
> executable that never needs to be re-execed is frequently unrealistic.
> So this allows a piece of software to run with reduce privilege, and it
> is an improvement over the previous state of affairs.

Having some scripts in the process is definitively a nightmare to
control. That should be prevented wherever possible. And usually it is
as the scripts might be used for computing some values that are used
later in privileged stuff.

However, that usecase has one more flaw I think. It is the human nature.

Someone that create a tool made for running as root or especially SUID
is usually careful to do so. If they know right now that the tool is
never run as root, then they don't care about many thinks that needs to
get addressed for root stuff.

Good example are all that userspace python tools that throw all that
stack traces around the users ears (I don't know if that saying exists
in English...) instead of giving proper error messages.

> I would have been happy if there had been a default-off PR_ENABLE_AMBIENT
> prctl which required a new CAP_ENABLE_AMBIENT capability to turn on, but
> the current set of rules which removes bits from pA whenever doing an
> action which capability-aware software does something which it would have
> reasonably expected to drop privilege is a nice safeguard.

Well, not really. You can only prevent ambient capabilities to be given
to tools you don't want to have any capabilities by setting that tool
SUID or setting just one random capability for it.

By the way, guys, can we start to _not_ add every one in this discussion
to the Cc? Currently I get every mail twice. One from the list and one
from Cc. I still leave all Ccs intact with this mail but I would prefer
to just reply to the list. If anybody is not reading the list and would
like to get the mail, please insist.

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

iQGcBAEBCgAGBQJWPdpRAAoJEKZ8CrGAGfasAaUL/jLZg82kUfL5ByyZ5bUINxvY
kTRIaUTkgSRwkMQF5p+ILkVajE/YVAfD4MZFdZrB62PNbhvvCdy4R9jefVPcBlae
CTJuaDguWr2UZvPX6C25l2Q/ix2v9K2zOlgbhf23piXisfdLD3b1i6YlpYAJ4MRU
gakxTWylYCUhIt2j6dzlxPGN691o3q59kLa+1wCBXcMXr4gB8i93NjAloS6/ud+/
tC+6Ld+tbJFjoG/3HJ6qBCabaz41HVFnSPPQBohv19lSM1oDjUvH6wO9QGHBxYNN
S8IrBPrsINjm2l4kbNqUexIA+GGn7uPYO1SLjWl/VxfiegT5DfwArYakzsSnpQS/
Y30RlKJHSwl+nP/dxxN2kaqmrrmppcvh0HemKvnJX75UwZ/ROw7ACVCcGZQIqlUs
FssHB/lw48fhMQ5/WYjVRXBIQdbN1tmj9s6r22Vwez4sNst2ak4F+zO7NLwuYwmY
AstL8IyovKSHT52jsASydFBZ4PpG2PsPkZIRIUTLDQ==
=5Iab
-----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/