lkml.org 
[lkml]   [1999]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

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