On Sun, Feb 16, 2014 at 4:23 PM, Luis Ressel <[email protected]> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-modules" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
