Messages in this thread | | | Subject | Re: ext3 to include capabilities? | Date | Fri, 02 Apr 1999 14:24:01 -0400 | From | Horst von Brand <> |
| |
Matthew Kirkwood <weejock@ferret.lmh.ox.ac.uk> said: > On Thu, 1 Apr 1999, Albert D. Cahalan wrote:
[...]
> > The kernel would ignore your header if the executable is not marked > > setuid root. If you can mark the executable setuid root, then you have > > already cracked root anyway -- why not "emacs /etc/passwd" instead?
> Your suggestion relies upon additional code in the dynamic loader (in fact > in every dynamic loader - a.out, ELF, Java). If I convince my admin that > I need raw socket privs for a perl script, should he really giveme an suid > perl binary? Not if me expects me to stay there.
Why not? You'd get a perl binary that has the capability you asked for, nothing more.
> Your ideas put security detection (OK, so "SD" here is a meaningless > phrase), and enforcement into the kernel.
Can't be done anywhere else: It has to be done by a trusted authority, and the ultimate trusted authority is (and always will be) the kernel and the underlying hardware.
> The kernel currently doesn't attempt to regulate the things which various > processes run. It shouldn't. The current abstractions make that > unnecessary. Yes, they also make kernel mods a periodic requirement but I > find the kernel source __much, much less painful__ than glibc. Your ideas > also require the kernel to restrict the activities of user specified > dynamic loaders/interpreters...
In a sense, those are kernel extensions. You'd have to trust them too, for otherwise they could just mangle the executable in interesting ways (loading "wrong" libraries, ...). -- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viña del Mar, Chile +56 32 672616
- 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/
| |