We have a number of different servers all running the same version of RHEL, on the same kernel, all up to date on patches, etc. They have the same SELinux policies applied and the same /etc/selinux/config files.

Yet, on some systems, when I do an ls -lZ on, for example, /etc/httpd/conf the SELinux contexts will show as system_u:object_r:httpd_config_t but on other systems the exact same thing will show system_u:object_r:httpd_config_t:s0.

Why does the 's0' show on some servers and not others? Is there an SELinux setting that I'm missing that controls this? I've looked through the file_contexts and on all servers, it shows that /etc/httpd(/.*)? includes the s0.

Thanks for any tips on this.

No idea.


"s0" is a level. The default policy is targeted. You don't need to control this unless you're running a MLS (Multi-Level Security) policy.

unSpawn,

I agree. All of our SELinux policies are "targeted." I even tried checking to see if one system was Enforcing and another Permissive just in case that would make a difference. I figured there didn't seem to be any other variable I could look at. But they were both Enforcing.

Thanks for the reply, though.

The level remains the same regardless of what state SELinux is in. There's no variables to look at as the level doesn't matter if you're using a "targeted", and not a MLS, policy.

You should check the file below to see how the translations are mapped out.
Though unSpawn is correct, it's more for MLS stuff.

anywho...just for kicks mine shows
Hope that helps...

1 members found this post helpful.

Yeah, I don't get why they're displayed differently on different servers. I did check that file, @Linux MR. The file on both systems is identical. I'm at a loss.

Eureka!!

As it turns out, the common thread here is the mcstransd service. With the service running, it does NOT display the Security Level and with the service stopped, the Service Level is displayed when you use the -Z to list files or processes, etc.

The article that talks about this can be found at:

http://www.redhatmagazine.com/2007/0...linux-daemons/

It's about halfway down the page.

1 members found this post helpful.