> > [...]
> > > If you really want to completely remove UID=0 tests from the kernel,
> > > then we have to put caps into the FS as metadata, because using the
> > > sticky bit on ordinary user files is too insecure. At the moment the
> > > debate is about ELF cap headers and whether to use suid-root or the
> > > sticky bit as the magic flag. In that debate, I think suid-root wins
> > > by default.
> > Bingo!
> OK, so it seems we agree that the suid-root approach is better than
> the sticky bit approach.
Not again... SUID 0 == capabilities, or sticky == capabilities is broken,
because it _can't_ be made to work right
> Putting caps into FS metadata has its own problems: breaking large
> numbers of programmes, NFS/CODA and more.
If you are into paranoia enough to really want capabilities, you won't let
anything like that even near to your system, unless it simply ignores
capabilities. Capabilities can _only_ be granted by specific permission,
not by copying around or getting files over the network.
> So the question is: is it better to have an ideologically pure caps
> system (i.e. euid=0 means nothing), with the cost of breaking everything,
> or is it better to have a practical caps system (where euid=0 means all
> caps, but there might not be a root account) which is 100% compatible and
> secure?
You can have both, but not via overloading of bits in the filesystem that
mean something entirely different and touching up the whole thing with
unsecure storing of permissions in the file itself.
> I'm heavily in favour of a practical system. In fact, there's no
> reason we can't have both. The practical system can be implemented in
> user space (use a CAP ELF header and put magic into the dynamic
> loader) if you want. For the purists, go ahead and put caps into FS
> metadata and #ifdef out all the places in the kernel where euid=0
> means something.
I don't see how a system that handles capabilities in metadata is not
practical. Sure, you can't just tar up a bunch of files with capabilities
and restore them later with the current tar(1). You'd need a special tool
for that, just as you'd need a _very_ few other specialized tools. I don't
see the big difference in writing the tools for a new filesystem vs writing
them for a "permissions inside the file" approach. Sure, there might be a
few more tools to write, but they would be simpler, and need no stupid
tricks inside the kernel to do their work (How does ls(1) find out to whom
the ---s--x--x file for user root really belongs? What are its
capabilities? What if the file is ---s------? Can I run it, as it really
belongs to me?)
As I see it, none of these kludges has any chance of getting by the head
hackers or Linus. The Linux way is doing things _right_, even if it hurts.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
- 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/