Xorg modprobe denials

Xorg modprobe denials

[Eamon Walsh]

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

Attached are some denials that modprobe is encountering while loading 
Xorg DRI kernel modules while X server is starting up.  tty7 is the 
terminal where the X server is being launched (Ctrl-Alt-F7).  I'm aware 
that the Xorg.0.log file is supposed to be labeled xserver_log_t, but my 
guess is that would be denied as well.  Think this may be log messages 
except for the renicing stuff.

This is xselinux branch of refpolicy running in enforcing mode.

-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency


[-- Attachment #2: audit_x.txt --]
[-- Type: text/plain, Size: 1794 bytes --]

Dec 17 21:25:34 moss-charon kernel: audit(1197944734.892:71): avc:  denied  { read write } for  pid=2220 comm="modprobe" name="tty7" dev=tmpfs ino=240 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file
Dec 17 21:25:34 moss-charon kernel: audit(1197944734.893:72): avc:  denied  { write } for  pid=2220 comm="modprobe" path="/usr/local/var/log/Xorg.0.log" dev=dm-0 ino=5701638 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:object_r:usr_t:s0 tclass=file
Dec 17 21:25:34 moss-charon kernel: audit(1197944734.893:73): avc:  denied  { read write } for  pid=2220 comm="modprobe" path="/dev/tty7" dev=tmpfs ino=240 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file
Dec 17 21:25:34 moss-charon kernel: audit(1197944734.926:74): avc:  denied  { sys_nice } for  pid=2220 comm="modprobe" capability=23 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tclass=capability
Dec 17 21:25:34 moss-charon kernel: [drm] Initialized drm 1.1.0 20060810
Dec 17 21:25:34 moss-charon kernel: audit(1197944734.932:75): avc:  denied  { sys_nice } for  pid=2220 comm="modprobe" capability=23 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tclass=capability
Dec 17 21:25:34 moss-charon kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16
Dec 17 21:25:34 moss-charon kernel: [drm] Initialized i915 1.11.0 20071122 on minor 0
Dec 17 21:25:34 moss-charon kernel: mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining
Dec 17 21:25:40 moss-charon kernel: mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining

Re: Xorg modprobe denials

[Chris PeBenito]

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

On Mon, 2007-12-17 at 22:14 -0500, Eamon Walsh wrote:
> Attached are some denials that modprobe is encountering while loading 
> Xorg DRI kernel modules while X server is starting up.  tty7 is the 
> terminal where the X server is being launched (Ctrl-Alt-F7).  I'm aware 
> that the Xorg.0.log file is supposed to be labeled xserver_log_t, but my 
> guess is that would be denied as well.  Think this may be log messages 
> except for the renicing stuff.
> 
> This is xselinux branch of refpolicy running in enforcing mode.

Based on the other kernel messages, I'm guessing that the insmod
succeeded despite the tty and capability denials?  If so I suppose we
can dontaudit it.

> plain text document attachment (audit_x.txt)
> Dec 17 21:25:34 moss-charon kernel: audit(1197944734.892:71): avc:  denied  { read write } for  pid=2220 comm="modprobe" name="tty7" dev=tmpfs ino=240 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file
> Dec 17 21:25:34 moss-charon kernel: audit(1197944734.893:72): avc:  denied  { write } for  pid=2220 comm="modprobe" path="/usr/local/var/log/Xorg.0.log" dev=dm-0 ino=5701638 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:object_r:usr_t:s0 tclass=file
> Dec 17 21:25:34 moss-charon kernel: audit(1197944734.893:73): avc:  denied  { read write } for  pid=2220 comm="modprobe" path="/dev/tty7" dev=tmpfs ino=240 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file
> Dec 17 21:25:34 moss-charon kernel: audit(1197944734.926:74): avc:  denied  { sys_nice } for  pid=2220 comm="modprobe" capability=23 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tclass=capability
> Dec 17 21:25:34 moss-charon kernel: [drm] Initialized drm 1.1.0 20060810
> Dec 17 21:25:34 moss-charon kernel: audit(1197944734.932:75): avc:  denied  { sys_nice } for  pid=2220 comm="modprobe" capability=23 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tclass=capability
> Dec 17 21:25:34 moss-charon kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16
> Dec 17 21:25:34 moss-charon kernel: [drm] Initialized i915 1.11.0 20071122 on minor 0
> Dec 17 21:25:34 moss-charon kernel: mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining
> Dec 17 21:25:40 moss-charon kernel: mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining
> 

-- 
Chris PeBenito
<pebenito@gentoo.org>
Developer,
Hardened Gentoo Linux
 
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243
Key fingerprint = B0E6 877A 883F A57A 8E6A  CB00 BC8E E42D E6AF 9243

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Xorg modprobe denials

[Stephen Smalley]

On Mon, 2007-12-17 at 22:47 -0500, Chris PeBenito wrote:
> On Mon, 2007-12-17 at 22:14 -0500, Eamon Walsh wrote:
> > Attached are some denials that modprobe is encountering while loading 
> > Xorg DRI kernel modules while X server is starting up.  tty7 is the 
> > terminal where the X server is being launched (Ctrl-Alt-F7).  I'm aware 
> > that the Xorg.0.log file is supposed to be labeled xserver_log_t, but my 
> > guess is that would be denied as well.  Think this may be log messages 
> > except for the renicing stuff.
> > 
> > This is xselinux branch of refpolicy running in enforcing mode.
> 
> Based on the other kernel messages, I'm guessing that the insmod
> succeeded despite the tty and capability denials?  If so I suppose we
> can dontaudit it.

I don't think we want to dontaudit the capability denials.

> > plain text document attachment (audit_x.txt)
> > Dec 17 21:25:34 moss-charon kernel: audit(1197944734.892:71): avc:  denied  { read write } for  pid=2220 comm="modprobe" name="tty7" dev=tmpfs ino=240 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file
> > Dec 17 21:25:34 moss-charon kernel: audit(1197944734.893:72): avc:  denied  { write } for  pid=2220 comm="modprobe" path="/usr/local/var/log/Xorg.0.log" dev=dm-0 ino=5701638 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:object_r:usr_t:s0 tclass=file
> > Dec 17 21:25:34 moss-charon kernel: audit(1197944734.893:73): avc:  denied  { read write } for  pid=2220 comm="modprobe" path="/dev/tty7" dev=tmpfs ino=240 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file
> > Dec 17 21:25:34 moss-charon kernel: audit(1197944734.926:74): avc:  denied  { sys_nice } for  pid=2220 comm="modprobe" capability=23 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tclass=capability
> > Dec 17 21:25:34 moss-charon kernel: [drm] Initialized drm 1.1.0 20060810
> > Dec 17 21:25:34 moss-charon kernel: audit(1197944734.932:75): avc:  denied  { sys_nice } for  pid=2220 comm="modprobe" capability=23 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tclass=capability
> > Dec 17 21:25:34 moss-charon kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16
> > Dec 17 21:25:34 moss-charon kernel: [drm] Initialized i915 1.11.0 20071122 on minor 0
> > Dec 17 21:25:34 moss-charon kernel: mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining
> > Dec 17 21:25:40 moss-charon kernel: mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining
> > 
> 
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Xorg modprobe denials

[Stephen Smalley]

On Tue, 2007-12-18 at 08:34 -0500, Stephen Smalley wrote:
> On Mon, 2007-12-17 at 22:47 -0500, Chris PeBenito wrote:
> > On Mon, 2007-12-17 at 22:14 -0500, Eamon Walsh wrote:
> > > Attached are some denials that modprobe is encountering while loading 
> > > Xorg DRI kernel modules while X server is starting up.  tty7 is the 
> > > terminal where the X server is being launched (Ctrl-Alt-F7).  I'm aware 
> > > that the Xorg.0.log file is supposed to be labeled xserver_log_t, but my 
> > > guess is that would be denied as well.  Think this may be log messages 
> > > except for the renicing stuff.
> > > 
> > > This is xselinux branch of refpolicy running in enforcing mode.
> > 
> > Based on the other kernel messages, I'm guessing that the insmod
> > succeeded despite the tty and capability denials?  If so I suppose we
> > can dontaudit it.
> 
> I don't think we want to dontaudit the capability denials.

And just to note, denials from insmod can be triggered either by
userspace activity of insmod or by the module initialization code of the
loaded module.

> > > plain text document attachment (audit_x.txt)
> > > Dec 17 21:25:34 moss-charon kernel: audit(1197944734.892:71): avc:  denied  { read write } for  pid=2220 comm="modprobe" name="tty7" dev=tmpfs ino=240 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file
> > > Dec 17 21:25:34 moss-charon kernel: audit(1197944734.893:72): avc:  denied  { write } for  pid=2220 comm="modprobe" path="/usr/local/var/log/Xorg.0.log" dev=dm-0 ino=5701638 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:object_r:usr_t:s0 tclass=file
> > > Dec 17 21:25:34 moss-charon kernel: audit(1197944734.893:73): avc:  denied  { read write } for  pid=2220 comm="modprobe" path="/dev/tty7" dev=tmpfs ino=240 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file
> > > Dec 17 21:25:34 moss-charon kernel: audit(1197944734.926:74): avc:  denied  { sys_nice } for  pid=2220 comm="modprobe" capability=23 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tclass=capability
> > > Dec 17 21:25:34 moss-charon kernel: [drm] Initialized drm 1.1.0 20060810
> > > Dec 17 21:25:34 moss-charon kernel: audit(1197944734.932:75): avc:  denied  { sys_nice } for  pid=2220 comm="modprobe" capability=23 scontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tcontext=system_u:system_r:insmod_t:s0-s0:c0.c255 tclass=capability
> > > Dec 17 21:25:34 moss-charon kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16
> > > Dec 17 21:25:34 moss-charon kernel: [drm] Initialized i915 1.11.0 20071122 on minor 0
> > > Dec 17 21:25:34 moss-charon kernel: mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining
> > > Dec 17 21:25:40 moss-charon kernel: mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining
> > > 
> > 
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Xorg modprobe denials

[Martin Orr]

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

On 18/12/07 13:57, Stephen Smalley wrote:
> On Tue, 2007-12-18 at 08:34 -0500, Stephen Smalley wrote:
>> On Mon, 2007-12-17 at 22:47 -0500, Chris PeBenito wrote:
>>> Based on the other kernel messages, I'm guessing that the insmod
>>> succeeded despite the tty and capability denials?  If so I suppose we
>>> can dontaudit it.
>> I don't think we want to dontaudit the capability denials.
> 
> And just to note, denials from insmod can be triggered either by
> userspace activity of insmod or by the module initialization code of the
> loaded module.

I find that on an SMP machine I need both the sys_nice capabability and
setsched on kernel_t to load modules.

This is because stop_machine() is called by sys_init_module(), so it makes
sense to me to add these to kernel_load_module().

Index: policy/modules/kernel/kernel.if
===================================================================
--- policy/modules/kernel/kernel.if	(revision 2560)
+++ policy/modules/kernel/kernel.if	(working copy)
@@ -330,6 +330,9 @@

 	allow $1 self:capability sys_module;
 	typeattribute $1 can_load_kernmodule;
+
+	allow $1 self:capability sys_nice;
+	kernel_setsched($1)
 ')

 ########################################

-- 
Martin Orr


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: Xorg modprobe denials

[Christopher J. PeBenito]

On Wed, 2007-12-19 at 21:11 +0000, Martin Orr wrote:
> On 18/12/07 13:57, Stephen Smalley wrote:
> > On Tue, 2007-12-18 at 08:34 -0500, Stephen Smalley wrote:
> >> On Mon, 2007-12-17 at 22:47 -0500, Chris PeBenito wrote:
> >>> Based on the other kernel messages, I'm guessing that the insmod
> >>> succeeded despite the tty and capability denials?  If so I suppose we
> >>> can dontaudit it.
> >> I don't think we want to dontaudit the capability denials.
> > 
> > And just to note, denials from insmod can be triggered either by
> > userspace activity of insmod or by the module initialization code of the
> > loaded module.
> 
> I find that on an SMP machine I need both the sys_nice capabability and
> setsched on kernel_t to load modules.
> 
> This is because stop_machine() is called by sys_init_module(), so it makes
> sense to me to add these to kernel_load_module().
> 
> Index: policy/modules/kernel/kernel.if
> ===================================================================
> --- policy/modules/kernel/kernel.if	(revision 2560)
> +++ policy/modules/kernel/kernel.if	(working copy)
> @@ -330,6 +330,9 @@
> 
>  	allow $1 self:capability sys_module;
>  	typeattribute $1 can_load_kernmodule;
> +
> +	allow $1 self:capability sys_nice;
> +	kernel_setsched($1)
>  ')

Are these rules are inherent to anything that loads a module or specific
to insmod?  This patch only makes sense if its the former.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Xorg modprobe denials

[Martin Orr]

On 03/01/08 15:30, Christopher J. PeBenito wrote:
> On Wed, 2007-12-19 at 21:11 +0000, Martin Orr wrote:
>> On 18/12/07 13:57, Stephen Smalley wrote:
>>> On Tue, 2007-12-18 at 08:34 -0500, Stephen Smalley wrote:
>>>> On Mon, 2007-12-17 at 22:47 -0500, Chris PeBenito wrote:
>>>>> Based on the other kernel messages, I'm guessing that the insmod
>>>>> succeeded despite the tty and capability denials?  If so I suppose we
>>>>> can dontaudit it.
>>>> I don't think we want to dontaudit the capability denials.
>>> And just to note, denials from insmod can be triggered either by
>>> userspace activity of insmod or by the module initialization code of the
>>> loaded module.
>> I find that on an SMP machine I need both the sys_nice capabability and
>> setsched on kernel_t to load modules.
>>
>> This is because stop_machine() is called by sys_init_module(), so it makes
>> sense to me to add these to kernel_load_module().
>>
>> Index: policy/modules/kernel/kernel.if
>> ===================================================================
>> --- policy/modules/kernel/kernel.if	(revision 2560)
>> +++ policy/modules/kernel/kernel.if	(working copy)
>> @@ -330,6 +330,9 @@
>>
>>  	allow $1 self:capability sys_module;
>>  	typeattribute $1 can_load_kernmodule;
>> +
>> +	allow $1 self:capability sys_nice;
>> +	kernel_setsched($1)
>>  ')
> 
> Are these rules are inherent to anything that loads a module or specific
> to insmod?  This patch only makes sense if its the former.
>

It happens inside the init_module system call in the kernel, so anything
that loads a module needs it.

-- 
Martin Orr

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

refpolicy: syscall init_module needs sys_nice & setsched

[Václav Ovsík]

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

Hi,
while playing with current Debian Sid, Linux 2.6.25 I noticed, denials
on modprobe:

May 22 07:26:11 sid kernel: [    9.195474] type=1400 audit(1211433957.144:3): avc:  denied  { sys_nice } for  pid=801 comm="modprobe" capability=23 scontext=system_u:system_r:insmod_t:s0-s0:c0.c1023 tcontext=system_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=capability
May 22 07:26:11 sid kernel: [    9.198362] type=1400 audit(1211433957.144:3): avc:  denied  { setsched } for  pid=801 comm="modprobe" scontext=system_u:system_r:insmod_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=process

After a longer investigation with git-bisect I found, that above
denials appeared after kernel commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=85653af7d488702165eba72c6c1dd0250fae4e70
A function stop_machine() (from kernel/stop_machine.c) was changed in
this commit in such a way, that system calls init_module()
& delete_module() needs sys_nice & setsched. I did'n try to understand
code too much (consequences of this commit).

I found in the history of SE Linux mailing list Martin Orr sent a patch
already. (The correspondence attached.)
The Martins patch is available at URL:
http://www.martinorr.name/selinux/patches/151_module_setsched

Can be Martins patch merged?
Thanks
-- 
Zito

[-- Attachment #2: m1 --]
[-- Type: message/rfc822, Size: 1 bytes --]

Re: refpolicy: syscall init_module needs sys_nice & setsched

[Christopher J. PeBenito]

On Thu, 2008-05-22 at 14:29 +0200, Václav Ovsík wrote:
> while playing with current Debian Sid, Linux 2.6.25 I noticed, denials
> on modprobe:
> 
> May 22 07:26:11 sid kernel: [    9.195474] type=1400 audit(1211433957.144:3): avc:  denied  { sys_nice } for  pid=801 comm="modprobe" capability=23 scontext=system_u:system_r:insmod_t:s0-s0:c0.c1023 tcontext=system_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=capability
> May 22 07:26:11 sid kernel: [    9.198362] type=1400 audit(1211433957.144:3): avc:  denied  { setsched } for  pid=801 comm="modprobe" scontext=system_u:system_r:insmod_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=process
> 
> After a longer investigation with git-bisect I found, that above
> denials appeared after kernel commit:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=85653af7d488702165eba72c6c1dd0250fae4e70
> A function stop_machine() (from kernel/stop_machine.c) was changed in
> this commit in such a way, that system calls init_module()
> & delete_module() needs sys_nice & setsched. I did'n try to understand
> code too much (consequences of this commit).
> 
> I found in the history of SE Linux mailing list Martin Orr sent a patch
> already. (The correspondence attached.)
> The Martins patch is available at URL:
> http://www.martinorr.name/selinux/patches/151_module_setsched

I added that and comments as to why its needed.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.