Messages in this thread | | | Date | Fri, 2 Apr 1999 18:33:26 -0800 (PST) | From | Santos Halpar <> | Subject | Re: Subject: Re: ext3 to include capabilities? |
| |
Albert D. Cahalan" <acahalan@cs.uml.edu> wrote: > G. Sumner Hayes writes: > > Albert Cahalan <acahalan@cs.uml.edu> wrote: > > >> 1. Put capabilities information in the executable header. > >> 2. Mark the executable setuid root. > >> 3. Have the kernel check for #1 if #2, and prefer #1 if present. > > > > Of course, you've completely busted up security. > > Nope, think about the system a bit more. It isn't so stupid. > > if(setuid){ > if(root_owned && cap_header) use_cap_header(); > else use_setuid_bit(); > } >
I understand that. Read my concern again. I don't understand how your system can possibly make my (already installed) 2.0.x kernel ignore the setuid bit. I have 2.0.x around for stability, so putting random patches into it isn't really an option. It seems like your system will run programs with capabilities on 2.2.x but full-blown setuid on 2.2.x, which opens up the security holes I'm concerned about when running the most stable (for the moment :) and secure kernel. :(
Correct me if I'm completely offbase WRT 2.0.x, though.
> > On my machine > > there's a crypto-daemon that wants to mlock() some RAM. I have a > > little setuid wrapper to give it mlock capability on 2.2.x, but > > I'm not about to let it run with full root privs -- under 2.0.x > > (or whenever it can't [SNIP] > > mlock()), it prints a detailed warning and lets the user decide > > whether the risk is worth the convenience of not typing passwords > > constantly.
To rephrase: the daemon would like to mlock if it can, but it doesn't want root priviledges. Currently, I exec it with mlock privs under 2.2.x. It always tries to mlock. Currently, under 2.0.x, it can't mlock -- no suid. So it prints a warning and lets the user make a decision.
Same thing with mount; I never let /bin/mount be suid, but I'd be willing to give it a mount capability (if there were one; full admin capability is a bit too much for my taste). So when 2.?3?.x is running, peons could mount/umount the floppy; with 2.0.x it'd be like it is now -- no mounting for non-root.
Same thing with a lot of binaries. There are only a handful of binaries that I trust with full suid under 2.0.x, but I'd be willing to give my users a few extra tools under 2.2.x if it didn't mean compromising security when booting under old kernels.
Basically, it seems like your system doesn't allow a secure fallback for 2.0.x machines. It promotes capabilities-having bins to suid ones under old kernels, which is a major bug IMO.
(second, less interesting portion of debate snipped -- adding EUID/ UID/FSUID/SUID fields to the header solves that problem in kernels that grok the scheme, but has the same issue of causing older kernels to grant suid root to binaries that only want limited privs).
Your idea does limit the fs data needed to one bit, and that's something I don't mind. Using the suid bit as you suggest is bogus, though. The sticky bit would work if it were limited to root, but that's not an assumption that's workable in an NFS environment (correct me if I'm wrong). _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
- 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/
| |