MCS issues
Tracy Reed
treed at ultraviolet.org
Fri Feb 20 23:35:23 UTC 2015
Once upon a time I had MCS working under RHEL 5 "Getting Started with
Multi-Category Security (MCS)" doc. Then the project was shelved for a while
and never got deployed. Interest has returned and I am now picking it up again
with our current production-deployed OS which is RHEL 6. It seems things have
changed significantly. The Getting Started doc doesn't work anymore. Is there
any current documentation regarding MCS in 6? I can't seem to find any.
I was discussing this on the selinux at tycho.nsa.gov list when I was reminded
that this list exists and probably has more RHEL/Fedora specific expertise.
I would love to point to the previous discussion on selinux at tycho.nsa.gov but
it seems archives are sadly unavailable or at least Google can't find them.
I am trying to sandbox several instances of the same web app on a bunch of
machines. Each app runs under a username like p16001 or p16002 etc. We also
create a category p16001 and p16002 etc. Each app should only be able to access
files with the category by the same name. In RHEL 5 categories were associated
with usernames and everything was pretty straightforward. Now I have been told
on the other list that categories are associated with user types and that I
need to insert a policy module like so:
policy_module(mytest, 1.0,0)
gen_require(` type user_t; attribute mcsuntrustedproc; ')
typeattribute user_t mcsuntrustedproc;
I have done this but the MCS is not being enforced. The system is in permissive
mode but I expect to see deny messages in the log and there are none.
Some of my current (somewhat mangled via experimentation) config:
[mcstest:/home/users/tracy.reed]# semanage user -l
Labeling MLS/ MLS/
SELinux User Prefix MCS Level MCS Range SELinux Roles
git_shell_u user s0 s0 git_shell_r
guest_u user s0 s0 guest_r
p16001_u user s0 s0:c1 user_r
p16002_u user s0 s0:c2 user_r
root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
sysadm_u user s0 s0-s0:c0.c1023 sysadm_r
system_u user s0 s0-s0:c0.c1023 system_r unconfined_r
unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r
user_u user s0 s0-s0:c0.c1023 user_r
xguest_u user s0 s0 xguest_r
[mcstest:/home/users/tracy.reed]# semanage login -l
Login Name SELinux User MLS/MCS Range
__default__ unconfined_u s0-s0:c0.c1023
p16001 p16001_u s0:c1-s0:c1
p16002 appuser_u s0:c1.c499-s0:c2
p16003 appuser_u s0:c1.c499-s0:c3
p16004 unconfined_u s0-s0:c0.c1023,c4
p16005 unconfined_u s0-s0:c0.c1023,c4,c5
p16006 unconfined_u s0-s0:c0.c1023,c6
p16007 unconfined_u s0-s0:c0.c1023,c7
p16008 unconfined_u s0-s0:c0.c1023,c8
p16009 unconfined_u s0-s0:c0.c1023,c9
root unconfined_u s0-s0:c0.c1023
system_u system_u s0-s0:c0.c1023
p16001 is associated with p16001_u and has category c1 which all seems fine.
# ssh p16001 at localhost
p16001 at localhost's password:
Last login: Thu Feb 19 18:06:54 2015 from localhost
-bash-4.1$ cd /glide/
backup/ include/ lib64/ share/
bin/ java/ logs/ snc-provision/
chroot/ java-1.6.0_45.i586/ nodes/ temp/
cid/ lib/ runbooktmp/
-bash-4.1$ cd /glide/
backup/ include/ lib64/ share/
bin/ java/ logs/ snc-provision/
chroot/ java-1.6.0_45.i586/ nodes/ temp/
cid/ lib/ runbooktmp/
(reverse-i-search)`': ^C
-bash-4.1$ cd /glide/nodes/
-bash-4.1$ ls
p16001 p16002 p16003
-bash-4.1$ ls -laZ
drwxr-xr-x. root root system_u:object_r:default_t:s0 .
drwxrwxr-x. root root system_u:object_r:default_t:s0 ..
drwxr-xr-x. p16001 p16001 user_u:object_r:default_t:s0:c1 p16001
drwxr-xr-x. p16002 p16002 user_u:object_r:default_t:s0:c2 p16002
drwxr-xr-x. p16003 p16003 user_u:object_r:default_t:s0:c3 p16003
-bash-4.1$ cd p16001/
-bash-4.1$ ls -laZ
drwxr-xr-x. p16001 p16001 user_u:object_r:default_t:s0:c1 .
drwxr-xr-x. root root system_u:object_r:default_t:s0 ..
-rw-r--r--. p16001 p16001 user_u:object_r:default_t:s0:c1 testfile
-bash-4.1$ cat testfile
I am 16001
-bash-4.1$
-bash-4.1$ pwd
/glide/nodes/p16001
-bash-4.1$ cd ../p16002/
-bash-4.1$ ls -laZ
drwxr-xr-x. p16002 p16002 user_u:object_r:default_t:s0:c2 .
drwxr-xr-x. root root system_u:object_r:default_t:s0 ..
-rw-r--r--. p16002 p16002 user_u:object_r:default_t:s0:c2 testfile
-bash-4.1$ cat testfile
I am 16002
-bash-4.1$ id
uid=16001(p16001) gid=16001(p16001) groups=16001(p16001) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Hmm...now for some reason my p16001 user is in unconfined. So I now have two
problems: Why is this p16001 user not confined?
The output of semanage login -l (maps linux users to selinux users) shows linux
user p16001 associated with selinux user p16001_u:
p16001 p16001_u s0:c1-s0:c1
And the output of semange user -l shows:
p16001_u user s0 s0:c1 user_r
So why would p16001 be unconfined and MCS not enforcing?
Any tips that can be provided are greatly appreciated!
--
Tracy Reed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/selinux/attachments/20150220/6fbc0bf6/attachment.sig>
More information about the selinux
mailing list