Messages in this thread | | | From | peter swain <> | Subject | Re: [RFC] Giving capabilities to users and groups | Date | Fri, 17 Dec 1999 11:54:55 -0800 (PST) |
| |
Sorry about my cryptic late-night post. i really should have attached this to the 32bit-uid thread.
'scap' seems like a well thought user-level encapsulation of the existing linux kernel capability mechanisms. I didn't mean by injecting a discussion of future kernel extensions, to dissipate your zeal for the project of making user tools for handling existing kernel-supported mechanisms.
The parallel with 'su' is a good one. Note also Jeremy Fitzhardinge's work on annotating ELF executables with a capability set, as a much finer grained version of the setuid bits. The two are complementary, 'scap' is to 'su' as ELF-caps is to SUID. Well, sort of -- see <http://www.goop.org/~jeremy/caps>.
The worrying thing about making capabilities this accessible is that it can lead to quick hacks using scap as a *tool*, which weaken system integrity -- augmenting a process's capabilities make it a target for cracking and spoofing from the unaugmented processes of the *same* uid. I leapt upon the 32bit uid extension as a means to grant different internal uids to different capability sets, thus breaking the relationship of trust, and forcing same-public-uid processes with different capability sets to go through some lengthier authentication process before signalling/examining/meddling with each other.
But such complexity is against the spirit of linux...
> 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.
"Martijn van Oosterhout wrote:" > Interesting idea, though I'm not sure if I'm understanding > you right. Do you have anything places that describe this > in more detail?
not yet. i was just waffling on possibilities. i'll drag my original outburst back to the 32bit-uid thread when i've added a little more meat/sleep to it.
^..^ (oo) www.pobox.com/~swine
- 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/
| |