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