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/