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? - Do you get any AVC or SELINUX_ERR messages at boot or upon the run_init related to the transition itself? - Is system_u authorized for systemhigh? -- 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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
