Proposal: Add a depmod wrapper for kmod to aid SELinux

[Luis Ressel]

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

[Josh Boyer]

Post by Luis Ressel
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
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.

Post by Luis Ressel
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

[Luis Ressel]

On Mon, 17 Feb 2014 08:47:05 -0500

Post by Josh Boyer
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.

Post by Josh Boyer
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

[Lucas De Marchi]

Post by Luis Ressel
On Mon, 17 Feb 2014 08:47:05 -0500

Post by Josh Boyer
Can you elaborate on the different set of SELinux labels/permissions
for depmod? Fedora ships with SELinux enforcing enabled and we've n=

ot

Post by Luis Ressel

Post by Josh Boyer
had any issues with depmod being under the system_u:object_r:bin_t:s=

0

Post by Luis Ressel

Post by Josh Boyer
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, roo=

t

Post by Luis Ressel
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.

Post by Josh Boyer
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 crea=

te

Post by Luis Ressel
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
...

Post by Luis Ressel
However, in case you add the functionality of creating the symlinks t=

o

Post by Luis Ressel
the Makefile in the future, it would be neat to offer this approach a=

s

Post by Luis Ressel
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