Steve Dodd wrote:
>
> On Tue, May 02, 2000 at 11:01:38AM -0700, Linda Walsh wrote:
>
> [.. ugh, bad line wrapping, ugh <g>]
>
> > One of the requirements for this level of 'trust' is that audit actions be
> > able to be written corresponding to the appropriate 'authenticated' (as in
> > they gave a "password" (literal password or other biometric)). Currently,
> > none of the uid values can be guaranteed to remain constant for
> > a login session. Thus the luid fix.
>
> I'd rather see ruid "unbroken", but probably isn't possible to do this and
> retain compatibility. Other than BSD style euid<->ruid swapping (which
> could surely by fixed by a "local" kludge, rather a global one <g>), the
> issue is su and friends. I've never been entirely happy with the Unix "become
> someone else to do certain things" model; I'd much rather remain user "steved"
> but "assert" or "raise" particular privileges when I was going to something
> dangerous. Doesn't VMS have something like this? set proc/priv=xxx?
--- Linux has this in the kernel as well. The CAP set needs to be expanded to 64 bits and we need 1 or more file systems to support capability sets on files. Then we need the kernel to read and set CAPs appropriately. The problem is -- w/o filesystem support, or a CAP-process that can spawn a shell for a given user with a given CAP-set and connect it to their currently running session, ... (hmmm... sidethought: that last one should be doable in user-space with the current kernel, have a /etc/capabilities file for default and permitted for each user...etc). Eventually I think a minimal-privilege/capability based system is where we will want to go (at least support it as an option), but we aren't quite there yet. We're sorta stuck with the current paradigm until get farther along.I know Andreas Gruenbacker has a list (Linux ACL Developers List <acl-devel@bestbits.at>) that has expanded a bit to cover capabilities and MAC on ext2 using the acl-reserved word in the ext2-inode, but I seem to remember him talking about it being used by someone else under some circumstances (I think it was something to do w/large file support).
But you are right -- changing the ruid thing at this point would break alot of existing software...tres bad! Some of the shells -- like I think ksh and csh, perl too for that matter operate differently if ruid!=euid. They all think they are being run by an SUID wrapper or script and allow more limited functionality -- thus to make those work normally, su 'has' to set ruid. :-/
-l
p.s. -- sorry again about the lines...bad netscape on another machine defaulted to HTML composition and didn't notice until I was ready to send it....sigh.
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- 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/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:13 EST