Messages in this thread | | | Date | Fri, 6 Nov 2015 14:58:36 +0100 | From | Klaus Ethgen <> | Subject | Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities |
| |
-----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@ethgen.de> 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@Ethgen.de> 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-----
| |