Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.

8.4. Deploying Customized Binary Policy

Building custom binary policy requires the policy source, but there are security risks to having the full policy source on a production server. Should an attacker gain root control, they could rebuild the policy to weaken or neutralize SELinux. For this reason, you want to use only binary policy on production servers.

If you are using binary policy provided by Red Hat, this is not an issue. You can manage the policy packages as you do any other software packages, such as through Red Hat Network. If you do customize your policy, you may want to manage it using RPM packages, either manually or as part of custom channels in Red Hat Network. Even if you manage the policy files by hand, as this procedure demonstrates, the underlying principles are the same.

Unlike software source code, SELinux policy is independent of the architecture of the system it is built on. You can have multiple development trees with vastly different policy needs expressed, all residing and built in a single development environment. In fact, it is recommended to use software version control, such as CVS, if you are going to be doing any measurable level of customization.

This short procedure demonstrates how to build and deploy policy from a development environment into a production environment.

Building and Deploying Policy

  1. In your development environment, make a copy of the source tree for the policy you are working from. If you want to add a single daemon to confinement under the targeted policy, use /etc/selinux/targeted/src/policy/. If you want to work from a fully confined SELinux environment, obtain and use the strict source, which is usually at /etc/selinux/strict/.

    # Copy the entire tree to a custom/ directory:
    
    cp -r /etc/selinux/targeted/ /etc/selinux/custom/
    
  2. Build and test your policy. You can test locally on your development machine, or follow the outline of this procedure to deploy custom binary policy files to your test environment. Use apol to analyze your policy, as described in Section 6.3 Using apol for Policy Analysis.

  3. When you are ready to deploy, use tar to pack your policy files. Notice that the source directory is not included.

    tar -czvf tgt.tgz targeted/policy/ targeted/contexts/ \
      targeted/booleans
    

    Alternately, you can use star so that you can preserve the xattrs for the policy files. This is explained in Section 5.1.4 Make Backups or Archives That Retain Security Contexts. However, since you are going to initiate a relabel on boot anyway, you can use tar instead. The policy files unpack and gain the default file label such as system_u:object_r:default_t and are relabeled upon boot.

  4. If this is the first time the custom policy has been deployed on this system, you need to configure SELinux to use the policy on the next boot.

    Note Note
     

    It is extremely difficult to change policy without rebooting the system. The file system needs to be relabeled and every process starting with init needs to be restarted under the new policy. This is the reason rebooting is required for switching policy.

    In /etc/selinux/config, change the value for SELINUXTYPE to the name of the new policy. The name is the same as the directory name in /etc/selinux. For example, the custom policy at /etc/selinux/custom/ has the value of SELINUXTYPE=custom.

    You can do this using system-config-securitylevel. Under the SELinux tab, change the Policy Type: to custom. This area of system-config-securitylevel is automatically populated from the names of actual policy directories under /etc/selinux/.

  5. Initiate a reboot and relabel.

    touch /.autorelabel
    reboot
    
  6. If you have troubles getting the custom policy to work on the test or production environment, work through the denials like you did when writing the policy in the first place.

    1. Make sure the file system is labeled correctly. If you cannot touch /.autorelabel, either use setenforce 0 or boot into permissive mode.

      You may need to boot into single-user mode and attempt a manual relabel of the file system. Although this is not normally recommended, it can be a working method to get enough labeling correct to have the /.autorelabel work correctly. You can read more about this at Section 5.2.2 Relabel a File System.

    2. Work through the denial errors one at a time. You may need to temporarily install the policy source to relabel or rebuild the policy.

 
 
  Published under the terms of the GNU General Public License Design by Interspire