From: cpebenito@tresys.com (Christopher J. PeBenito)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] MLS file upgrade
Date: Fri, 3 Feb 2012 08:25:05 -0500 [thread overview]
Message-ID: <4F2BE031.30502@tresys.com> (raw)
In-Reply-To: <4F2AD54D.60804@nps.edu>
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
next prev parent reply other threads:[~2012-02-03 13:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-02 1:09 [refpolicy] MLS file upgrade Paul Clark
2012-02-02 15:23 ` Christopher J. PeBenito
2012-02-02 18:26 ` Paul Clark
2012-02-03 13:25 ` Christopher J. PeBenito [this message]
2012-02-03 22:12 ` Paul Clark
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F2BE031.30502@tresys.com \
--to=cpebenito@tresys.com \
--cc=refpolicy@oss.tresys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.