[refpolicy] MLS file upgrade

[refpolicy] MLS file upgrade

[Paul Clark]

I want to change the MLS policy to allow any process to upgrade a file 
or directory, but I'm currently failing on an "easy" first step with a 
"relabelfrom" error.

I'm using Fedora 13 and selinux-policy-3.7.19-101.fc13.src.rpm.

I did *not* change the mlscontrain rule that deals with relabelfrom 
because I think it should still work.

My test file has the same type that chcon runs with (user_t), and I'm 
simply trying to change the level from s0 to s1 by doing the following:
     chcon -l s1 testfile

I changed the mlsvalidatetrans statement for "dir" and "file" so that 
the first line was changed from
     ((( l1 eq l2 ) or
to
     ((( l1 domby l2 ) or

Any obvious problems or suggestions?

Another approach would be to also give all domains the "mlsfileupgrade" 
attribute.  Because my test process was running with user_t, I added:
     mls_file_upgrade(user_t)
to modules/admin/usermanage.te, but there was no change in the error.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20120201/2a421306/attachment.html 

[refpolicy] MLS file upgrade

[Christopher J. PeBenito]

On 02/01/12 20:09, Paul Clark wrote:
> I want to change the MLS policy to allow any process to upgrade a file or directory, but I'm currently failing on an "easy" first step with a "relabelfrom" error.
> 
> I'm using Fedora 13 and selinux-policy-3.7.19-101.fc13.src.rpm.
> 
> I did *not* change the mlscontrain rule that deals with relabelfrom because I think it should still work.
> 
> My test file has the same type that chcon runs with (user_t), and I'm simply trying to change the level from s0 to s1 by doing the following:
>     chcon -l s1 testfile

Can you clarify this?  It sounds like you're saying that your file is labeled user_t.  If thats the case, then its a regular TE problem, as user_t isn't a file type, so you can't relabel it.

> I changed the mlsvalidatetrans statement for "dir" and "file" so that the first line was changed from
>     ((( l1 eq l2 ) or
> to
>     ((( l1 domby l2 ) or
> 
> Any obvious problems or suggestions?
> 
> Another approach would be to also give all domains the "mlsfileupgrade" attribute.  Because my test process was running with user_t, I added:
>     mls_file_upgrade(user_t)
> to modules/admin/usermanage.te, but there was no change in the error.


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] MLS file upgrade

[Paul Clark]

In my earlier attempts to debug this desired ability to have all 
processes have file upgrade capabilities, I reset the type on 'testfile' 
to user_t (in permissive mode) to try to remove as many variables as 
possible from the problem, but I guess I introduced more problems.

When I leave the type as user_home_t, it still fails:
ls -Z
     user_u:object_r:user_home_t:s0 testfile
id -Z
     user_u:user_r:user_t:s0
chcon -l s1 testfile
     chcon: failed to change context of 'testfile' to 
'user_u:object_r:user_home_t:s1': Permission denied
chcon runs with the following context:
     user_u:user_r:user_t:s0

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)

When I run sealert:


Summary:

SELinux is preventing /usr/bin/chcon "relabelto" access on
/home/user2/Documents/testfile.

Detailed Description:

SELinux denied access requested by chcon. It is not expected that this 
access is
required by chcon and this access may signal an intrusion attempt. It is 
also
possible that the specific version or configuration of the application is
causing it to require additional access.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug
report.

Additional Information:

Source Context                user_u:user_r:user_t:s0
Target Context                user_u:object_r:user_home_t:s1
Target Objects                /home/user2/Documents/testfile [ file ]
Source                        chcon
Source Path                   /usr/bin/chcon
Port <Unknown>
Host                          sel13.ern.nps.edu
Source RPM Packages           coreutils-8.4-6.fc13
Target RPM Packages
Policy RPM                    selinux-policy-3.7.19-101.fc13
Selinux Enabled               True
Policy Type                   mls
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     sel13.ern.nps.edu
Platform                      Linux sel13.ern.nps.edu 
2.6.33.3-85.fc13.i686.PAE
                               #1 SMP Thu May 6 18:27:11 UTC 2010 i686 i686
Alert Count                   2
First Seen                    Thu Feb  2 10:10:27 2012
Last Seen                     Thu Feb  2 10:10:30 2012
Local ID                      c3096a25-dad6-425b-a6d1-72584a164bdb
Line Numbers

Raw Audit Messages

node=sel13.ern.nps.edu type=AVC msg=audit(1328206230.964:56): avc:  
denied  { relabelto } for  pid=2093 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(1328206230.964:56): 
arch=40000003 syscall=226 success=no exit=-13 a0=93a68d0 a1=71a185 
a2=93a7c70 a3=1f items=0 ppid=2069 pid=2093 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)


On 2/2/12 7:23 AM, Christopher J. PeBenito wrote:
> On 02/01/12 20:09, Paul Clark wrote:
>> I want to change the MLS policy to allow any process to upgrade a file or directory, but I'm currently failing on an "easy" first step with a "relabelfrom" error.
>>
>> I'm using Fedora 13 and selinux-policy-3.7.19-101.fc13.src.rpm.
>>
>> I did *not* change the mlscontrain rule that deals with relabelfrom because I think it should still work.
>>
>> My test file has the same type that chcon runs with (user_t), and I'm simply trying to change the level from s0 to s1 by doing the following:
>>      chcon -l s1 testfile
> Can you clarify this?  It sounds like you're saying that your file is labeled user_t.  If thats the case, then its a regular TE problem, as user_t isn't a file type, so you can't relabel it.
>
>> I changed the mlsvalidatetrans statement for "dir" and "file" so that the first line was changed from
>>      ((( l1 eq l2 ) or
>> to
>>      ((( l1 domby l2 ) or
>>
>> Any obvious problems or suggestions?
>>
>> Another approach would be to also give all domains the "mlsfileupgrade" attribute.  Because my test process was running with user_t, I added:
>>      mls_file_upgrade(user_t)
>> to modules/admin/usermanage.te, but there was no change in the error.
>

[refpolicy] MLS file upgrade

[Christopher J. PeBenito]

On 02/02/12 13:26, Paul Clark wrote:
> In my earlier attempts to debug this desired ability to have all processes have file upgrade capabilities, I reset the type on 'testfile' to user_t (in permissive mode) to try to remove as many variables as possible from the problem, but I guess I introduced more problems.
> 
> When I leave the type as user_home_t, it still fails:
> ls -Z
>     user_u:object_r:user_home_t:s0 testfile
> id -Z
>     user_u:user_r:user_t:s0
> chcon -l s1 testfile
>     chcon: failed to change context of 'testfile' to 'user_u:object_r:user_home_t:s1': Permission denied
> chcon runs with the following context:
>     user_u:user_r:user_t:s0
> 
> 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.
 
> When I run sealert:
[...]
> Source Context                user_u:user_r:user_t:s0
> Target Context                user_u:object_r:user_home_t:s1
> Target Objects                /home/user2/Documents/testfile [ file ]
[...]
> node=sel13.ern.nps.edu type=AVC msg=audit(1328206230.964:56): avc:  denied  { relabelto } for  pid=2093 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

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 ))));
 


 
> On 2/2/12 7:23 AM, Christopher J. PeBenito wrote:
>> On 02/01/12 20:09, Paul Clark wrote:
>>> I want to change the MLS policy to allow any process to upgrade a file or directory, but I'm currently failing on an "easy" first step with a "relabelfrom" error.
>>>
>>> I'm using Fedora 13 and selinux-policy-3.7.19-101.fc13.src.rpm.
>>>
>>> I did *not* change the mlscontrain rule that deals with relabelfrom because I think it should still work.
>>>
>>> My test file has the same type that chcon runs with (user_t), and I'm simply trying to change the level from s0 to s1 by doing the following:
>>>      chcon -l s1 testfile
>> Can you clarify this?  It sounds like you're saying that your file is labeled user_t.  If thats the case, then its a regular TE problem, as user_t isn't a file type, so you can't relabel it.
>>
>>> I changed the mlsvalidatetrans statement for "dir" and "file" so that the first line was changed from
>>>      ((( l1 eq l2 ) or
>>> to
>>>      ((( l1 domby l2 ) or
>>>
>>> Any obvious problems or suggestions?
>>>
>>> Another approach would be to also give all domains the "mlsfileupgrade" attribute.  Because my test process was running with user_t, I added:
>>>      mls_file_upgrade(user_t)
>>> to modules/admin/usermanage.te, but there was no change in the error.
>>


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] MLS file upgrade

[Paul Clark]

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)