Re: Capabilities under Linux
Y2K (y2k@y2ker.com)
Tue, 20 Apr 1999 16:11:35 -0700 (PDT)
On Tue, 20 Apr 1999, Horst von Brand wrote:
> Riley Williams <rhw@bigfoot.com> said:
> It can be stored in the file, but security in any meaningful sense goes out
> the window: It is just to easy to overwrite files, get the helpful sysadmin
> to restore a file, doctor something that is being copied via NFS, ... There
> are just too many points of attack, and the kernel would have a hell of a
> time guaranteeing nobody has tampered with the file's capabilities.
The current elf_header solution does not grant *any* privledges just is
used to revoke them. elf_headers should never be used to grant privledges
that we can agree on.
> I'm not up to date WRT the status of S[UG]ID scripts, but I understand that
> they _can_ be implemented securely, without kludges like an all-powerful
> interpreter (that is clearly out of the question for a capability system).
I have heard that said as well, If I recall correctly it involved reading
in the whole file into some kind of temp memory buffer. that dies when
program ends. The script would be invoked with foo
/proc/self/my_script_image instead of foo /bin/some-suid-file
Maybe even that is unworkable. Anyway you can embed most scripting
languages anyway like perl or python so I don't really care.
Just make a wrapper that doesn't even read yet another file.
With fmemopen or open_memstream like thing that made fd's instead of
streams one could probably make one size fit all in place wrapper.
> Storing the rights to do things inside files (that can be tampered with in
> a miriad different ways) is not secure. The ideas given here were proposed
> as a way of continuing using the exact same tools as before, but they
> couldn't live up to that (extra bits for capabilities, overloading sticky
> (+ inmutable) or SUID root for marking a capable executable all need
> _extra_ support in tools to recognize the special status). So you will need
> to hack them anyway, and the whole advantage of this just evaporates.
Again we won't store rights in the files, only denials.
> Exactly what has being thrown around here as the justification for storing
> capabilities inside the files is that you continue using the old tools...
I know that is not what I want. Store restrictions.
> > > Please forget about the cop-out "almighty root does all", that
> > > is the essence of what capabilities are all about.
> > WHere have I ever offered any such cop-out?
> Whenever specific capabilities are needed to do a job the instinctive
> reaction of any Unix sysadmin is "root". You have to think almighty root
> away, suddenly things look _very_ different.
The elf_header can transform a root into another user with only a subset
of the power... Or a root with only a subset of the full power.
I am about to release a patch based on one by Pavel.
I'd like someone who hates it to really try ripping into it.
-
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/