From: pcclark@nps.edu (Paul Clark) Date: Fri, 3 Feb 2012 14:12:17 -0800 Subject: [refpolicy] MLS file upgrade In-Reply-To: <4F2BE031.30502@tresys.com> References: <4F29E259.60205@nps.edu> <4F2AAA61.3090304@tresys.com> <4F2AD54D.60804@nps.edu> <4F2BE031.30502@tresys.com> Message-ID: <4F2C5BC1.8080602@nps.edu> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 2/3/12 5:25 AM, Christopher J. PeBenito wrote: > On 02/02/12 13:26, Paul Clark wrote: >> >> It now is reporting a 'relabelto' error. I changed the 2nd MLS 'mlsconstrain' rule in 'policy/mls' that applies to 'relabelto' from >> ( h1 dom h2 ) >> to >> ( l1 domby l2) > Thats not going to do anything in this case, as in your test, l1 == h1 and l2 == h2, since both your subject and object are single level. > It is my understanding that h1 = clearance of the process h2 = high level of the file/dir l1 = current level of the process l2 = low level of the file/dir The original (h1 dom h2) test made sense in the original policy because it ensured that a process could not create a multilevel directory that was outside the clearance of the process. For files, it was another way of ensuring that a process could not upgrade a file. I changed that rule to (l1 domby l2) so that a process could upgrade a file, but it made sure that the new level of the file was >= the old level (i.e., it made sure it wasn't a downgrade). > I did a quick look through the MLS constraints, and I /think/ this will achieve what you want. It should remove all of the upgrading restrictions, except the relabelfrom one. If you wanted to upgrade a file but your process doesn't dominate the object level (eg subject is s0 and object is s1) you'd have to remove the relabelfrom permission from the MLS constraint for all the file classes. > > diff --git a/policy/mls b/policy/mls > index 0e8474b..9a8011b 100644 > --- a/policy/mls > +++ b/policy/mls > @@ -68,10 +68,6 @@ gen_levels(mls_num_sens,mls_num_cats) > mlsconstrain { file lnk_file fifo_file } { create relabelto } > ( l2 eq h2 ); > > -# new file labels must be dominated by the relabeling subjects clearance > -mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file } relabelto > - ( h1 dom h2 ); > - > # the file "read" ops (note the check is dominance of the low level) > mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file } { read getattr execute } > (( l1 dom l2 ) or > @@ -108,12 +104,10 @@ mlsconstrain dir { add_name remove_name reparent rmdir } > > # the file upgrade/downgrade rule > mlsvalidatetrans { dir file lnk_file chr_file blk_file sock_file fifo_file } > - ((( l1 eq l2 ) or > - (( t3 == mlsfileupgrade ) and ( l1 domby l2 )) or > + ((( l1 domby l2 ) or > (( t3 == mlsfiledowngrade ) and ( l1 dom l2 )) or > (( t3 == mlsfiledowngrade ) and ( l1 incomp l2 ))) and > - (( h1 eq h2 ) or > - (( t3 == mlsfileupgrade ) and ( h1 domby h2 )) or > + (( h1 domby h2 ) or > (( t3 == mlsfiledowngrade ) and ( h1 dom h2 )) or > (( t3 == mlsfiledowngrade ) and ( h1 incomp h2 )))); > > @@ -121,12 +115,10 @@ mlsvalidatetrans { dir file lnk_file chr_file blk_file sock_file fifo_file } > # has used setfscreate (note that both the high and low level of the object > # default to the process sensitivity level) > mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file } create > - ((( l1 eq l2 ) or > - (( t1 == mlsfileupgrade ) and ( l1 domby l2 )) or > + ((( l1 domby l2 ) or > (( t1 == mlsfiledowngrade ) and ( l1 dom l2 )) or > (( t1 == mlsfiledowngrade ) and ( l1 incomp l2 ))) and > - (( l1 eq h2 ) or > - (( t1 == mlsfileupgrade ) and ( l1 domby h2 )) or > + (( l1 domby h2 ) or > (( t1 == mlsfiledowngrade ) and ( l1 dom h2 )) or > (( t1 == mlsfiledowngrade ) and ( l1 incomp h2 )))); > Thanks for taking the time to do this. I installed these changes, but I still get a 'relabelto' error. I don't understand it. Could it be that the relabelto error is coming form another module? How can I tell? Is it a problem with the type difference between the process and the file, and not an MLS problem? Here is a condensed output from sealert: node=sel13.ern.nps.edu type=AVC msg=audit(1328305466.993:55): avc: denied { relabelto } for pid=2088 comm="chcon" name="testfile" dev=sda1 ino=526347 scontext=user_u:user_r:user_t:s0 tcontext=user_u:object_r:user_home_t:s1 tclass=file node=sel13.ern.nps.edu type=SYSCALL msg=audit(1328305466.993:55): arch=40000003 syscall=226 success=no exit=-13 a0=86118d0 a1=71a185 a2=8612c70 a3=1f items=0 ppid=2069 pid=2088 auid=501 uid=501 gid=501 euid=501 suid=501 fsuid=501 egid=501 sgid=501 fsgid=501 tty=pts1 ses=1 comm="chcon" exe="/usr/bin/chcon" subj=user_u:user_r:user_t:s0 key=(null)