(Imported from MoinMoin)
m (1 revision(s))
Revision as of 16:29, 24 May 2008
The original SELinux config files was stored in /etc/sysconfig/selinux, and it still exists as a symlink to /etc/selinux/config. Where all the magic of selinux starts. libselinux reads this file to figure out how the system is configured.
This file usually looks like this.
In FC5 there are two additional variables, which I will talk about later.
# SETLOCALDEFS= Check local definition changes SETLOCALDEFS=0
This file is read by libselinux and is used to determine the mode to run SELinux in and which policy to use. When booting up the machine, init uses libselinux to read this file, and determines which policy to load and what mode to put the machine in.
- SELINUX - variable can have one of three settings.
- This tells the system to run with SELinux watching all system access checks and to stop all "Denied" access.
- This should be the default mode.
- The kernel is blocking all access unless they are explicitly allowed. All denied accesses are reported in the logging system as AVC (Access Vector Cache), unless policy writers have explicitly told the kernel to dontaudit the message.
- The kernel will report Access Violations in the form of AVC messages but will allow the access.
- The kernel will also continue to create properly labeled files.
- There is a couple of major differences with the way the kernel reports these avc messages.
1. The kernel will only report the first access violation in permissive mode for a confined domain on a particular object, where as in enforcing mode, it will report each and every denied access. 2. You can get many additional AVC messages that would never have shown up in enforcing mode. For example if a confined domain was not allowed to read a directory or any of the files in it. In enforcing mode the directory access would be denied and one AVC message would be generated. In Permissive mode, the directory access would generate an AVC, and each file read would generate an AVC.
- When reporting AVC Messages we would prefer that you report avc messages in Enforcing mode. But sometimes Permissive mode is necessary to get all the AVC Messages. You can boot the kernel in permissive mode with the enforcing=0 switch.
- You can use setenforce 0 to turn on permissive mode. setenforce 1 to turn on enforcing mode.
- Disabled tells the init program to disable SELinux altogether from the system. This is only read at boot time, so if you want to disable SELinux, you need to set this flag and then reboot.
- Turns off SELinux enforcement entirely and also stops the creation of proper labels on the files.
- You should only disable SELinux if you do not intend to use it. You should use permissive mode when diagnosing a problem.
- If you want to disable SELinux, you need to edit /etc/selinux/config and change the SELINUX line to disabled. You will then need to reboot the machine, since SELinux is running within the kernel.
- If you wish to re-enable SELinux you will need to relabel the entire file system.
There are two kernel parameters that can override these settings. If you want to boot a system with SELinux disabled you can enter the selinux=0 boot param. This will cause init to not even look at the /etc/selinux/config directory. You can cause the machine to boot in permissive mode by booting with the enforcing=0 parameter. And you can cause it to boot in enforcing mode with the enforcing=1 parameter.
- This tells libselinux which directory to look into for the rest of the SELinux configuration files. So if you do an everything install in FC5 you will see /etc/selinux/mls, /etc/selinux/targeted, /etc/selinux/strict directories. You can choose any one of these or create your own, using the base name of the directory path. Set the flag with the base name, (targeted, strict, mls, mypolicy). touch /.autorelabel; reboot. And your machine will come up with the different policy. That is the theory at least. For certain policies (MLS) you will need to boot in permissive mode and then switch to enforcing when the relabel is complete.
Now what about those other two fields. I call these the Wizard of Oz fields, "Ignore the man behind the curtain". So don't touch these fields unless you know what you are doing. I don't touch these flags either.
- SETLOCALDEFS tells the init and load_policy process whether is is using the new management infrastructure or not. If not it reads in the local customizations, booleans and users. Since going forward we are going to use the new infrastructure this should always be set to 0.
- REQUIRESEUSERS, which can be used to mandate that if there is no match in seusers and no default entry, we fail the login instead of falling back to performing a lookup of the user in policy and ultimately falling back to user_u.
My advise, don't touch these flags.