> >> You gain so little (nothing?) over an executable header, and you lose
> >> so much compatibility. You waste inode space and risk having buggy
> >> filesystem code.
> >>
> >> Better way:
> >>
> >> 1. Put capabilities information in the executable header.
> >> 2. Mark the executable setuid root.
> >> 3. Have the kernel check for #1 if #2, and prefer #1 if present.
> >
> > What if I make a new executable and make its header say it implies
> > CAP_whatever? Probaly I have looked over something...
>
> You overlooked the step 2 requirement, as many people do.
Much of the initial posix.1e (or whatever) spec, about which the Linux
kernel privileges support is based had the intention of removing, or
obsoleteing the whole "root" concept (or at least making it possible to do
so for chosen services).
> 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.
Your ideas put security detection (OK, so "SD" here is a meaningless
phrase), and enforcement into the kernel.
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...
I'm no guru, but you seem to have severely missed half a dozen of the most
important "point"s that the kernel (and the Unix model) has to offer.
Matthew.
-
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/