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,

Am Do den  5. Nov 2015 um 23:08 schrieb Serge E. Hallyn:
> On Thu, Nov 05, 2015 at 11:01:07AM -0800, Andy Lutomirski wrote:
> > On Thu, Nov 5, 2015 at 9:48 AM, Klaus Ethgen <Klaus+lkml@xxxxxxxxx> 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.
> 
> Not exactly.  It's restoring the full unadulterated use of posix
> capabilities.

- -v

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

I never talked about capabilities _and_ SUID, I always talked about
capabilities _instead_ of SUID. I want to get rid of the SUIDs.

> > Securebits
> > are very different: they very much do break pre-existing assumptions.
> 
> ... thought i was clear about that.

What I read about, that ist clear for me too.

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

Hmm.. That is exactly what I fear about ambient capabilities too. Maybe
I am a bit more paranoid than the author of ambient capabilities but I
droved good with that paranoia level in the past.

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

Well, I think I have a good understanding about capabilities. I just
think that we talk at cross purposes.

I never ever talked about using capabilities in _combination_ with SUID.
That was brought to the line by others and, how I read the patch that
brought ambient capabilities in, the main reason for it.

But that left out completely the, I think more important, usecase of
_removing_ SUID completely and _replacing_ it with very tight capability
setting. And that is what I always talked about.

I did not know about that "security bits", shame on me. But I do not
think that they are any kind of solution for the problem that ambient
capabilities brought into the kernel. Nor do I think that they change
any about the second usecase I always talked about.

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

iQGcBAEBCgAGBQJWPLIGAAoJEKZ8CrGAGfaspF8MAKst2DUJ6id4VcPFZGbC6Koe
DROSPWJpZ2+5kW5q4hHX5+E+pQls3ipDwi0K+HyhqjTOXZbRC4Irv8RynbZBgvmN
C7wL2H9o+zjnK29XTlZf7Gr2nCYw/ct10CMtXm56OhIaZcEhb9yNDXa5X+wiPy+B
qVP8xGdFVORa7ziQnyv7j8TRMGejT3qkX+vxLB9bfX5KvuuBgg0X7JIVMqFET6By
HaKWAoVEWoRNbifbOiG0FRq7z8usXB0/5Yhz9u89n4MiGf14bQb4ivrJStIyMb4q
BxHZxQsEtf+wSpd4itoICdKl2vUO5J46mNc3vNvi0tCv1EKIff8HvQRjAYQYpYB9
Vn862aXUQlFrM5z7QjywhYH4que5Xs8PRP+zBsh2eVCZgecwkt7aUh+zK1FzBaWG
Rr+vYwZdObMYQjA3/1v4sQhJmINO0A5yGgLjRCSO1uirU+gjNScXRmGCyvidzaSR
eOlfcv34EfAxzDUrT/X7TSTph308W8s6y3Em9prbKA==
=8opp
-----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/