>>>> 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).
This is where you really don't understand.
If I said "special enabler flag" instead of setuid-root, would you like
the system better? I choose the old (now useless) setuid-root setting
to be my special enabler flag.
In other words, setuid-root gets overloaded for compatibility reasons.
You can still disable the setuid feature; in that case it would only
act as a special enabler flag.
>> 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 admin (well, security officer) can set up the script as needed,
assuming the perl interpreter supports such operation.
(perl must be modified for either system -- scripts don't get privs)
What, you don't want the admin to know if your script suddenly grows
a network-aware password scanning feature? Hmmm...
> Your ideas put security detection (OK, so "SD" here is a meaningless
> phrase), and enforcement into the kernel.
No, the existing setuid policy is enough protection. It is the other
system which needs new enforcement code.
> The kernel currently doesn't attempt to regulate the things which various
> processes run. It shouldn't.
Actually, it does and it must. Try inserting a kernel module as a
normal user, without any setuid help.
> 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.
Who said anything about glibc? I propose a simple tool to change
existing binary executables, used with plain old chmod and chown.
> Your ideas
> also require the kernel to restrict the activities of user specified
> dynamic loaders/interpreters...
Such as?
> 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.
Capabilities are not at all part of the Unix model. At least I don't
break tar, cpio, taper, bru, NFS (including non-Linux servers), and
really basic UNIX tools like /bin/mv and /bin/cp. You'd break them all.
-
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/