I have a Linux VM that I inherited and I'm running into some strange permission issues around selinux that I'm hoping someone can help me out with. I started with the simple things:

# setenforce 0
setenforce: setenforce() failed

My id is:
# id
uid=0(root) gid=0(root) grupos=0(root) context=root:sysadm_r:sysadm_t:s0-s15:c0.c1023

If I try to edit /etc/selinux/config I get a warning about it being a read only file

Running sestatus results in the following:
# /usr/sbin/sestatus
-bash: /usr/sbin/sestatus: Permission denied

# ls -la /usr/sbin | grep sestatus
-?????????? ? ? ? ? ? sestatus

A couple of other things that I have checked:
# getsebool -a | grep secure
secure_mode --> off
secure_mode_insmod --> off
secure_mode_policyload --> off

I'm not sure where else to check or what to look for. If anyone has any ideas they are certainly welcomed.

Anything in the kernel message buffer? Run dmesg to check.

That's normal if the file is read-only. As root, you can write to it anyway.
Does the directory /usr/sbin have correct permissions?

I would also check whatever log file contains SELinux messages (/var/log/auth/auth.log on Centos, I think), and run a filesystem check.

You are logged in as systems administrator, sysadm is not allowed to do security administration in MLS systems. You need to login as security administrator (secadm) instead if you want to touch SELinux.

I will expand on the above answer a little bit.

You noted that `id` returns:
uid=0(root) gid=0(root) grupos=0(root) context=root:sysadm_r:sysadm_t:s0-s15:c0.c1023

The "s0-s15:c0.c1023" part of the "context=" indicates to me that this system enforces confidentiality using what is called "Multi-level security". Enforcement of confidentiality is a very niche use-case. Usually government of DoD type parties.

https://en.wikipedia.org/wiki/Bell%E...LaPadula_model

In these environments there are verious roles like sysadm_r for systems administration, secadm_r for security administration, auditadm_r for audit administrators.

So depending on your task you assume the appropriate role. There are various way's to configure this. At login time with "pam_selinux" and at runtime with "newrole".

1 members found this post helpful.

SELinux with the targeted policy is enabled and enforced on all Red Hat and Centos system out of the box, without secadm user. It's likely that this is the case here as well.

This system does not enforce targeted policy. It enforces MLS policy.

Thanks for the help everyone, this is all very interesting to me since I haven't really worked with anything like this before. I've been working on this a little more and originally tried just running a newrole command but got the output of

Error: you are not allowed to change levels on a non secure terminal

I checked /etc/securetty and ran the command chvt to change to tty2 which matched up with what was listed in /etc/securetty

Now I can create a new role, but I've never created anything like this before. Would it be easier to create a new user and assign them a role that would give them proper access, or would it be better to just re-assign the role of the root user?

Thanks again for all of the help!

No because you need root regardless of whether you use sysadm_r, secadm_r, or auditadm_r.

Newrole is cumbersome but you can make it a little less painful. For example you can add the "pam_rootok" pam module to newroles' pam stack so that you dont have to type root's password each time you run newrole.

You can also look into appending the "select_context" option to the "pam_selinux open" call in logins' pam stack. This will then make login ask you for a role and optionally a security level. You might then be able to just log in with one of the three administrator roles depending on what task you want to perform.

Unless you are familiar with the concept of confidentiality and "no read up/no write down" you probably should not try to manipulate the policy, as you might create holes in the model.

I am a bit rusty with MLS but if I recall correctly:

The staff_u SELinux identity *should* be authorized to the sysadm_r, auditadm_r, and secadm_r roles I believe.

So you could create a new user and associate that user with the existing staff_u identity. Something like: `useradd -Z staff_u joe`

Then you should be able to use `su` to switch to root and to use `newrole` to transition to any of the three privileged roles.

In theory I suppose you could create three seperate "staff_u" like identities and authorize each to a specific privileged role.

for example:
"joe_u { staff_r auditadm_r } s0-s15:c0.c1023"
"jane_u { staff_r sysadm_r } s0-s15:c0.c1023"
"foo_u { staff_r secadm_r } s0-s15:c0.c1023"

But they still need newrole to transition from staff_r to any of the privileged roles, the also need the root password to get root access with su. The auditadm_r, secadm_r, and sysadm_r roles are privileged roles that are meant to be associated with root afterall

And besides. if the root SELinux identity is authorized to all three privileged roles then any of the users with root password and physical access can access any of the three privileged roles anyway I suppose.

If I is important for you to be able to properly operate MLS systems then I suggest you install some virtualized systems, configure MLS and play with that a little in your spare time. It is not the easiest environment to operate in.