From: pcclark@nps.edu (Paul Clark) Date: Thu, 2 Feb 2012 10:26:21 -0800 Subject: [refpolicy] MLS file upgrade In-Reply-To: <4F2AAA61.3090304@tresys.com> References: <4F29E259.60205@nps.edu> <4F2AAA61.3090304@tresys.com> Message-ID: <4F2AD54D.60804@nps.edu> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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 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. >