[...]
> > 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/