Re: Capabilities done right...

Matthew Vanecek (mev0003@unt.edu)
Mon, 17 May 1999 12:34:38 -0500


John Wojtowicz wrote:
>
> Thats what I've said all along. Not to mention that the
> ELF header capabilities idea is probably insecure from the start. One
> wouldn't place the permission bits inside the file, ehh? So why should
> we place the capabilities, inside the file. For one thing, unless

Pardon my ignorance; I'm not really an expert on capabilities. But
shouldn't a file's permissions, executability level, user level, etc.,
be placed in the file's metadata? That is, information about a file's
capabilities (i.e., the level of permissions it has, etc) should be
stored in the filesystem. How else would you do it?? To put the
capabilities in the binary would be very insecure, IMHO, and you would
have to edit the binary every time you wanted to change its
permissions. That's just wrong.

>
> I deal with several OS'es that provide "principle of least privilege"
> support. Most notably Trusted Solaris, and SecureWare (HP, Digital,
> etc).
> They ALL provide filesystems that include the ability to store
> privileges
> (read capabilities).
>
> 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 ;-).

Exactly right. It's only common sense. I've been watching this thread
for a while, and decided to throw my two cents in, FWIW. What a binary
has permissions to do is strictly a system policy domain. The binary
should have no say in the matter. Well, to a certain extent. It should
only be allowed to execute to the highest level of permission with the
*system* has been configured to allow it. This mean if the binary has a
setuid call in it, even if it's setuid root, that that setuid would only
go as high as the system allows it, which doesn't necessarily have to be
root.

The binaries and the permissions need to be two totally separate
animals. That's the only way you can be half-way sure of maintaining
security.

-- 
Matthew Vanecek
Course of Study: http://www.unt.edu/bcis
Visit my Website at http://people.unt.edu/~mev0003
For answers type: perl -e 'print
$i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
*****************************************************************
For 93 million miles, there is nothing between the sun and my shadow
except me. I'm always getting in the way of something...

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