> David L. Parsley writes:
> > On Thu, 15 Apr 1999, Albert D. Cahalan wrote:
> >> David L. Parsley writes:
> >>
> >>> Well, the stickybit/immutable solution has been modified so that it can
> >>> be compatible with local fs tools, but is still not completely secure with
> >>> remote fs's. Still, nfs at least should understand the sticky bit, and if
> >>> you can trust the security of the sticky bit on the remote system, it _is_
> >>> possible to use caps with a mount option.
> >>
> >> Ugh. Immutable does not survive backup and restore. The sticky bit
> >> is not even secure on a Linux 2.2 server.
> >
> > Then you haven't been paying attention, Albert. After the modification, a
> > 2.2 kernel will interpret 'chmod +t' as 'capability enable'; this will
> > require the current process has CAP_SETFCAP, and on success will set
> > _both_ sticky and immutable on a local fs. (or just sticky on remote).
> > Otherwise neither is set.
>
> I have a 2.2 kernel right here, and it does NOT require CAP_SETFCAP to
> change the sticky bit. Oh, you plan to patch the kernel? Of course you
> do,
Yes. Completely secure on local fs's.
> but you can't ensure that every NFS server in the world will be
> patched as you wish.
No kidding. If you're running with this new security model, you should
re-think running system binaries over nfs. This, btw, is not just my own
opinion.
> The NFS client has no control over this. Using the sticky bit as a
> flag is just absurdly bad.
I've tried to avoid using 'bad' unless I was saying something like
'marking named(8) is bad', which is obvious. You have to say _why_ it's
bad if it's not obvious. It only seems so obvious to you because you
haven't really given more than a few second's thought to the solution,
evidenced by your misunderstanding about the immutable bit relationship.
> You might as well use the world-write bit.
Now _that_ is quite obviously absurdly bad.
> Imagine a Linux distribution that had this misfeature. It gets installed
> on some new systems on the network. I sit down at my old Linux box,
> make a nice executable, telnet to a new box, and do bad things. Yow!
What the HECK are you talking about? You sit down at a Linux box that is
exporting /usr to a new box? Then you edit the binaries on /usr (or
create new ones) that do bad things on the new box? If you can do that,
then you might as well just create a whole fleet of setuid-root binaries.
If you can't trust the /usr on another machine completely, you damn well
shouldn't be mounting it over nfs!
> > If 'doesn't implement capabilities correctly' isn't a showstopper for you,
>
> We currently have a 'doesn't implement capabilities correctly' situation,
> for many definitions of 'correctly'. (no on-disk support)
Again, what the heck are you talking about? Whether we use the immutable
bit that's ext2 specific, or new caps metadata in ext3, you get the same
end result!!! (except that using sticky/immutable won't break current
tools, a major benefit)
> The setuid-root solution is a large improvement. Good. I'll not worry
> that it doesn't offer all theoretically possible features.
>
> I'll certainly prefer the setuid-root solution over the MASSIVE SECURITY
> HOLE caused by trusting remote executables with the sticky bit set.
If you're trusting remote executables that shouldn't be trusted, that is
just bad administration.
> The intent is to reduce security holes I hope, not to add big holes.
Yes. Please go read and think and understand why a mis-implementation of
capabilities is at best a small step forward in security, and a large step
backward for adminstrators who will one day have a correct implementation
of capabilities to work with. (ext3 + cap metadata)
> > So far, it seems that correctness and
> > flexibility are a whole lot less important than using the stupid setuid0
> > flag, which also has the severe ugliness of storing the uid and suid bit
> > in the headers.
>
> That is beauty, not ugliness. I can have 4 UID values if I want.
That's an abomination, and now you're screwing around with traditional fs
rights. Again, just _try_ to get this code in the kernel. No way.
> > I'll just wait for caps in the fs metadata, which will at least work
> > correctly although requiring updating a bunch of tools.
>
> Your "correctly" does not include NFS, iso9660, etc.
Yes, everybody knows this. Of course, an iso is by default immutable, so
you can safely burn a sticky bit capabilities fs on it, and so it works
right away, and preserves correct capability semantics.
setuid0:
- setting inheritable caps is a non-priviledged operation, but it should
be. (this means that, in many cases you have to remove all write rights
to the file, otherwise the file owner can always max-out inheritable)
- if you want to set permitted, you have to make the file setuid root;
setting permitted is a good idea for things like 'named' as I've shown.
- if the file is not setuid root, you use the uid and setuid bit from the
filesystem, otherwise you read it from the binary. this is an ugly break
in UNIX fs semantics.
Albert, in particular you don't seem to understand just how important the
inheritable bits are in a capability-based security system, and how bad it
is to not require setting them to be priviledged. Or at least, if you
want it to be priviledged, now you have to mark it setuid root.
Apparently it's time for me to do some coding, since logic has no meaning
here. I only hope that you won't license your cap setting utility 'GPL
except for David Parsley, who can neither use it nor even look at it.'
cheers,
David
- --
David L. Parsley
Network Specialist
City of Salem Schools
-
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/