On 06/29/2016 03:41 PM, Stephen Smalley wrote: > 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. Confirmed. It falls back to init_module. We do not know why, but i think it does not really matter, and that we should always take into account this fall back scenario. So i do not believe i will be able to drop the init_module support anytime soon. Thanks again > >> >>> >>> 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. >> >> > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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.
