>>>> 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.
Woah. Stop right there. You plan to _automatically_ set the immutable
bit when the sticky bit is set? If a copy or unpack an executable with
the sticky bit set, I won't be able to remove it? Oh crap!
If sticky alone is good enough for a remote filesystem (it is not),
then why bother with the immutable bit at all? This makes no sense.
>> 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.
This is not acceptable.
>> 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
OK, using the sticky bit as a flag is just absurdly bad because it
lets anyone with access via Irix grant themselves full capabilities.
> haven't really given more than a few second's thought to the solution,
> evidenced by your misunderstanding about the immutable bit relationship.
I'm not some kind of vegetable you know... (rudeness not appreciated)
While I think you are terribly wrong, I acknowledge that you have given
more than a few second's thought to the solution. I have too.
>> 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?
Forget /usr, anything will do. Consider /projects/trauma instead,
where local users are developing a game that needs CAP_SYS_RESOURCE.
The server runs Linux 2.2 or Irix.
There is a Linux 2.2 or Irix client with read-write access.
There is a patched Linux client.
Alone, none of the machines have a security problem. Access to both
client systems creates a severe hole.
> 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!
I can trust that normal users won't create setuid-root executables.
This is all the trust I need.
> 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)
I doubt that all UNIX systems will add support for Linux capabilities
to their NFS servers and local filesystems.
>> 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.
Screwing around with traditional fs rights in what way? The executable
is owned by root and nobody else. This is very simple. (someone else
had the idea to put some kind of "real" owner in the file, not me)
>>> 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)
The kernel already clears the setuid and setgid bits on write.
(note that the sticky bit is not cleared in the same manner)
> - 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.
I don't suggest putting a setuid bit in the binary. Check my code.
Linux supports 4 UID values. The header always sets all 4 of them.
They may be set to any value, including 4 special values that
represent the old UID values.
This is a beautiful system.
> 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.
Which inheritable bits, file or process? It would be very bad to let a
user set or clear bits in either one. It is perfectly fine to use the
setuid bit to mark any "interesting" files, and a very good idea too.
Safety is ensured by the mangled header.
Here is a normal user process:
CapInh: 00000000fffffeff
CapPrm: 0000000000000000
CapEff: 0000000000000000
If you can freely set the inheritable bits on a file.
pP' = fP | ( fI & pI )
pP' = fP | ( 00000000fffffeff & 00000000fffffeff )
pP' = fP | ( 00000000fffffeff )
pP' = at least 00000000fffffeff, which is almost everything
The same goes for fP. They are about the same in fact, since you can't
safely remove bits from pI. I can see why the POSIX committee might
reject such a system, and perhaps we should respect their rejection.
The more I study this system (including kernel code) the worse it looks.
> 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.'
Nope, LGPL. You can put the security check code into a library and link
it with your proprietary software. I wrote that while looking at several
guides to writing good setuid software, so it ought to be quite good if
you add the unimplemented environment variable cleanup.
-
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/