| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20151102191616.GA2158@ikki.ethgen.ch> Date: Mon, 2 Nov 2015 20:16:17 +0100 From: Klaus Ethgen <Klaus+lkml@...gen.de> To: Andy Lutomirski <luto@...capital.net>, Linus Torvalds <torvalds@...ux-foundation.org> Cc: Richard Weinberger <richard.weinberger@...il.com>, LKML <linux-kernel@...r.kernel.org>, Christoph Lameter <cl@...ux.com>, Andy Lutomirski <luto@...nel.org>, Serge Hallyn <serge.hallyn@...ntu.com>, Kees Cook <keescook@...omium.org>, Andrew Morton <akpm@...ux-foundation.org> Subject: Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, Am Mo den 2. Nov 2015 um 19:50 schrieb Andy Lutomirski: > >> I read recently about patch 58319057b7847667f0c9585b9de0e8932b0fdb08 > >> which made it into kernel 4.3 recently. And I have to say that I was > >> shocked on how could such a patch that breaks normal use of capabilities > >> make it into the kernel. > >> > >> Usually I have set very own crafted capabilities set to files instead of > >> having them SUID root. With that, I have a comparable set of inheritable > >> capabilities set for limited users. That allows me to nearly drop all > >> SUID binaries and replace it by only giving the processes the > >> capabilities they need but only if the users are allowed to act with > >> that capabilities. Especially, and that is important, it inhibit any > >> leak of rights to any forked process, be it indented or by a security > >> problem of the binary. > >> > >> With the patch above, any process that is spawned by such a program will > >> inherit the raised capabilities if it has no own filecapabilities set. > >> Even worse, even every user made tool can be target for such > >> escalations! That drives the benefits in security of capabilities over > >> SUID ad-absurdum. > > Can you describe what it is that you think changed in 4.3 that breaks > anything? The behavior of inheritable capabilities shouldn't have > changed. Well, the think that changed is that the ambient capabilities can be set by any process if the pI and pE are matching for a process. But then, that capabilities are inherited via execve to even programs that don't have any capability setting. That allows every subprocess to (mis-)use it. > >> Let me add here, that I disagree with Andy Lutomirski about the > >> usefulness of capability inheritance in kernels before that patch. They > >> was fully usefull to only allow selective capabilities if both, the > >> binary and the user was allowed to use it. I never want to have any > >> capabilities for processes that I did not allow them to have. Even > >> worse, I never want any capabilities allowed for any shell. It is > >> horrible to even think about such a possibility!. > >> > >>> Users with nonzero pA are unlikely to unintentionally leak that > >>> capability. If they run programs that try to drop privileges, dropping > >>> privileges will still work. > >> > >> Even that is naiv. There are only few programs out there that do > >> actively drop privileges. Most are agnostic about capabilities. But this > >> crappy patch introduce a need for _every_ tool to drop all capabilities > >> right after start to stay in a secure system. > >> > > I don't know what you mean. Concrete examples are welcome. Am Mo den 2. Nov 2015 um 19:52 schrieb Linus Torvalds: > >> With the patch above, any process that is spawned by such a program will > >> inherit the raised capabilities if it has no own filecapabilities set. > > Do you actually have a real example of this? Very simple example: ~> getcap =mount /bin/mount = cap_dac_override,cap_sys_admin+ei ~> ls -l =mount - -rwxr-xr-x 1 root root 40000 Sep 17 15:55 /bin/mount ~> getpcaps $$ Capabilities for `5509': = cap_dac_override,cap_net_raw,cap_sys_rawio,cap_sys_admin+i What allows me to use mount for mounting shares with user flag without the need of having a SUID mount. Nice and with a good security level. Even if the binary has some flaw that allows to exec some unrelated stuff, there is no harm as after execve, all capabilities are set to 0. With the alternative approach of having /bin/mount SUID root (as it is normally), root rights would spread to unrelated tools in such a case. With pA set (what can be even done in mount itself), the security problem would be the same as havin mount SUID root. > The ambient capabilities stay empty unless you explicitly raise them. > So your old workflow shouldn't actually have any change in it at all. Ok, As I understand, that pA has to be set explicitly but that doesn't prevent such problems. For example if someone has managed to break into my account (in the example above), he can set it himself. > And if your old workflow gave a capability to something you don't > trust, and that then decides to now uses the ambient capabilities, > what does that change? It had the capability already. Well, not really. With the former approach, the capabilities in pI can only be used with a specific tool that the admin allowed to inherit. With pA, every tool can inherit that. And please ask if I described something not understandable as my main language is not english. I even might be wrong in understanding the pA. but I don't think so currently. Regards Klaus - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <Klaus@...gen.de> Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQGcBAEBCgAGBQJWN7Z5AAoJEKZ8CrGAGfasHPcL/jmGC8tSMcxsSLnSB89rxEJf CaWVwxw+zlhSzaXgLRoip7VaXFMnKEjOfigQ7gehKAqg1lu4aIDmEznHKbGq20Eo o8FcXV7uqUlicEhmxLunYIjQeFWFip7JPvl1retbvOVsa1xqXVXXPOUZID+2e63S DbKG1lG4jRGVatW6xjHjOY56AHN0hErnG1g3ONBAz9Ri5QwfxC0UhVlopfSYy13x M20raMn0VedkJM4dbpOjGskakMij/5OmlY/t3tBiLBcFXS4JzQzkpYw2VJagLzfZ 9DDGIHA7+qTBWBDdy6ZEnR3QTbOozMUj0WBXa9dOukzLm+BtP6ik8v8DAdbdtJmx 6jn7WdMMXs4FpvmvT3y3MYeRm4Rn3qJNZTMe6b77RryzxLf5CIMTYW1rSr9bCRwp te6bA7IKmGoKbD2Ge4n5PqFVpoVVVqZN0SPiW2dO/cDQ7WM+hb6yEeeYdBlO1gF4 Hw3oPeCLkm0+6R//dqeq1Q6mtIgYxL45Nxlvh4uhpg== =qWwm -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists