Re: Capabilities done right...

Ingo Molnar (mingo@chiara.csoma.elte.hu)
Mon, 17 May 1999 11:14:32 +0200 (CEST)


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/