Messages in this thread | | | Date | Thu, 15 Apr 1999 19:20:47 -0400 (EDT) | From | "David L. Parsley (lkml account)" <> | Subject | Re: 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/
| |