LinuxQuestions.org - [SOLVED] SELinux semanage is missing context of unconfied

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - SELinux semanage is missing context of unconfied_u (https://www.linuxquestions.org/questions/linux-security-4/selinux-semanage-is-missing-context-of-unconfied_u-4175572524/)

SELinux semanage is missing context of unconfied_u

I'm trying to troubleshoot some 3rd party software that is having issues with SELinux on RHEL5.

On one RHEL6 server it is working and the other server, RHEL5 it is. I'm guessing because the context is off.

RHEL6

Code:

rwsr-x---. root varonis unconfined_u:object_r:usr_t:s0 vrns_watchdog

RHEL5

Code:

rwsr-x---. root varonis user_u:object_r:usr_t:s0 vrns_watchdog

If I run

Code:

[root@server varonis]# semanage user -l



                Labeling  MLS/      MLS/

SELinux User    Prefix    MCS Level  MCS Range                      SELinux Roles



root            user      s0        SystemLow-SystemHigh          system_r sysadm_r user_r

system_u        user      s0        SystemLow-SystemHigh          system_r

user_u          user      s0        SystemLow-SystemHigh          system_r sysadm_r user_r

[root@server varonis]#

Its missing the context for the user that i need, which is unconfined_u.

Is there a way to add unconfined_u?

thanks

have you ran "audit2allow " on the error log?

and have you contacted RH support

Quote:

Originally Posted by John VV (Post 5501954)

have you ran "audit2allow " on the error log?

and have you contacted RH support

No, I forgot to run audit2allow, however I did look at /var/log/audit.

I try to troubleshoot the best I can before contacting RH.

I'm just wondering if anyone else has seen this?

Not that particular one. I have seen similar differences between releases though.

But after every upgrade you really need to check/relable the system (touch ./autorelable, and reboot would do).

It is also possible to do after the fact using "restorecon -R <pathname>" which will recursively check/set everything in <pathname>. The only issue here is that running processes may get cut off. For some busy systems, that can end up in a reboot anyway.

The best explaination I have seen was that the labels in the filesystem are binary numbers, and between releases the security definitions may change due to new ones added/unused ones removed. This in turn changes the numbers assigned... and thus needing a pass over filesystems to update the definitions.

Quote:

Originally Posted by jpollard (Post 5501970)

But after every upgrade you really need to check/relable the system (touch ./autorelable, and reboot would do).

Recently updated the kernel, which upgraded the the release.

I wasn't aware that if doing this, need to run touch ./autorelabel in order to fix issues. I will make a note of this.

Quote:

Originally Posted by jpollard (Post 5501970)

It is also possible to do after the fact using "restorecon -R <pathname>" which will recursively check/set everything in <pathname>. The only issue here is that running processes may get cut off. For some busy systems, that can end up in a reboot anyway.

I didn't attempt restorecon because in my experience say I moved a file that I touched or created in a different directory, typically will keep its SELinux context. I can try that first before doing the touch ./autorelabel, which can take some time once its kicked off.

thanks

Quote:

Originally Posted by JockVSJock (Post 5501992)

Recently updated the kernel, which upgraded the the release.

I wasn't aware that if doing this, need to run touch ./autorelabel in order to fix issues. I will make a note of this.

It is usually done by upgrade process - but that doesn't mean all file systems are seen as they may have been removed. In my case, I usually remove the home and media filesystems to avoid the possibility of an accidental erasure. Other situations that can require it is in multi-boot situations. A newer system is planned, installed for testing, but without all of the filesystems mounted. When testing finished switch to the new system - and again, the filesystems need to have their security labels updated.

Quote:

If a file is in a directory tree with the wrong security label, it needs to be relabeled as it no longer has a valid context for where it is located.

If the new location is deemed to valid context, then the database needs to be updated, and that will preserve the desired context the next time the labels get updated. The usual case for that would be web content being put in /var/www. These SHOULD be httpd_sys_script_exec_t, httpd_sys_content_t , webalizer_rw_content_t. But moving user files into should be made httpd_sys_content_t so that they cannot be altered by actions of the web server (or the user again). It happens, but the files no longer are protected... If apache is to write on them the label needs to be httpd_sys_rw_content_t.

But that is just being consistent with the compartmented design.

Quote:

Originally Posted by John VV (Post 5501954)

have you ran "audit2allow " on the error log?

SELinux audit2allow generates policies to allow what is denied. I don't think that is a great place to start. I started to look at /var/log/audit first and look for exceptions there.

Right now I'm trying to figure out if its even an SELinux issues.

Today I changed the user context to root and the software still wouldn't run. Matter of fact while troubleshooting /var/log/messages, it just stopped working...maybe its the software...

I also create .autorelabel and rebooted and this didn't change the users found under semanage...maybe its the software...

From troubleshooting this more, this is an application issue. It abruptly stops running on two of my servers, so I don't know why they would think it would be an SELinux issue.