From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: mdadm failure in MLS Enforcing From: Stephen Smalley To: Joe Nall Cc: SE Linux In-Reply-To: References: <1234362362.12067.104.camel@localhost.localdomain> <1234364409.12067.109.camel@localhost.localdomain> Content-Type: text/plain Date: Wed, 11 Feb 2009 12:33:08 -0500 Message-Id: <1234373588.12067.115.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@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.