The tools installed by sys-apps/kmod with USE=tools are all just symlinks to /bin/kmod. However, due to technical limitations, it would be helpful if /sbin/depmod was a regular binary instead of a symlink on SELinux systems. Could you please add a "selinux" USE flag on the kmod ebuild to copy the whole kmod binary to /sbin/depmod?
technical limitations? why not just eg. sed whatever is doing something to depmod, to do to kmod instead?
Right, it would be helpful to know more about the problem you are trying to solve. Also, if actually necessary, would hard links work better than symlinks for whatever your are doing?
we're not hardlinking them (especially since there's no guarantee of it working across mounts). if anything, the inclination is to delete them altogether.
(In reply to SpanKY from comment #3) > we're not hardlinking them (especially since there's no guarantee of it > working across mounts). if anything, the inclination is to delete them > altogether. well, we should start by dropping modutils (Linux 2.4) from tree as a first step, and get rid of the virtual/modutils, in order to start using 'kmod ...' syntax anywhere
On the SELinux side, hardlinking would be fine as well. And I think it can be safely assumed that /bin and /sbin are on the same filesystem. However, it doesn't matter; if you prefer a separate copy, that would do just as well. @ssuominen: Wouln't that break the kernel make files?
(In reply to Samuli Suominen from comment #1) > technical limitations? why not just eg. sed whatever is doing something to > depmod, to do to kmod instead? That's exactly the problem. SELinux works by attaching labels ("contexts" / "domains") to files and processes. Now, there is one context that permits (un)loading kernel modules, and one that permits manipulating module files. These contexts should be kept separate, as these are both quite security-critical permissions. Therefore, depmod has to run in one domain, and modprobe etc. in another one. To achieve that, we need different files so that we can attach different labels to them.
(In reply to Luis Ressel from comment #6) > (In reply to Samuli Suominen from comment #1) > > technical limitations? why not just eg. sed whatever is doing something to > > depmod, to do to kmod instead? > > That's exactly the problem. SELinux works by attaching labels ("contexts" / > "domains") to files and processes. Now, there is one context that permits > (un)loading kernel modules, and one that permits manipulating module files. > These contexts should be kept separate, as these are both quite > security-critical permissions. I don't understand why they should be kept separate. How does that improve security? If you can load a module, you can pretty much do anything with the system since there is no telling what the module contains? Seems like the contexts should just be merged into one, kmod one. > Therefore, depmod has to run in one domain, and modprobe etc. in another > one. To achieve that, we need different files so that we can attach > different labels to them. Has to? Different labels, why? Can't you just slap all the labels to the kmod binary? I don't understand the possible security attack vector you seem to imply there is if it's done all to kmod...
(In reply to Samuli Suominen from comment #4) i don't think deleting the symlinks and requiring people to run `kmod xxx` makes any sense at all ever. you're talking about breaking decades of built up scripts for really no gain at all. (In reply to Samuli Suominen from comment #7) presumably they want to grant permission for everyone to use `depmod`, a reduced set for `lsmod`, and even a smaller set for `modprobe` and friends. what does Redhat do ? create sep files ? i guess selinux doesn't support applying labels to symlinks ?
some Fedora bugs for 'selinux-policy' + 'kmod' are closed as 'resolved', but still the kmod .spec for in Fedora rawhide is symlinking them with 'ln -sf', and I don't see anything special done there however http://www.spinics.net/lists/linux-modules/msg01213.html talks about copying kmod as depmod, or hardlinking it
