June 19th, 2007

SELinux kernel parameters

Just a quick blog entry about the SELinux kernel parameters.  There are three kernel parameters that you can pass on boot to change the way SELinux runs.  

selinux=0  (Bad idea :^))
        If you want to Disable SELinux entirely.  You can boot the system with the SELINUX=0 kernel parameter.  This will cause the kernel to not load any of the SELinux infrastructure.  The init scripts will notice that you booted with SELINUX=0 and will touch /.autorelabel themselves.  This will cause the machine to automatically relabel the next time you boot with SELINUX enabled.  We do this because anytime you are booted with SELNUX=0 files will not get a label.  So the next time the system boots the SELinux would report these files as file_t and almost no domains can interfact with a file_t (Unlabeled file).  Files like /etc/resolv.conf get recreated at boot time and probably would get this label and the next time SELinux booted, all heck would break loose.

    Setting this parameter will cause the machine to boot in permissive mode.  If your machine will not boot in enforcing mode, this can allow you to boot it and figure out what is wrong.  Sometimes you file system can get so messed  up that this parameter is your only option.  The nice thing about this option, the system continues to create the labels correctly.  The AVC messages that are created via this command can be different then in enforcing mode.    There are two differences in enforcing mode, every access denial is reported, in permissive only the first denial is reported.  However in Enforcing mode you might get a denial on reading a directory and the app will stop.  In permissive mode you would get the same avc message but then you would get an avc for each denial when the app continues reading files in the directory.

This parameter will force the system to relabel.  It does the same thing as "touch /.autorelabe; reboot".    Sometimes, if the machines labeling is really bad, you will need to boot in permissive mode in order for the autorelabel to succeed.  An example of this is switching from strict to targeted policy.  In strict policy shared libraries are labeled as shlib_t while ordinary files in /lib directories are labeled lib_t.  strict policy only allows confined apps to execute shlib_t.  In targeted policy shlib_t and lib_t are aliases.  (Having these files labeled differently is of little security importance and leads to labeling problems in my opinion). So every file in /lib directories gets the label lib_t. 
When you boot a machine that is labeled for targeted with strict policy the confined apps try to execute lib_t labeled shared libraries so and they are denied.  /sbin/init tries this and blows up.  So booting in permissive mode allows the system to relabel the shared libraries as shlib_t and then the next boot can be done in enforcing.