Messages in this thread | | | Date | Mon, 17 May 1999 11:14:32 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: Capabilities done right... |
| |
On Sun, 16 May 1999, 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 you really do > some weird (and IMHO kludge) stuff, anyone who has the ability to modify > the contents of the file also has the ability to modify the > capabilities. I don't think that the kernel can truly "trust" that the > ELF headers haven't been modified in a illegitimate manner. Even if you > do put other checks in (i.e. checking for setuid bit before applying > file capabilities to the process, etc.), but thats another story.
wrong. It _is_ a safe method. Since you seem to be so sure and Pavel has posted his patch, could you please point out the insecurities in the ELF capabilities patch? Linus' problem was not with the security side, but rather with some conceptual issues.
> 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 ;-).
you are really naive if you think that putting priviledges into the filesystem guarantees security. If you are priviledged enough to edit root owned ELF sections then you are probably priviledged enough to use a 'disk editor' as well to tweak the filesystem directly, no?
the ELF method _is_ elegant in many ways:
- First, capabilities-enabled binaries are actually pretty rare, about 1% of all binaries. ext2fs (just like many other filesystems) makes no distinction between executable files and data files. (why would it) _What_ you do with a file is up to you. ELF is the preferred way to define executable files, and no, it's not built into the filesystem. Capabilities (as present in Linux) are inherently tired to executables, so putting it into the filesystem possibly introduces unnecessary bloat.
- With the ELF method we'd immediately get capabilities on _all_ filesystems.
- The ELF method is also very flexible in some ways, eg. potentially it could be extended to include per-binary (mandatory) PGP signatures as well, which would be checked by the kernel (or better, by external hardware which has an unreadable master key) wether the binary is signed validly to run on the system. You want to extend the filesystem (and tools) for that again?
i think the way how capabilities are passed along exec() should be defined by the binary loader, and not the filesystem. And exactly this is what Pavel's ELF-capabilities patch does. We need minimal support from the filesystem to pinpoint and maintain security-relevant executables (we have this, the setuid bit), but further 'finegrained' access can i think much better be done in the binary loader.
-- mingo
- 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/
| |