Re: Kernel 4.3 breaks security in systems using capabilities

[Andy Lutomirski]

On Mon, Nov 2, 2015 at 10:38 AM, Richard Weinberger
<richard.weinberger@xxxxxxxxx> wrote:
> CC'ing patch authors.
>
> On Mon, Nov 2, 2015 at 7:06 PM, Klaus Ethgen <Klaus+lkml@xxxxxxxxx> 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
--
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/