Messages in this thread | | | Date | Fri, 17 Dec 1999 14:01:01 +1100 | From | Martijn van Oosterhout <> | Subject | Re: [RFC] Giving capabilities to users and groups |
| |
peter swain wrote: > i was about to reply to the author of the 32bit uid patch, > thinking that this should not change lightly, but should > wait until some discussion on extensible authorization spaces.
Interesting idea, though I'm not sure if I'm understanding you right. Do you have anything places that describe this in more detail?
> 'scap' is one of the forms i'd expect this to embrace, > with a 64bit (or more??) capability space which maps down > to a 16bit {User,Group,Vol,Session,Xaction,...}Id when queried > thru the old interfaces.
Here I'm confused. There is no one-to-one mapping between userids and capabilities. Do you mean that each {user,group,etc}id has associated with it a set of capabilities which go beyond just the simple bits in the capability structs. Then you extend the fd passing machanism to handle passing of any of these around.
> treat this like the move from IPv4 to IPv6, where several > sub-namespaces Embrace & Extend (TM) the old ID space. > designing a fully secure ID space which can serve all needs > is a real can of worms, and we should explore/consult before > unsettling linux/glibc futures by another little change, > when the same porting hassle can be delayed until we get > a more powerful featureset in place (as long as it can be > seen to have a minimal bugset).
This program, afaics, will not require any changes to any other programs. I want it basically so I can add 'exec scap NET_RAW' to my .bash_profile so I can test all my networking programs and run tcpdump without having to open a root console.
> i'd be interested in exploring such things. > Some possible features include: > * 16bit uids are represented internally (when id16to32() mapping > is applied) by an (id, time, rights) tuple, so anything uttering > an old id16 can encapsulate a snapshot of its intention. > Imagine 'kill -TERM --capability 3456' returning a string which > will enable the holder to SIGTERM the *current* proc 3456 at any > time in its life, but not any future proc 3456 (after 2^16 more > forks have wrapped the pidspace).
So they can kill the process even if it changes its userid? This would probably require some encryption to prevent people faking the strings.
> * such alien id-spaces as Win32/NT ids, NFS-handles, (dev,inode) pairs, > yadda yadda, could be candidates for wrapping in some subspace of > IDng (TM,GPL) capabilities > * possible merge of capability-spaces, routing-spaces, fd-space, > into some kind of simple computational structure > * incorporate Beowulf clusterwide-mock-PID extensions
Sounds like what you really want is the separation of userids as an identification mechanism and the rights granted by that. So the user has a userid and associated with that they have an NT id, a set of capabilities and other such things, all of which give rights to certain objects.
> * have a small cache of translation/authorisation entries which > (on some architectures) get hardware assist (x86 task/entry/... gates, > MIPS TIDs, whatever), but not at the expense of uglifying the generic > case.
Not quite sure what you mean here.
> * unify capability passing with the send-FD-over-socket stuff > * unify capability handling with FS ACL handling
I've always thought it would be nice if you could send UIDs, GIDs and other such things over a socket. You could then abstract this whole thing to a user-space daemon (capd? authd?) which the login script could connect to and be given all the approprite rights.
> * unify capability handling with fairshare scheduling (such as Aurema's > forthcoming ShareII port to Linux, and a freer project which developed out of > bandwidth-allocation research, but whose name escapes me)
No idea what you mean here.
> has anyone beaten this topic to death as infeasible, > or should we try now???
I've no idea. Is this the kind of security models they use on mainframes?
Martijn
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |