Re: Capabilities done right...
Y2K (y2k@y2ker.com)
Mon, 17 May 1999 09:29:06 -0700 (PDT)
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
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.
> 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.
So worst case is they don't voluntarily lose some of the caps they would
have gotten anyway.
> 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.
Right now setuid-root gives you everything, binary cap headers would allow
you to trim that down.
> 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?
> 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. Enablers would never go in the contents that
I can think we'd agree is absurd.
--
Any caps I mention are *derived* from a withdrawn draft posix document.
See http://www.millenniumproductsllc.com/sjp/ for more info.
-
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/