[cap-talk] Unix FDs as capabilities, preventing socket creation,
kerberos etc?
John C. McCabe-Dansted
gmatht at gmail.com
Sat Nov 26 01:44:59 EST 2005
On Saturday 26 November 2005 06:48, Rob J Meijer wrote:
> I'm all rather exited about the possibilities of using
> unix domain socket filehandles as capabilities, and would like
> to try and use the concept in some of my private projects.
> But now looking at using the concept in a design, I'm running into a few
> issues, that I hope maybe someopne on the list would have some usefull
> thoughts about.
> 1) Using suid and chrootuid in process bootsttrap makes it possible to
> give a single process part of the users authority. Using uid based
> firewalling makes it possible to take away networking from a user id, so
> far so good, but how about the two together, giving a process part of a
> users disk access, but disabelling its networking without breaking the
> users networking? Is it in unix in any way possible to have a process drop
> its possibility to create new sockets?
The way systrace does it is to run the process in debug mode and trap
syscalls, and only allowing certain syscalls with certain parameters to
succeed.
> 2) When bootstrapping the basic interconnection process and socket
> infrastructure, initialy authentication is essential. With normal
> networking we have kerberos to take care of that, but over a tcp/ip socket
> we can not
> comunicate filehandles. Does anyone have any notion on how one could
> integrate kerberos and the bootstrapping of a unix domain socket based
> capability system design?
As I understand, capabilities typically remove the need for other access
control mechanisms, If a capability is passed into an object then it has
rights to it with no need to double check against a rights lists or
authentication protocol.
>
> T.I.A.
>
> Rob J Meijer
--
John C. McCabe-Dansted
Masters Student
More information about the cap-talk
mailing list