[cap-talk] [tahoe-dev] Fwd: Don't put capabilities in argv?

Rob Meijer capibara at xs4all.nl
Sun Jul 13 06:04:59 CDT 2008

On Sun, July 13, 2008 11:37, Toby Murray wrote:
> On Sat, 2008-07-12 at 19:59 -0600, zooko wrote:
>> But I guess I'll probably get comfortable with having all caps on the
>> tahoe
>> command-line represented by their aliases instead of by the actual
>> capability.
>> I really like the Python motto: "There is only one way to do it.", so
>> I'm
>> inclined to try to make the aliases mechanism good enough for most
>> purposes and
>> deprecate the caps-on-the-command-line mechanism entirely.
> Zooko, are tahoe "aliases" petnames for capabilities?
> That would appear to be the best way to go about providing a safe way
> for users to manage their capabilities.

This confuses me.
Wouldn't the ability to use petnames between entities imply a shared
scope? If so it would seem like the medicine would be worse than what it
is trying to cure.

The only good solution im my view would be to deny /proc/$PID access other
than /proc/self to all non root processes, unless that process has some
way to 'prove' its userness.  For a MinorFs style solution this would mean
that for example 'ps' would just like 2rulethemall need to ask a password,
although I am not quite comfortable with passwords as proof of userness.

I feel some treegraph would need to be constructed where the root of the
tree holds the user her userness, that can be decomposed so the user could
grant the ps program for example sufficient privileges to access the
/proc/$PID information it needs, but a random program could not invoke ps
with such a cap and thus would not be able to list information of other
processes than itself.

The LSM framework provides sufficient hooks for limiting /proc/$PID
access, and SELinux/AppArmor would already be usable to create  profiles
to do so, and to give extra privileges to special deputy replacements of
programs like ps.

I feel solving the problem at its root is the only viable solution. That
is, use AppArmor or a custom LSM to prevent non root non deputized access
to /proc/$PID. Introducing shared scopes where 'weak' petname references
are uses for delegations is I feel worse than what it is trying to solve.


More information about the cap-talk mailing list