Messages in this thread | | | From | Andy Lutomirski <> | Date | Mon, 2 Nov 2015 10:50:16 -0800 | Subject | Re: Kernel 4.3 breaks security in systems using capabilities |
| |
On Mon, Nov 2, 2015 at 10:38 AM, Richard Weinberger <richard.weinberger@gmail.com> wrote: > CC'ing patch authors. > > On Mon, Nov 2, 2015 at 7:06 PM, Klaus Ethgen <Klaus+lkml@ethgen.de> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> Hi, >> >> 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.
>> >> 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.
--Andy
| |