Messages in this thread | | | Date | Fri, 2 Apr 1999 17:46:52 -0500 | From | linux-kernel@progress ... | Subject | Re: Subject: Re: ext3 to include capabilities? |
| |
On 1999-04-02, "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(); > } [snip]
> The above _is_ "real capabilities". It can be more if desired:
> euid = (left as the user) [snip] > I_priv = CAP_FOO, CAP_USEFUL_THING, CAP_STUFF
> In the above, I set two of the four UIDs (to different values), > added 3 extra groups, and changed capabilities.
I think something which causes most people to react negatively to this scheme is that they have huge issues wrt overloading the longstanding behavior of 'setuid root == runs with root privs'. I see why Albert wants to use the root +s bit to mark capabilities-using binaries; it will be easy to support w/existing file tools, etc. But still, u+s files owned by root are scary, for good reason -- perhaps we don't like the ramification that if this system is rebooted to another kernel, or its filesystems NFS mounted by a box that doesn't support capabilities, whatever. Scary, messy things will eventually happen in a scheme like that.
So... who says the +s, capability-enabled binaries need to be +x ?
Trying to execute a setuid, non-executable binary on a machine that doesn't support capabilities should be meaningless and therefore harmless, no? (unless there some existing significance of u+s, u-x files, like +t on a file, whether POSIX enforced or simply convention.)
if (is_noexec) { if(setuid){ if(root_owned && cap_header) use_cap_header(); else meaningless, EACCES or whatever as usual else normal no-capabilities setuid/nonsetuid, whatever
Of course this means that the binary will not run at *all* on non-capable systems (no pun intended). But from the reactions of Alan, sct, Sumner, etc, I have a feeling that would be preferred (and I'd agree). If it's important to make a box that can switch back and forth, you can shell script around which tools/daemons are fired up, etc.
Hank Leininger <hlein@progressive-comp.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/
| |