On Sun, Feb 16, 2014 at 4:23 PM, Luis Ressel [off-list ref] wrote:

Hello,


I've got a small proposal for kmod which would be helpful for SELinux
users. First of all, I'll give some background (if you're not
interested in that, you can skip the next two paragraphs):

As you may know, SELinux is is an optional kernel subsystem which gives
finer control over permissions than the standard Unix DAC
(Discretionary Access Controls - the normal read/write/execute bits).
Basically, it attaches labels ("contexts") to files and processes and
bases the decision whether to allow or not to allow a specific action
upon these contexts.

For multi-call binaries like kmod, this labeling is problematic: The
kmod tool "depmod" requires a different set of permissions than the
rest of the kmod tools, and should therefore get a different label.
However, all of the kmod tools are only symlinks to /bin/kmod - and due
to technical limitations, we can only attach labels to files, but not to
symlinks.

Can you elaborate on the different set of SELinux labels/permissions
for depmod?  Fedora ships with SELinux enforcing enabled and we've not
had any issues with depmod being under the system_u:object_r:bin_t:s0
label.  I'm curious what you're trying to set depmod to and why.

Thus, it would be useful if you could add wrapper binary to the kmod
distribution, basically just an
"execl("/bin/kmod", "/sbin/depmod", NULL);" call. This would behave
exactly the same as a symlink, but would allow SELinux policies to
label that binary differently. Of course, this doesn't have to be
done for every user; it could be optional on a ./configure option
"--enable-depmod-wrapper".

What do you think? Would you accept such a patch?

This seems somewhat over-engineered.  Wouldn't it be simpler to copy
the kmod binary itself to a real file called 'depmod' during the
installation?

josh