On 06/29/2016 09:33 AM, Stephen Smalley wrote: > On 06/29/2016 05:36 AM, Dominick Grift wrote: >> On 06/28/2016 02:54 PM, Stephen Smalley wrote: >>> On 06/28/2016 07:02 AM, Dominick Grift wrote: >>>> On 06/22/2016 09:02 PM, Jeffrey Vander Stoep wrote: >>>>> selinux@xxxxxxxxxxxxx to bcc >>>>> >>>>> Hi Ravi, >>>>> >>>>> The intent is not to restrict which processes may load modules, >>>>> but to place restrictions on the origin of the module itself. >>>>> Modules, like the kernel, should live on a verity protected >>>>> partition. >>>>> >>>>> If you want system apps to load a kernel module from the system >>>>> partition you just need to add an allow rule. e.g. >>>>> >>>>> # system_app loads /system/lib/module/wlan.ko allow system_app >>>>> system_file:system module_load; >>>>> >>>>> Similar rules may be added for platform_app or system_server. >>>>> >>>> >>>> In Fedora rawhide i see these where the target is "self". example: >>>> >>>> allow kmod self:system module_load; >>>> >>>> is that intended? >>> >>> That's the fallback when using init_module() rather than >>> finit_module() to load modules, since the kernel does not see the file >>> when using init_module(). With init_module(), userspace loads the >>> module from the file into memory and passes a (pointer, len) pair to >>> the kernel; with finit_module(), userspace opens the module file and >>> passes the open file descriptor to the kernel. Ideally, one would >>> convert all users of init_module() to finit_module(), then remove any >>> self:system module_load permissions and only allow it for specific >>> file types. >>> >> >> I suspect that something is broken here then (although i might be wrong) >> >> systemd-udevd seems to be using finit_module() but selinux still checks >> "self" instead of a module file type. (whereas i would have expected the >> latter) > > I don't see how that is possible, given the code in question. I'd > recommend checking that it is actually using finit_module() and not > falling back to init_module(). BTW, you should be able to just check the SYSCALL audit record to see what system call was invoked upon the denial. ausearch -m AVC -i will show you any related SYSCALL records for any avc denial and will map the architecture + system call numbers to string names. So if you have an audit.log containing the denial in question, you should be able to easily tell whether it was init_module or finit_module. > >> >> I see that there is no selinux test-suite test implemented for this >> functionality. > > Can't really do that until the permission is defined in the Fedora > policy. Otherwise, it will always be allowed due to the allow-unknown > default in Fedora. > > _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
