Messages in this thread | | | Date | Mon, 17 May 1999 12:34:38 -0500 | From | Matthew Vanecek <> | Subject | Re: Capabilities done right... |
| |
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/
| |