Messages in this thread | | | Date | Mon, 17 May 1999 17:16:48 -0400 | From | John Wojtowicz <> | Subject | Re: capability disablers... in ELF... |
| |
>> The header stuff can only *reduce* capabilities, other mechanisms such as >> suid-root or vfs cap support would be needed to raise caps. >> I don't think anyone would sell them as the *one* *true* answer.
Ohh! So the kernel doesn't intend to support raising capabilities in the ELF header scenario? I see. So its not really a full principle of least privilege implementation.
>> So worst case is they don't voluntarily lose some of the caps they would >> have gotten anyway.
>> Right now setuid-root gives you everything, binary cap headers would allow >> you to trim that down.
Yupp, but if they call other programs, then you have to kludge the disabling of privs so that the child process doesn't get any privileges. Or in the case of shell scripts suffer horrible consequences, as mentioned in previous messages.
In a full implementation this is done in conjunction with the process privilege sets, and the file privilege sets (which are the forced and allowed sets).
This is how it works. A privileged process has priv a, b, and c in its effective set, inheritable and permitted sets. It execs another program that has none in its allowed set and none in its forced set (on the file). since the new processes effective, permitted and inheritable sets are determined by the intersection of the inheritable of the parent, and the allowed of the child (which is none) and the child process gets no effective, permitted, or allowed privileges.
>> > They also give you (at least) three privilege sets per process. >> > Permitted, inheritable, and effective. These seem to be there >> > in the linux kernel. As well, they allow you to set two privilege sets >> > on each regular file. Allowed, and forced sets (but there appears to >> > be only one in the linux kernel). To set a privilege >> > on a file, the process that is doing so must have the "file set >> > privilege" >> > privilege. This may seem like a catch-22 but its not. >> They are in the kernel just not realy being used right now. >> Could you look at my web page to see what is being done to address that >> issue?
Yupp sure thing. I think that you agree that any implementation which raises capabilities based on something thats in the contents of a file is fundamentally flawed. Sure you COULD even access the filesystem in a raw manner if the caps are in the filesystem, but then again you can protect that raw filesystem with a raw filesystem access capability.
>> > A system call should be the only way to change the files capability >> > sets (forced and allowed), and that system call should check to see if >> > the >> > process that is calling it has the "set capabilities on files" >> > capability, >> > in its effective capabilities set. Inode or namespace is fine and >> > dandy with me, as long as they don't get put into the CONTENTS >> > of the file ;-).
>> Why if some restrictions go in the CONTENTS then they can be restricted >> across ftp, nfs, or whatever.
And it buys you the ability not to have to rewrite tar, and other archiving programs to store privileges and place them on the file when they are extracted. I agree it has its benefits.
And because the kernel should restrict what processes can set privileges on files. If you do it as I mentioned above the kernel can keep ANY process from setting capabilities on a file, if that process doesn't have the "I can set file capabilities" capability. If you add in a "raw disk access" capability you can keep any process from writing to a disk device, and attempting to hack privileges onto the filesystem. (thus the "disk editor" has to get the "raw disk access" capability somehow doesn't it?).
I'm not just pulling this stuff out of the air, its been implemented on other trusted operating systems already.
>>Enablers would never go in the contents that >> I can think we'd agree is absurd.
Exactly, I think I was under the mistaken belief that you intended to do that. But still don't you think it would be better to implement both enablers and disablers, in a more secure and arguably correct principle of least privilege implementation?
John -- John Wojtowicz, Secure Systems Engr. ph: (703) 318-7134 Trusted Computer Solutions, Inc. fax: (703) 318-5041 13873 Park Center Rd. Suite 225 email: jwojtowicz@tcs-sec.com Herndon, VA 20171 http://www.tcs-sec.com/
- 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/
| |