Proposal: Add a depmod wrapper for kmod to aid SELinux

Proposal: Add a depmod wrapper for kmod to aid SELinux

[Luis Ressel]

[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]

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.

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?


Regards,
Luis Ressel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: Proposal: Add a depmod wrapper for kmod to aid SELinux

[Josh Boyer]

On Sun, Feb 16, 2014 at 4:23 PM, Luis Ressel <aranea@aixah.de> 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

Re: Proposal: Add a depmod wrapper for kmod to aid SELinux

[Luis Ressel]

[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]

On Mon, 17 Feb 2014 08:47:05 -0500
Josh Boyer <jwboyer@fedoraproject.org> wrote:

> 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.

That's because Fedora uses a "targeted" SELinux policy by default and
therefore only restricts the permissions of daemons. Users are
"unconfined" - they keep their full permission set. Depmod is called
interactively and gets full root access, just as without SELinux.

I use a "strict" policy which also restricts users. In that case, root
normally doesn't have the permissions needed by modprobe or depmod.
Thus, they have to be labeled specially: depmod_t for depmod and
insmod_t for the other kmod tools.

> 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?

You're absolutely right. I just didn't think of that. In some cases
this might create an unpleasant size overhead, but for kmod that
overhead is negligible. Since kmod's make install target doesn't create
the symlinks, it also doesn't have to care about this. I therefore
withdraw my proposal.

However, in case you add the functionality of creating the symlinks to
the Makefile in the future, it would be neat to offer this approach as
a configurable alternative. (Only for depmod, though, the other tools
can stay symlinks).


Regards,
Luis Ressel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: Proposal: Add a depmod wrapper for kmod to aid SELinux

[Lucas De Marchi]

On Tue, Feb 18, 2014 at 3:10 PM, Luis Ressel <aranea@aixah.de> wrote:
> On Mon, 17 Feb 2014 08:47:05 -0500
> Josh Boyer <jwboyer@fedoraproject.org> wrote:
>
>> 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.
>
> That's because Fedora uses a "targeted" SELinux policy by default and
> therefore only restricts the permissions of daemons. Users are
> "unconfined" - they keep their full permission set. Depmod is called
> interactively and gets full root access, just as without SELinux.
>
> I use a "strict" policy which also restricts users. In that case, root
> normally doesn't have the permissions needed by modprobe or depmod.
> Thus, they have to be labeled specially: depmod_t for depmod and
> insmod_t for the other kmod tools.
>
>> 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?
>
> You're absolutely right. I just didn't think of that. In some cases
> this might create an unpleasant size overhead, but for kmod that
> overhead is negligible. Since kmod's make install target doesn't create
> the symlinks, it also doesn't have to care about this. I therefore
> withdraw my proposal.

You can use hardlinks as well, so you don't have the size overhead:

=E2=94=94 bin =E2=9E=A4 ls -li kmod
1450802 -rwxr-xr-x 2 root root 665285 Jan 26 18:07 kmod
=E2=94=94 bin =E2=9E=A4 ls -li modprobe
1450802 -rwxr-xr-x 2 root root 665285 Jan 26 18:07 modprobe
=E2=94=94 bin =E2=9E=A4 ./modprobe -h
Usage:
        modprobe [options] [-i] [-b] modulename
        ...


>
> However, in case you add the functionality of creating the symlinks to
> the Makefile in the future, it would be neat to offer this approach as
> a configurable alternative. (Only for depmod, though, the other tools
> can stay symlinks).

ok... in the very first versions kmod we had code in the install
target to create the symlinks... However back then we had to deal with
all different distros putting modprobe/depmod in different
directories. We decided to stop doing that and let the distros create
them.

My personal plan is to move away from modprobe/insmod/rmmod/depmod and
instead use only kmod as a tool. I'll remember your problem with
SELinux if/when we have a useful kmod tool and provide an alternative

Lucas De Marchi