New rules on restrict kernel module loading

New rules on restrict kernel module loading

[Ravi Kumar]

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

Hi team ,

I see some new changes  both in kernel and sepolicy project on restricting
the load of kernel module  .

https://android-review.googlesource.com/#/c/213758/ -- kernel change  on
check for moudle_load request  by Jeff
https://android-review.googlesource.com/#/c/214021/-- sepolicy change
adding the neverallow  on module_load request  by Jeff .

As most of the  SoC /OEM has there own KO  which are loaded on run-time
detection an mostly running in system_app/system_server/platfrom_app  are
there any special guideline here .

As an good example  wlan.ko  .


Regard,
Ravi

[-- Attachment #2: Type: text/html, Size: 923 bytes --]

Re: New rules on restrict kernel module loading

[Stephen Smalley]

On 06/22/2016 01:35 PM, Ravi Kumar wrote:
> Hi team , 
> 
> I see some new changes  both in kernel and sepolicy project on
> restricting the load of kernel module  . 
> 
> https://android-review.googlesource.com/#/c/213758/ -- kernel change  on
> check for moudle_load request  by Jeff 
> https://android-review.googlesource.com/#/c/214021/-- sepolicy change
> adding the neverallow  on module_load request  by Jeff .
> 
> As most of the  SoC /OEM has there own KO  which are loaded on run-time
> detection an mostly running in system_app/system_server/platfrom_app
>  are there any special guideline here . 
> 
> As an good example  wlan.ko  .

The neverallow only prohibits loading from a target file other than
system_file or rootfs.  So as long as your module lives in /system or /,
you should just be able to allow permission as needed.  That said, not
sure why that would trigger from an app context; I would expect it to be
more likely from one of the domains already allowed module_request
permission (e.g. system_server, wpa, ...).

Re: New rules on restrict kernel module loading

[Jeffrey Vander Stoep]

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

selinux@tycho.nsa.gov 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.

On Wed, Jun 22, 2016 at 10:43 AM Ravi Kumar <nxp.ravi@gmail.com> wrote:

> Hi team ,
>
> I see some new changes  both in kernel and sepolicy project on restricting
> the load of kernel module  .
>
> https://android-review.googlesource.com/#/c/213758/ -- kernel change  on
> check for moudle_load request  by Jeff
> https://android-review.googlesource.com/#/c/214021/-- sepolicy change
> adding the neverallow  on module_load request  by Jeff .
>
> As most of the  SoC /OEM has there own KO  which are loaded on run-time
> detection an mostly running in system_app/system_server/platfrom_app  are
> there any special guideline here .
>
> As an good example  wlan.ko  .
>
>
> Regard,
> Ravi
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to
> Selinux-request@tycho.nsa.gov.

[-- Attachment #2: Type: text/html, Size: 2392 bytes --]

Re: New rules on restrict kernel module loading

[Ravi Kumar]

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

Hi Jeffrey,
I tried to do the same ,
added the allow rule in system_server as
* allow system_server system_file:system module_load;*

But still seeing issue  as of the wlan.ko is a symlink as below
wlan.ko -> /system/lib/modules/vendor_wlan.ko

Wlan.ko   or  vendor_wlan.ko are with   u:object_r:system_file:s0

But still  i see there is some issue where it show up this denial .

W WifiStateMachin: type=1400 audit(0.0:2074): avc: denied { module_load }
for scontext=u:r:system_server:s0 tcontext=u:r:system_server:s0
tclass=system permissive=0
in the above denial  i see the tcontext as system_server.

I had not debugged much into will do  but looks like there is some thing
which we are missing .

Regards,
Ravi


On Thu, Jun 23, 2016 at 12:32 AM, Jeffrey Vander Stoep <jeffv@google.com>
wrote:

> selinux@tycho.nsa.gov 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.
>
> On Wed, Jun 22, 2016 at 10:43 AM Ravi Kumar <nxp.ravi@gmail.com> wrote:
>
>> Hi team ,
>>
>> I see some new changes  both in kernel and sepolicy project on
>> restricting the load of kernel module  .
>>
>> https://android-review.googlesource.com/#/c/213758/ -- kernel change  on
>> check for moudle_load request  by Jeff
>> https://android-review.googlesource.com/#/c/214021/-- sepolicy change
>> adding the neverallow  on module_load request  by Jeff .
>>
>> As most of the  SoC /OEM has there own KO  which are loaded on run-time
>> detection an mostly running in system_app/system_server/platfrom_app  are
>> there any special guideline here .
>>
>> As an good example  wlan.ko  .
>>
>>
>> Regard,
>> Ravi
>> _______________________________________________
>> Selinux mailing list
>> Selinux@tycho.nsa.gov
>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> To get help, send an email containing "help" to
>> Selinux-request@tycho.nsa.gov.
>
>

[-- Attachment #2: Type: text/html, Size: 3899 bytes --]

Re: New rules on restrict kernel module loading

[Stephen Smalley]

On 06/23/2016 01:01 PM, Ravi Kumar wrote:
> Hi Jeffrey,
> I tried to do the same , 
> added the allow rule in system_server as 
> / allow system_server system_file:system module_load;/
> 
> But still seeing issue  as of the wlan.ko is a symlink as below  
> wlan.ko -> /system/lib/modules/vendor_wlan.ko 
> 
> Wlan.ko   or  vendor_wlan.ko are with   u:object_r:system_file:s0
> 
> But still  i see there is some issue where it show up this denial .
> 
> W WifiStateMachin: type=1400 audit(0.0:2074): avc: denied { module_load
> } for scontext=u:r:system_server:s0 tcontext=u:r:system_server:s0
> tclass=system permissive=0
> in the above denial  i see the tcontext as system_server.
> 
> I had not debugged much into will do  but looks like there is some thing
> which we are missing . 

hardware/libhardware_legacy/wifi/wifi.c needs to be updated to use
open() + finit_module() rather than load_file() + init_module().

And bionic needs to export finit_module?

Re: New rules on restrict kernel module loading

[Stephen Smalley]

On 06/22/2016 03:02 PM, Jeffrey Vander Stoep wrote:
> selinux@tycho.nsa.gov <mailto:selinux@tycho.nsa.gov> 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. 

Actually, that probably won't work for any app domains, as they can't
pass the sys_module capability check.  So hopefully you only truly need
it for system_server.

Re: New rules on restrict kernel module loading

[Jeffrey Vander Stoep]

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

Here's an example migrating code from init_module to finit_module:
https://android-review.googlesource.com/#/c/210691/

On Thu, Jun 23, 2016 at 10:22 AM Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On 06/22/2016 03:02 PM, Jeffrey Vander Stoep wrote:
> > selinux@tycho.nsa.gov <mailto:selinux@tycho.nsa.gov> 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.
>
> Actually, that probably won't work for any app domains, as they can't
> pass the sys_module capability check.  So hopefully you only truly need
> it for system_server.
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1587 bytes --]

Re: New rules on restrict kernel module loading

[Ravi Kumar]

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

Thanks Stephen and Jeffrey  that  really helped.

Regards,
Ravi

On Thu, Jun 23, 2016 at 10:59 PM, Jeffrey Vander Stoep <jeffv@google.com>
wrote:

> Here's an example migrating code from init_module to finit_module:
> https://android-review.googlesource.com/#/c/210691/
>
> On Thu, Jun 23, 2016 at 10:22 AM Stephen Smalley <sds@tycho.nsa.gov>
> wrote:
>
>> On 06/22/2016 03:02 PM, Jeffrey Vander Stoep wrote:
>> > selinux@tycho.nsa.gov <mailto:selinux@tycho.nsa.gov> 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.
>>
>> Actually, that probably won't work for any app domains, as they can't
>> pass the sys_module capability check.  So hopefully you only truly need
>> it for system_server.
>>
>>
>>
>>

[-- Attachment #2: Type: text/html, Size: 2136 bytes --]

Re: New rules on restrict kernel module loading

[Dominick Grift]

[-- Attachment #1.1: Type: text/plain, Size: 911 bytes --]

On 06/22/2016 09:02 PM, Jeffrey Vander Stoep wrote:
> selinux@tycho.nsa.gov 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?

-- 
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 648 bytes --]

Re: New rules on restrict kernel module loading

[Stephen Smalley]

On 06/28/2016 07:02 AM, Dominick Grift wrote:
> On 06/22/2016 09:02 PM, Jeffrey Vander Stoep wrote:
>> selinux@tycho.nsa.gov 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.

Re: New rules on restrict kernel module loading

[Dominick Grift]

[-- Attachment #1.1: Type: text/plain, Size: 2180 bytes --]

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@tycho.nsa.gov 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.
> 

Thanks one final question to make sure i understand this right:

Without the capability sys_module access vector the module_load
permission is "useless". You need both (capability/sys_module plus
system/module_load) to load kernel modules with success?

This is my initial support:

https://github.com/DefenSec/dssp/commit/c877fb7c91d1f404761fed282d88d40012876201

I probably end up leaving this fall back support in. And then add
finit_module() support as the need arises (i have not encountered
finit_module() users yet).

-- 
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 648 bytes --]

Re: New rules on restrict kernel module loading

[Stephen Smalley]

On 06/28/2016 09:11 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@tycho.nsa.gov 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.
>> 
> 
> Thanks one final question to make sure i understand this right:
> 
> Without the capability sys_module access vector the module_load 
> permission is "useless". You need both (capability/sys_module plus 
> system/module_load) to load kernel modules with success?

Yes, sys_module is still checked for module load (and module deletion).
module_load offers finer-grained support if you switch all
init_module() users to finit_module().  Android uses this to limit
module loading to read-only, cryptographically verified filesystems.
ChromeOS has its own custom LSM that enforces a similar constraint.

> This is my initial support:
> 
> https://github.com/DefenSec/dssp/commit/c877fb7c91d1f404761fed282d88d40012876201
>
>  I probably end up leaving this fall back support in. And then add 
> finit_module() support as the need arises (i have not encountered 
> finit_module() users yet).

Re: New rules on restrict kernel module loading

[Dominick Grift]

[-- Attachment #1.1: Type: text/plain, Size: 1962 bytes --]

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@tycho.nsa.gov 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 see that there is no selinux test-suite test implemented for this
functionality.

-- 
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 648 bytes --]

Re: New rules on restrict kernel module loading

[Stephen Smalley]

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@tycho.nsa.gov 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().

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

Re: New rules on restrict kernel module loading

[Stephen Smalley]

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@tycho.nsa.gov 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.
> 
> 

Re: New rules on restrict kernel module loading

[Dominick Grift]

[-- Attachment #1.1: Type: text/plain, Size: 3334 bytes --]

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@tycho.nsa.gov 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 648 bytes --]