Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: Subject: Re: ext3 to include capabilities? | Date | Fri, 2 Apr 1999 23:20:21 -0500 (EST) |
| |
Santos Halpar writes: > 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,
One doesn't give capabilities to random executables. One uses them in place of existing setuid-root settings. Consider this program:
-rwsr-xr-x 1 root root 14148 Jan 10 1998 /bin/ping
Right now it is setuid-root, with full capabilities. With my proposal, it gets far fewer capabilities. If you revert to the old kernel, you should get the old security.
You really need a setuid-root setting that is ignored by newer kernels, so that you can still run an old kernel with traditional security. Without this, /bin/ping and others won't run on old kernels.
> which opens up the security holes I'm concerned about > when running the most stable (for the moment :) and secure kernel.
No, you get back the old holes (if any) when you run an old kernel.
> 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.
Of course, a buffer overflow would still grant root and full capabilities. (mount an ext2 floppy with privileged executables)
BTW, this is Red Hat 5.0 mount: -rwsr-xr-x 1 root root 34424 Jan 10 1998 /bin/mount
> 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.
It is a minor missing feature. You should not grant capabilities to executables you don't trust, and you should not run crummy old kernels. I had indeed assumed that you would only be reducing the capabilities that current setuid-root executables have, not granting capabilities to new poorly-trusted executables.
When replacing setuid-root with capabilities, you certainly do want a fallback to the old setuid-root system.
> 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).
The sticky bit would work fine over NFS. In that case, there must be a header flag to disable setuid operation. This is because /bin/ping and others must be setuid-root when running with an old kernel, but should not be root when they can just get the needed capabilities.
I prefer the setuid bit though, because it will be noticed by scripts that look for suspicious executables. It is much less likely that a script will notice an executable with the sticky bit set. (but this is still better than a strange new file attribute)
Well, which do people prefer? (sticky bit or setuid bit)
- 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/
| |