Re: mdadm failure in MLS Enforcing

[Stephen Smalley <sds@tycho.nsa.gov>]

On Wed, 2009-02-11 at 10:15 -0600, Joe Nall wrote:
> On Feb 11, 2009, at 9:00 AM, Stephen Smalley wrote:
> 
> > On Wed, 2009-02-11 at 08:47 -0600, Joe Nall wrote:
> >> On Feb 11, 2009, at 8:26 AM, Stephen Smalley wrote:
> >>
> >>> On Tue, 2009-02-10 at 22:17 -0600, Joe Nall wrote:
> >>>> mdadm runs system_u:system_r:mdadm_t:s0-s15:c0.c1023 during boot  
> >>>> and
> >>>> can't access block devices that are
> >>>> system_u:object_r:fixed_disk_device_t:s15:c0.c1023
> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=485006
> >>>>
> >>>> Posted here instead of fedora-selinux because I don't think it is
> >>>> fedora specific.
> >>>>
> >>>> Boot avcs:
> >>>>
> >>>> node=test type=AVC msg=audit(1234315341.183:18): avc:  denied
> >>>> { read } for  pid=1501 comm="mdadm" name="sdb2" dev=tmpfs ino=508
> >>>> scontext=system_u:system_r:mdadm_t:s0-s15:c0.c1023
> >>>> tcontext=system_u:object_r:fixed_disk_device_t:s15:c0.c1023
> >>>> tclass=blk_file
> >>>>
> >>>>        Was caused by:
> >>>>                Policy constraint violation.
> >>>>
> >>>>                May require adding a type attribute to the domain or
> >>>> type to satisfy the constraint.
> >>>>
> >>>>                Constraints are defined in the policy sources in
> >>>> policy/constraints (general), policy/mcs (MCS), and policy/mls  
> >>>> (MLS).
> >>>>
> >>>> node=test type=AVC msg=audit(1234315341.184:19): avc:  denied
> >>>> { read } for  pid=1457 comm="mdadm" name=".tmp-9-1" dev=tmpfs
> >>>> ino=5859
> >>>> scontext=system_u:system_r:mdadm_t:s0-s15:c0.c1023
> >>>> tcontext=system_u:object_r:device_t:s0 tclass=blk_file
> >>>>
> >>>>        Was caused by:
> >>>>                Missing type enforcement (TE) allow rule.
> >>>>
> >>>>                You can use audit2allow to generate a loadable  
> >>>> module
> >>>> to allow this access.
> >>>>
> >>>> node=test type=AVC msg=audit(1234315341.188:20): avc:  denied
> >>>> { getattr } for  pid=1457 comm="mdadm" path="/proc/kcore" dev=proc
> >>>> ino=4026531986 scontext=system_u:system_r:mdadm_t:s0-s15:c0.c1023
> >>>> tcontext=system_u:object_r:proc_kcore_t:s15:c0.c1023 tclass=file
> >>>>
> >>>>        Was caused by:
> >>>>                Policy constraint violation.
> >>>>
> >>>>                May require adding a type attribute to the domain or
> >>>> type to satisfy the constraint.
> >>>>
> >>>>                Constraints are defined in the policy sources in
> >>>> policy/constraints (general), policy/mcs (MCS), and policy/mls  
> >>>> (MLS).
> >>>>
> >>>> so I added this policy:
> >>>>
> >>>> diff -up serefpolicy-3.5.13/policy/modules/system/raid.fc.orig
> >>>> serefpolicy-3.5.13/policy/modules/system/raid.fc
> >>>> --- serefpolicy-3.5.13/policy/modules/system/raid.fc.orig	 
> >>>> 2009-02-10
> >>>> 19:41:17.000000000 -0600
> >>>> +++ serefpolicy-3.5.13/policy/modules/system/raid.fc	2009-02-10
> >>>> 19:41:31.000000000 -0600
> >>>> @@ -2,4 +2,4 @@
> >>>> /sbin/mdadm		--	gen_context(system_u:object_r:mdadm_exec_t,s0)
> >>>> /sbin/mdmpd		--	gen_context(system_u:object_r:mdadm_exec_t,s0)
> >>>>
> >>>> -/var/run/mdadm(/.*)?		
> >>>> gen_context(system_u:object_r:mdadm_var_run_t,s0)
> >>>> +/var/run/mdadm(/.*)?		
> >>>> gen_context(system_u:object_r:mdadm_var_run_t,mls_systemhigh)
> >>>> diff -up serefpolicy-3.5.13/policy/modules/system/raid.te.orig
> >>>> serefpolicy-3.5.13/policy/modules/system/raid.te
> >>>> --- serefpolicy-3.5.13/policy/modules/system/raid.te.orig	 
> >>>> 2009-02-10
> >>>> 19:33:59.000000000 -0600
> >>>> +++ serefpolicy-3.5.13/policy/modules/system/raid.te	2009-02-10
> >>>> 19:39:58.000000000 -0600
> >>>> @@ -9,6 +9,10 @@ policy_module(raid, 1.7.0)
> >>>> type mdadm_t;
> >>>> type mdadm_exec_t;
> >>>> init_daemon_domain(mdadm_t,mdadm_exec_t)
> >>>> +ifdef(`enable_mls',`
> >>>> +	init_ranged_daemon_domain(mdadm_t, mdadm_exec_t,mls_systemhigh)
> >>>> +')
> >>>> +
> >>>> role system_r types mdadm_t;
> >>>>
> >>>> type mdadm_var_run_t;
> >>>>
> >>>> which does transition to SystemHigh using run_init in permissive,  
> >>>> but
> >>>> doesn't affect this bug.
> >>>>
> >>>> Clues?
> >>>
> >>> I'm not sure what you mean by "doesn't affect this bug".  Did mdadm
> >>> transition to systemhigh at boot or not?
> >>
> >> no
> >>
> >> That is why I went back and tried the run_init (which did transition)
> >> and verified the /var/run/mdadm directory was SystemHigh. I also used
> >> seinfo to verify that the patch had bend applied to the running
> >> policy. Very confusing.
> >
> > - Does it transition if in permissive mode at boot?
> no
> 
> > - Do you get any AVC or SELINUX_ERR messages at boot or upon the
> > run_init related to the transition itself?
> 
> no
> 
> > - Is system_u authorized for systemhigh?
> # semanage user -l
> 
>                  Labeling   MLS/       MLS/
> SELinux User    Prefix     MCS Level  MCS Range                       
> SELinux Roles
> 
> ...
> system_u        user       SystemLow  SystemLow-SystemHigh            
> system_r
> ...
> 
> There are a few other md* executables in /sbin. Making them  
> mdadm_exec_t did not help. Nor did rebuilding the initrd (desperation).

Looking at the mdadm policy, I see that it can also be started by udev?
So possibly you also need a range_transition rule from udev_t on it?

You should also be able to enable auditing of all transitions into
mdadm_t via auditallow rules or syscall auditing using context filters.

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