lkml.org 
[lkml]   [1999]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Capabilities, this time in elf section
Date
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, but you can't ensure that every NFS server in the world will be
patched as you wish.

The NFS client has no control over this. Using the sticky bit as a
flag is just absurdly bad. You might as well use the world-write bit.

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!

> 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)

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.
The intent is to reduce security holes I hope, not to add big holes.

> 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.

> 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.

Considering how many tools would break, you might as well change your
operating system. How about DG-UX with the B2 security option?

-
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.809 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site