I think your worries are unfounded.
> > In addition, my scheme gives you a pretty flexible system for
> > increasing security on non-caps kernels. You can easily set things up
> > so that when root runs another binary, the uid and euid are set to
> > nobody, if that binary has no capability header, or doesn't have any
> > inheritable caps set. The only thing you can't control is statically
> > linked binaries without the magic code. But if you're setting up a
> > secure system, you'd relink those anyway.
>
> That looks like a lot more work than a simple "setcaps ..." on the
> affected executables. Plus you _can't_ do it with your propietary
> database which you need to trust for raw access to partition
> /dev/foo... and all to be able to smuggle capabilities behind the
> system's back via tar(1) et al? Where (with the inmutable bit) the
> whole idea of being able to use the existing tools transparently is
> long lost anyway?
Your proprietary database programme doesn't need any privs: make the
raw device file owned by "database" and run the database under that
account. There's no reason the device file has to be owned by root.
And your use of the term "smuggling capabilities" is false, misleading
and emotive. The correct term is "preserve capabilities", as that is
the intent of the sysadmin. The term "going behind the systems back"
is also false, misleading and emotive. Rather, the system is duly
performing the tasks required of it by the sysadmin.
Regards,
Richard....
-
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/