Re: file capabilities and inheritance

[Janne Karhunen <janne.karhunen@xxxxxxxxx>]

On Sat, May 12, 2012 at 10:53 PM, Will Drewry <wad@xxxxxxxxxxxx> wrote:

>> For example give init rights to execute shell with different capability set
>> than system developer shell and make this so that I would not have to
>> go patch ssh to drop the inheritable bits. WIth current capability
>> inheritance rules this is not possible as everything, including the shell
>> spawned by ssh, will automatically have same inheritable set than init.
>>
>> This should be doable easily if we would transform new inheritable set
>> just like permitted set;
>> P'(inheritable) = P(inheritable) & F(inheritable)
>>
>> So, just stamp sshd inheritable set with the set it is able to 'give forward'
>> and be done with it.
>
> Rather than redesigning capabilities, have you considered pam_cap.so?

That's for sure an option as well as an exec wrapper.


> Or looked at any of the related capsh tools? Your sshd launcher could
> drop inheritable bits and/or pam can do it on a per-user-policy basis.
>
> Perhaps you have, but it seems that the requirement to annotate every
> executable with the possible set of inheritable bits that may be
> desirable to pass on would be quite cumbersome.  For instance, you
> would also need to stamp /bin/bash and any of the subshell commands
> that may be run prior to use.  That may be acceptable to you, but it's
> not clear to me the specific benefits it yields over the current model
> (as painful as it may be :).

IMHO this would be:
1) Logically correct way for inheriting - child can never execute with
higher permissions than the parent through inheritance.
2) More secure - amount of capabilities we have to give away drops
and only smallest set can be assigned. No extra inheritable bits need
to be lifted anywhere where they are not needed.
3) More understandable - process tree branches can only reduce in
permissions as they get further from init. 'pstree' goes a long way
showing important and less important tasks.

So, I'm not even entirely sure it would be that much more complicated
to manage.


-- 
Janne
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html