[refpolicy] mls_systemlow is within mls_systemhigh?

[refpolicy] mls_systemlow is within mls_systemhigh?

[HarryCiao]

Hi all,

I seems to run into a weird problem, that a staff user(t2 in below example) that could only assume mls_systemhigh could log in system successfully with some other lower security level such as mls_systemlow !

Shouldn't such login be denied?

The openssh source code calls libselinux API of security_compute_av() to check if the source context of staff_u:staff_r:staff_t:s0 is ever contained in that of staff_u:staff_r:staff_t:s15:c0.c1023, which could be reproduced by the compute_av command:

[root/sysadm_r/s0 at QtCao ~]# compute_av staff_u:staff_r:staff_t:s15:c0.c1023 staff_u:staff_r:staff_t:s0 context 
allowed= { contains }
[root/sysadm_r/s0 at QtCao ~]# 

How come this ever happen?  Is there a selinuxfs kernel driver bug for /selinux/access file?

Any comment is greatly welcomed. The detailed logs are below.

Thanks a lot!
Harry

-------------------------------

cao at cao-laptop:/home/qemu_usage/pc$ ssh -l t2/staff_r/s0 172.18.0.2
t2/staff_r/s0 at 172.18.0.2's password: 
Last login: Sat Feb 12 07:14:15 2011 from 172.18.0.1
 
-bash-3.2$ id -Z
staff_u:staff_r:staff_t:s0
-bash-3.2$ /usr/sbin/getenforce 
Enforcing
-bash-3.2$


[root/sysadm_r/s0 at QtCao ~]# semanage login -l

Login Name                SELinux User              MLS/MCS Range            

__default__               user_u                    s0                       
root                      root                      s0-s15:c0.c1023          
staff                     staff_u                   s0-s15:c0.c1023          
system_u                  system_u                  s0-s15:c0.c1023          
t2                        staff_u                   s15:c0.c1023             
[root/sysadm_r/s0 at QtCao ~]#

[root/sysadm_r/s0 at QtCao ~]# date
Fri Feb 11 06:08:25 GMT 2011
[root/sysadm_r/s0 at QtCao ~]# newrole -l s15:c0.c1023 -- -c "ps Z -C sshd"
Password: 
LABEL                             PID TTY      STAT   TIME COMMAND
system_u:system_r:sshd_t:s0-s15:c0.c1023 488 ? Ss     0:00 /usr/sbin/sshd
system_u:system_r:sshd_t:s0-s15:c0.c1023 610 ? Ss     0:02 sshd: root at pts/0 
system_u:system_r:sshd_t:s0-s15:c0.c1023 5165 ? Ss    0:00 sshd: t2 [priv]  
system_u:system_r:sshd_t:s0-s15:c0.c1023 5169 ? S     0:00 sshd: t2 at pts/1   
[root/sysadm_r/s0 at QtCao ~]# 

[root/sysadm_r/s0 at QtCao ~]# strace -e trace=open,read,write compute_av staff_u:staff_r:staff_t:s15:c0.c1023 staff_u:staff_r:staff_t:s0 context 
......
open("/selinux/class/context/index", O_RDONLY|O_LARGEFILE) = 3
read(3, "59", 19)                       = 2
open("/selinux/class/context/perms", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
open("/selinux/class/context/perms/contains", O_RDONLY|O_LARGEFILE) = 4
read(4, "2", 19)                        = 1
open("/selinux/class/context/perms/translate", O_RDONLY|O_LARGEFILE) = 4
read(4, "1", 19)                        = 1
open("/selinux/mls", O_RDONLY|O_LARGEFILE) = 3
read(3, "1", 19)                        = 1
open("/selinux/access", O_RDWR|O_LARGEFILE) = 3
write(3, "staff_u:staff_r:staff_t:s15:c0.c"..., 68) = 68
read(3, "2 ffffffff 0 ffffffff 1 0", 4095) = 25
write(1, "allowed= { contains }\n", 22allowed= { contains }
) = 22
[root/sysadm_r/s0 at QtCao ~]#



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

[refpolicy] mls_systemlow is within mls_systemhigh?

[Stephen Smalley]

On Sat, 2011-02-12 at 09:25 +0000, HarryCiao wrote:
> Hi all,
> 
> I seems to run into a weird problem, that a staff user(t2 in below
> example) that could only assume mls_systemhigh could log in system
> successfully with some other lower security level such as
> mls_systemlow !
> 
> Shouldn't such login be denied?
> 
> The openssh source code calls libselinux API of security_compute_av()
> to check if the source context of staff_u:staff_r:staff_t:s0 is ever
> contained in that of staff_u:staff_r:staff_t:s15:c0.c1023, which could
> be reproduced by the compute_av command:
> 
> [root/sysadm_r/s0 at QtCao ~]# compute_av
> staff_u:staff_r:staff_t:s15:c0.c1023 staff_u:staff_r:staff_t:s0
> context 
> allowed= { contains }
> [root/sysadm_r/s0 at QtCao ~]# 
> 
> How come this ever happen?  Is there a selinuxfs kernel driver bug
> for /selinux/access file?
> 
> Any comment is greatly welcomed. The detailed logs are below.

Looks like policy is configured that way.  policy/mls has this rule:
mlsconstrain context contains
        ( h1 dom h2 );

So as long as the source context high level dominates the target context
high level, the constraint will evaluate to true and the permission will
be allowed.  If you want to enforce a minimal level for a user, you'd
have to rewrite that constraint, e.g.
mlsconstrain context contains 
	( ( h1 dom h2 ) and (l1 domby l2) );


-- 
Stephen Smalley
National Security Agency

[refpolicy] mls_systemlow is within mls_systemhigh?

[HarryCiao]

Hello Stephan,

Many many thanks to your reply!

So far I am still a new-comer for all those MLS rules, didn't realize the solution to this problem lies there.

Yep, if one MLS range contains another, then the latter must be a part of the former. Now the compute_av could generate the expected result:

sh-3.2# /usr/sbin/compute_av system_u:system_r:sysadm_t:s0-s15:c0.c1023 system_u:system_r:sysadm_t:s0 context     
allowed= { contains }
sh-3.2# /usr/sbin/compute_av system_u:system_r:sysadm_t:s15:c0.c1023 system_u:system_r:sysadm_t:s0 context
allowed= null
sh-3.2#

I will try to submit a patch for the refpolicy.

Many thanks for your help again!

Best regards,
Harry


> Subject: Re: [refpolicy] mls_systemlow is within mls_systemhigh?
> From: sds at tycho.nsa.gov
> To: harrytaurus2002 at hotmail.com
> CC: refpolicy at oss1.tresys.com; dwalsh at redhat.com
> Date: Mon, 14 Feb 2011 08:26:35 -0500
> 
> On Sat, 2011-02-12 at 09:25 +0000, HarryCiao wrote:
> > Hi all,
> > 
> > I seems to run into a weird problem, that a staff user(t2 in below
> > example) that could only assume mls_systemhigh could log in system
> > successfully with some other lower security level such as
> > mls_systemlow !
> > 
> > Shouldn't such login be denied?
> > 
> > The openssh source code calls libselinux API of security_compute_av()
> > to check if the source context of staff_u:staff_r:staff_t:s0 is ever
> > contained in that of staff_u:staff_r:staff_t:s15:c0.c1023, which could
> > be reproduced by the compute_av command:
> > 
> > [root/sysadm_r/s0 at QtCao ~]# compute_av
> > staff_u:staff_r:staff_t:s15:c0.c1023 staff_u:staff_r:staff_t:s0
> > context 
> > allowed= { contains }
> > [root/sysadm_r/s0 at QtCao ~]# 
> > 
> > How come this ever happen?  Is there a selinuxfs kernel driver bug
> > for /selinux/access file?
> > 
> > Any comment is greatly welcomed. The detailed logs are below.
> 
> Looks like policy is configured that way.  policy/mls has this rule:
> mlsconstrain context contains
>         ( h1 dom h2 );
> 
> So as long as the source context high level dominates the target context
> high level, the constraint will evaluate to true and the permission will
> be allowed.  If you want to enforce a minimal level for a user, you'd
> have to rewrite that constraint, e.g.
> mlsconstrain context contains 
> 	( ( h1 dom h2 ) and (l1 domby l2) );
> 
> 
> -- 
> Stephen Smalley
> National Security Agency
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110215/6d6874e0/attachment.html