lkml.org 
[lkml]   [1999]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: caps in elf headers: use the sticky bit!
Hello,

On Thu, 15 Apr 1999 tytso@MIT.EDU wrote:

> Date: Wed, 14 Apr 1999 22:41:44 -0400 (EDT)
> From: "David L. Parsley (lkml account)" <kparse@salem.k12.va.us>
>
> Well, I think Ted freely exercises his right to ignore us. ;-)
>
> No, it's because I've been travelling ---

I figured you were probably swamped with a coding project or something,
and wasn't worried about it. I just thought you'd find some of it
interesting.

> some of us have real jobs
> and can't afford to engage a debate which is taking up a huge amount
> of the bandwidth on linux-kernel at the same level of intensity that
> you all have been using. (Which is a polite way of saying, "Wow, you
> all have been flaming a lot" :-)

Yes, I've been guilty of firing off to quick, when I really should have
taken a break. I really ought to try and take a lesson from this...

[snip]

> Face it, using a full capability system is a completely different
> security model; it's different from the traditional Unix model. But
> that's OK. I don't expect everyone to immediately switch to it; it will
> take a lot of time. In fact, I don't think it will ever see widespread
> use until some distribution makes it an option and works out all of the
> system administration issues.

Yes, I'm interested in trying to work this out for a locally-produced
distribution.

[snip]
> So, given that, what do we do? I think we should strive for the full
> capabilities model as enviisioned by POSIX.

I agree strongly here.

[snip]
> What I would suggest is either using a combination of the sticky bit
> plus the immutable flag, *or* define a new ext2 flag which means "this
> file has capability information". The second is probably the better
> choice, and since it's only a bit in the flags word, it's easy enough
> to implement.

My favorite feature of the sticky bit solution is the way it's tied to
immutable. The kernel interprets a request to set sticky as
'capability-enable', requiring CAP_SETFCAP. If raised, the kernel sets
_both_ sticky and immutable, otherwise it sets neither. This gives us the
advantage of being easily made to work with tar, rpm, dpkg, cp, ...

Oh geez, this gives me another idea. (brace yourself! ;-) On an ext2 fs
we can define a new flag as you've suggested, and which I like a lot. On
a capability-enabled kernel, we can map this bit to the sticky bit in the
vfs, and not actually even _use_ the real sticky bit. This gives us both
the excellent tool compatibility, as well as protection from the 'old
kernel' problem.

> Now, people will inevitably complain that this means
> you can't use other filesystems. That's correct. And I think, that's
> OK.

Agreed. It's not that this solution _can't_ be made to work on a remote
fs, it's just not secure.

[snip remainder]

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/

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