lkml.org 
[lkml]   [1999]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.047 / U:0.612 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site