> -----Original Message-----
> From: Albert D. Cahalan [mailto:acahalan@cs.uml.edu]
> Sent: Wednesday, June 14, 2000 7:09 PM
> To: Joseph Gooch
> Cc: 'Albert D. Cahalan'; linux-kernel@vger.rutgers.edu;
> 'Jesse Pollard'
> Subject: Re: Ke: Process Capabilities on 2.2.16, Sendmail problem
> revisited
>
>
> Joseph Gooch writes:
> > [Albert D. Cahalan]
> >> Jesse I Pollard, II writes:
> >>> "Albert D. Cahalan" <acahalan@cs.uml.edu>:
> >>>> Jesse I Pollard, II writes:
> >>>>> Pavel Machek <pavel@suse.cz>:
>
> >>>>>> Fine. You have no problems with elfcap, then. Noone has
> >> setuid 0 bit,
>
> Woah! Watch that word wrap. I'll try to fix the latter wraps.
I have a big screen :)
>
> >>> [snip -- about using UID 0 as a normal user]
> >>
> >> I'm sure it works "fine" until an app screws up. The world is
> >> filled with code that assumes UID 0 is special. You aren't serious
> >> about security until you stop allowing UID 0 processes.
> >
> > No argument here. Only problem being last I knew, elfcap only
> > allowed you to drop privs, not elevate them. Elevating caps
> > implies uid 0. By needing setuid root for a capability aware
> > program you're depending on uid 0 anyway.
>
> There can be no distinction. Think about it.
>
> The above all happens within the kernel, before any user code runs.
> It doesn't matter if the kernel sets all capability values to
> something insane, like (uid+gid)/jiffies, as long as they are
> correct when the executable actually starts to run.
If elfcap only drops caps, how do you get the capabilities to give
executables caps? At this point we have a solution for "fs caps" so we can
turn off the legacy emulation, but there has to be a way to elevate privs.
> One might patch the kernel to panic if root ever tries to run
> an elfcap executable. This should be a "can't happen" issue.
I.e. only honor elfcap if ruid!=euid? Sounds reasonable.
> >> Eh... so should creating a capability-enhanced program under
> >> your preferred design. Exceptions must be made in either case,
> >> otherwise you couldn't even install the system.
> >>
> >> See, you had made some claims about suddenly having privileged
> >> executables on the system. That just won't happen, except due
> >> to errors that affect both elfcap and your preferred design.
> >
> > No capabilities will be passed on from distributed files if
> > they're in the filesystem. Anyone can modify the ELF header.
> > (well, anyone with write access, but they need not be privileged)
> > They may not be in effect until run by root, but they're still
> > there, a time-bomb waiting to happen.
>
> This makes no sense at all. Why do you have root on a system
> that is supposed to be using advanced security? Since you do
> have root, can't you at least avoid running random trojans?
> Never mind the capabilities issue! I want to know how you expect
> to avoid a simple "rm -rf /" embedded in one of the trojans
> that your root user likes to execute. Root owns a few files,
> else you'd have no reason at all to play with the account.
By using elfcap you're still assuming there's a superuser that's going to
give you a full capset that you can later drop caps out of.
Granted, running random things as root is a bad thing that doesn't happen
often. :) Then again, many distributions have 5 times as many setuid
executables as I'd ever consider running.
> >>> Users should not be able to create setuid files.
> >>> Users should not be able to assign capabilities.
> >>
> >> No problem.
> >>
> >> With elfcap, inability to create setuid files implies inability
> >> to assign capabilities. Even better, inability to create files
> >> owned by root also implies inability to assign capabilities.
> >> An attacker would have to do both, to the same file, at
> the same time.
> >> If random users can do this, you have a problem even
> without elfcap.
> >
> > Elcap implies that someone can assign capabilities to any file
> > they have write access for. They aren't active until run by
> > root or suid root. I can see a whole slew of symlink or /tmp
> > issues comin on...
>
> Look, you need to close the MAJOR security holes first.
> Capability bits, in any form, do little good when you
> have wide open holes like:
>
> 1. random writeable files run by root or suid root
> 2. root running random files in /tmp
> 3. root using unsafe file creation in /tmp
>
> Hey, the other system has the SAME "problem" you know:
> ...aren't active until [...] SOMEBODY ENABLES THE BITS.
> You seem to think setuid bits randomly turn on... well,
> then filesystem-based capability bits have the same problem.
The point is that you can change embedded capabilities in elfcap
executables, but not in the inode. Suppose you're using a binary
distribution that's meant to run as root. Who knows what kinds of elfcap
info it has.
Granted being a responsible admin always wins. Worst case scenarios are
your friend though.
> >>> And the proposals to use ext2 or
> >>> XFS to store capabilities in the inode are practical, and secure.
> >>
> >> Security is reduced because existing admin scripts will not find
> >> the XFS or ext2 extensions. Capability bits have enough trouble
> >> with compatibility just by design; filesystem hacks make
> them worse.
> >
> > Existing admin scripts will not find elfcap capabilities either.
> > It'll find the setuid bit but not capability problems.
>
> Yep, that is good enough for an alert. Assume the worst.
For the same effort it takes to retrieve the file listing and permissions,
you can easily get the capabilities if it's in the file system. (in a scan)
With elfcap, you'd have to open and parse every file on the system.
> >>> Any filesystem should work with root privilege (well...
> >> excluding dosfs).
> >>
> >> The in-memory system would even work with dosfs.
> >
> > Only if you ran it as root (no suid bits :))
>
> Nope, the in-memory system is not related to elfcap.
>
> The in-memory system works like this: at some early point during the
> boot, before entering secure mode, you load a list of privileged
> executables into the kernel. This list indicates what capability
> bits each one should have. The kernel then opens each file. Once in
> secure mode, the listed files are protected. The files act as if
> they had filesystem-based capability bits and the immutable bit.
> These files, and only these files, are your privileged executables.
Oh. Neet. I like it as a mmapped file like Jesse said.
> > Here's a question. Is there any reason why we can't do both?
>
> Not "both", but "all three", unless you exclude filesystem hacks.
> I have a reason why not: ext2 filesystem stability.
Sure, all three.
Then you don't have to use the ext2 option in your kernel. :)
Joe
-
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 : Thu Jun 15 2000 - 21:00:33 EST