[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cap-talk
Subject:    Re: [cap-talk] Delegating directories (previously: POSIX
From:       "Rob J Meijer" <rmeijer () xs4all ! nl>
Date:       2006-10-26 14:07:11
Message-ID: 15609.213.222.28.155.1161871631.squirrel () webmail ! xs4all ! nl
[Download RAW message or body]

>>maybe now would be a good time to see if POSIX capabilities
>>combined with the 'at' set of syscalls could not be extended in a way to
>>facilitate efficient and usefull mechanisms. [...]
>>
>>Do you guys think it viable to try to together write a proposal (and if
>>possible implement it as a patchset for linux) that defines
>>CAP_AMBIENT_AUTHORITY as POSIX capability, defining all the syscalls and
>>possibly syscall/attribute combinations that are covered by this?
>
> POSIX capabilities are a disaster.
>
> Finding some way to turn off all ambient authority would be interesting,
> though I don't see why it needs to be a POSIX capability (there would
> be many ways to communicate to the kernel that you want to turn off all
> ambient authority).

The inheritable/exec stuff of POSIX caps seemed like a good fit.
If you can execute an executable while both handing it an open
unix domain socket and taking away all of its ambient authority,
this would seem like a good fit.

> Have you looked at Linux seccomp?  You could view it as shutting off
> all ambient authority in a blanket way.

Do you feel it would be possible to achieve the abouve with seccomp,
it would seem to be rather difficult or even impossible, or am I wrong?

> Combining something like seccomp with file descriptor passing and a
> subset of the *at() syscalls might let you do something useful here.
> I could imagine building a pretty nice implementation of plash on top
> of that substrate.

I have had a look at the LSM stuff (that now are used for POSIX caps)
and tried to discuss the subject on their mailinglist. Seems like
they are not to fond of the idea of extending LSM with hooks to accomodate
anything POLA related. Maybe if someone more articulent than me could
raise the issue on their list we might have a change there?

> One challenge will be to figure out what to do about resources that
> aren't represented as files (e.g., network access).

I would think that 'bind' and 'connect' should be considered to imply
ambient authority and other calls should not. Given that you could hand
over a bound or connected socket over a unix socket, usage of these should
be quite clear. Finding a non ambient alternative to bind/connect may
possibly be solved by mapping ip/port information for these calls to a
pseudo filesystem using fuse.

As an alternative to dropping the full set of ambient implying system calls
in either a POSIX caps or seccomp (not sure about that one) way, I have
made a short draft document on a relatively simple pseudo filesystem for
file and directory delegation. This pseudo filesystem (D-GateFS) could
be implemented as a userspace filesystem at first, something I should be
able to alone if needed do with my limited time resources.
If anyone on the list has some spare time left to work on this small
project with me that would be great, given that my personal spare-time
resources are
rather limmited.


Rob

_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
[prev in list] [next in list] [prev in thread] [next in thread]