HardySELinux
7238
Comment:
|
10281
|
Deletions are marked like this. | Additions are marked like this. |
Line 7: | Line 7: |
* '''Contributors''': ChadSellers | * '''Contributors''': ChadSellers, CalebCase |
Line 22: | Line 22: |
* Sylar wants to learn more about how SELinux works. He installs the selinux packages, and they handle switching from AppArmor to SELinux, and provides a targeted policy by default. * Issac was using SELinux but wants to switch back to AppArmor. He uninstalls the selinux packages, which unlabels his filesystems and restores AppArmor to a working state. * Claire wants to contribute to the development of a strict SELinux policy. She installs selinux and is able to build, test, and share new policies. |
* Sylar wants to learn more about how SELinux works. He installs the SELinux packages, and they handle switching from AppArmor to SELinux, and provides a targeted policy by default. * Issac was using SELinux but wants to switch back to AppArmor. He uninstalls the SELinux packages and reinstalls the AppArmor ones. * Claire wants to contribute to the development of a strict SELinux policy. She installs SELinux's development packages and is able to build, test, and share new policies. * Jan has an SELinux system and wants to install a custom policy module to be used in conjunction with the standard targeted policy. |
Line 50: | Line 51: |
A new Preferences UI would be provides for choosing Security mechanisms. This would be similar to the UI provided by the installer. | A new Preferences UI would provide for choosing Security mechanisms. This would be similar to the UI provided by the installer. |
Line 61: | Line 62: |
2. Create the scripts for use in the initrd. | 1. Create the scripts for use in the initrd. |
Line 64: | Line 65: |
The policy loading script installation and the process of updating initramfs will be handled by the selinux package. |
|
Line 71: | Line 74: |
The breakdown of the policy would be as follows: ||Debian Package||Reference Policy Module||Description|| ||selinux-policy-refpolicy||base.pp||This contains the base policy module. The base policy module contains essential policy mainly from the kernel layer (core policy for executables, networking, devices, domains (processes), filesystems, etc).|| ||selinux-policy-refpolicy-unconfined||unconfined.pp|| This contains the unconfined policy module. The unconfined policy is a catch all policy that applies to everything that isn't explictly covered in the base module (base.pp) or another specific module (i.e. cups.pp). As the name implies, this module doesn't limit activities of the programs, users that it covers.|| ||selinux-policy-refpolicy-cups||cups.pp||This contains the Common UNIX Printing System policy module.|| ==== Custom Policy ==== Using a modular policy has the benefit that it is possible to support custom policy modules. The proposed method of doing this is to have an /etc/selinux.d directory that contains the policy packages that should be installed/loaded. When a debian package is installed/removed that supplies a policy package it adds/removes itself (or a symlink to itself) to /etc/selinux.d and triggers semodule (which is a trigger registered by the policycoreutils package). The script that handles the semodule trigger then checks the loaded modules and the ones found in /etc/selinux.d and adds/removes them via the semodule utility. The selinux-policy-refpolicy* packages will place their policy packages into /etc/selinux.d/refpolicy. It is also possible that the user doesn't want to use the policy shipped with Hardy (for example, compling and installing a newer version of Reference Policy). The user has several options, but to make this as simple as possible we are providing an selinux-policy-dummy package that satisifes the necessary debian Provide: selinux-policy. |
|
Line 76: | Line 94: |
* disable loading of the AppArmor module * add selinux=1 to the kernel command line in grub.conf |
* disable the AppArmor module (apparmor.enabled=0) * enable the SELinux module (selinux=1) |
Line 80: | Line 98: |
* enable loading of the AppArmor module * remove selinux=1 from the kernel command line in grub.conf |
* enable the AppArmor module (remove apparmor.enabled=0, it is on by default) * disable the SELinux moduel (remove selinux=1, it is off by default) |
Line 84: | Line 102: |
Additionally, when switching to SELinux, the filesystem must be relabeled (as SELinux provides label-based security). This requires relabeling the filesystem during the subsequent system boot, and probably rebooting again (though the second boot can be avoided if the relabel happens early enough in the boot process). | These flags are passed by the bootloader to the kernel. Ubuntu uses update-grub to manage the Grub menu.lst configuration file. update-grub regenerates the menu options (generally whenever a new kernel is installed). The above kernel options should be placed in either the kopt or defoptions options of update-grub's meta configuration of menu.lst. Placing it in the kopt line will add them to all the kernels whereas defoptions only affects the default kernels (not the alternatives). |
Line 86: | Line 104: |
==== Quick and Dirty HOWTO ==== | Additionally, when switching to SELinux, the filesystem must be relabeled (as SELinux provides label-based security). The disk may be relabeled on shutdown. A shutdown relabel has the advantage that the system doesn't need to be rebooted twice on startup (once to relabel, and again to boot with everthing labeled correctly). The drawback to a shutdown relabel is that it may or may not happen (system is shutdown incorrectly). As a fallback the system will still relabel on startup if necessary. |
Line 88: | Line 106: |
1. Remove apparmor-utils, because the selinux package conflicts with it. From aptitude, go to Options / Preferences, deselect 'Install recommended packages automatically'. In the future, the ubuntu-standard package should recommend "linux-security", and have apparmor-utils provide that virtual package. | The switching process will be handled by the selinux package. |
Line 90: | Line 108: |
2. Install the package 'selinux' and 'refpolicy', and their associated dependencies. | == Quick and Dirty HOWTO == |
Line 92: | Line 110: |
3. As the debconf message states, the user must modify his bootloader. Assuming that he has a default ubuntu install, he will need to modify his /boot/grub/menu.lst file. Find the line that begins with "#kopt" and append to it "selinux=1 enforcing=0". Then run 'update-grub' to rebuild menu.lst. | This is the current quick and dirty way to get SELinux working with our current packages. It may be broken or otherwise non-functional, but these steps should get a box from a standard Ubuntu installation into an SELinux enabled state for testing and development purposes. |
Line 94: | Line 112: |
4. Reboot. | 1. Update sources.list/sources.d with a repo of the current packages (currently there isn't one built, but the package sources are available from [https://code.launchpad.net/~calebcase/+junk/selinux-support here]). 1. Using aptitude (or your favorite manager), remove apparmor and apparmor-utils. 1. Install selinux and selinux-policy-refpolicy. 1. Modify the menu.lst file to enable SELinux on boot by adding "apparmor.enabled=0 selinux=1" to the "#kopt" line. 1. Run update-grub to regenerate the menu.lst. 1. Reboot. |
HardySELinux
Launchpad Entry: selinux-support
Created: 2007-10-25
Contributors: ChadSellers, CalebCase
Packages affected: selinux-policy-*, policycoreutils
Summary
Provide SELinux as an option for Ubuntu. Much of the support necessary is already inherited from Debian. The remaining pieces include turning on SELinux when loading the kernel, logic for loading the SELinux policy on boot, and tailoring a default SELinux policy.
Rationale
SELinux provides security features that are extremely useful for locking down machines, particularly servers. It provides the ability to isolate processes into domains and create security policy defining what those domains can do. This capability enables users to enforce a large number of security goals, including limiting privilege, containing exploits, preventing privilege escalation, enforcing application security architecture, controlling information flow, and many others.
SELinux is preferred over AppArmor for a number of reasons. Often, this is due to user preference of its inode-based labeling instead of AppArmor's use of pathnames. Also, customers with more stringent security requirements use SELinux. In the past, this has included users such as those from government, financial institutions, embedded systems, and others. For instance, users concerned with information flow often choose SELinux.
Use Cases
Sylar wants to learn more about how SELinux works. He installs the SELinux packages, and they handle switching from AppArmor to SELinux, and provides a targeted policy by default.
Issac was using SELinux but wants to switch back to AppArmor. He uninstalls the SELinux packages and reinstalls the AppArmor ones.
- Claire wants to contribute to the development of a strict SELinux policy. She installs SELinux's development packages and is able to build, test, and share new policies.
- Jan has an SELinux system and wants to install a custom policy module to be used in conjunction with the standard targeted policy.
Design
Security Policy
There are a few SELinux policies in universe (selinux-policy-default, selinux-policy-refpolicy-targeted, selinux-policy-refpolicy-strict) which are all geared toward Debian systems and need tweaking to work with Ubuntu. These policies are quite complex and have a tendency to require expert user intervention to use them. This is probably not the right direction for Ubuntu's default policy, though these policies can definitely continue to exist in universe for expert users wishing to use them. We plan to follow the general targeted model of leaving most things unconfined and offering the ability to confine network daemons, but plan to modify this to ensure that SELinux breaks user systems as infrequently as possible.
The proposed SELinux security policy should be fairly simple and modular. The idea here is to do everything we can to avoid breaking things on the system while at the same time adding some basic security controls. This would mean that all daemons would be unconfined unless the user/admin elected to confine them.
Enabling SELinux
Make SELinux an install-time and/or run-time configuration option. We do not want to replace AppArmor, but rather offer users the choice of SELinux.
Implementation
UI Changes
The only UI changes necessary will likely be those necessary to provide the user with the ability to choose to enable SELinux. This could come in two forms.
Installer Choice
The installer can provide the user with a choice of SELinux, AppArmor, or no security module. This may be an Advanced Option in the LiveCD installer.
Runtime Choice
A new Preferences UI would provide for choosing Security mechanisms. This would be similar to the UI provided by the installer.
Code Changes
Loading SELinux Policy on Boot
SELinux requires the policy to be loaded into the kernel as early in the boot process as possible. SysVInit has been patched in other distros (Fedora, Red Hat, Debian) to do this. Basically, init loads the policy then re-exec's itself so init has the correct label. As Ubuntu uses upstart, there is no SELinux support.
Rather than modify upstart, we will add the SELinux policy load to the initramfs. This will require a few code changes:
- A patch to load_policy to add a flag for doing an initial policy load.
- Create the scripts for use in the initrd.
Note that one downside to this approach is that the initrd image in /boot must be updated after installing the SELinux packages (unless the SELinux initrd package is installed by default).
The policy loading script installation and the process of updating initramfs will be handled by the selinux package.
SELinux Policy
Create a new SELinux policy configuration that is less restrictive by default than those found in Fedora, Debian, or Gentoo. This policy will prevent very little, reducing the chances of breaking unsuspecting users' systems. Users will then be able to select (potentially through apt) policies for their applications that they wish to confine. Additionally, this will provide the foundation for higher-level user-friendly SELinux policy management UIs to be developed in the future.
The list of daemon's for which confinement policies will be available for user selection is still to be determined, but will at least include cups. Confining cups is necessary to ensure that no protection is lost by turning off AppArmor, which currently only confines cups by default.
The breakdown of the policy would be as follows:
Debian Package |
Reference Policy Module |
Description |
selinux-policy-refpolicy |
base.pp |
This contains the base policy module. The base policy module contains essential policy mainly from the kernel layer (core policy for executables, networking, devices, domains (processes), filesystems, etc). |
selinux-policy-refpolicy-unconfined |
unconfined.pp |
This contains the unconfined policy module. The unconfined policy is a catch all policy that applies to everything that isn't explictly covered in the base module (base.pp) or another specific module (i.e. cups.pp). As the name implies, this module doesn't limit activities of the programs, users that it covers. |
selinux-policy-refpolicy-cups |
cups.pp |
This contains the Common UNIX Printing System policy module. |
Custom Policy
Using a modular policy has the benefit that it is possible to support custom policy modules. The proposed method of doing this is to have an /etc/selinux.d directory that contains the policy packages that should be installed/loaded. When a debian package is installed/removed that supplies a policy package it adds/removes itself (or a symlink to itself) to /etc/selinux.d and triggers semodule (which is a trigger registered by the policycoreutils package). The script that handles the semodule trigger then checks the loaded modules and the ones found in /etc/selinux.d and adds/removes them via the semodule utility.
The selinux-policy-refpolicy* packages will place their policy packages into /etc/selinux.d/refpolicy.
It is also possible that the user doesn't want to use the policy shipped with Hardy (for example, compling and installing a newer version of Reference Policy). The user has several options, but to make this as simple as possible we are providing an selinux-policy-dummy package that satisifes the necessary debian Provide: selinux-policy.
Switching Security Modules
In order to switch to a security module, the appropriate security module must be loaded into the kernel and enabled. Currently, SELinux is compiled into the Gutsy kernel but disabled, and can be enabled by passing selinux=1 on the kernel command line. AppArmor is currently loaded as a module. Given this, the following is necessary to switch between them:
AppArmor to SELinux
disable the AppArmor module (apparmor.enabled=0)
- enable the SELinux module (selinux=1)
- reboot
SELinux to AppArmor
enable the AppArmor module (remove apparmor.enabled=0, it is on by default)
- disable the SELinux moduel (remove selinux=1, it is off by default)
- reboot
These flags are passed by the bootloader to the kernel. Ubuntu uses update-grub to manage the Grub menu.lst configuration file. update-grub regenerates the menu options (generally whenever a new kernel is installed). The above kernel options should be placed in either the kopt or defoptions options of update-grub's meta configuration of menu.lst. Placing it in the kopt line will add them to all the kernels whereas defoptions only affects the default kernels (not the alternatives).
Additionally, when switching to SELinux, the filesystem must be relabeled (as SELinux provides label-based security). The disk may be relabeled on shutdown. A shutdown relabel has the advantage that the system doesn't need to be rebooted twice on startup (once to relabel, and again to boot with everthing labeled correctly). The drawback to a shutdown relabel is that it may or may not happen (system is shutdown incorrectly). As a fallback the system will still relabel on startup if necessary.
The switching process will be handled by the selinux package.
Quick and Dirty HOWTO
This is the current quick and dirty way to get SELinux working with our current packages. It may be broken or otherwise non-functional, but these steps should get a box from a standard Ubuntu installation into an SELinux enabled state for testing and development purposes.
Update sources.list/sources.d with a repo of the current packages (currently there isn't one built, but the package sources are available from [https://code.launchpad.net/~calebcase/+junk/selinux-support here]).
- Using aptitude (or your favorite manager), remove apparmor and apparmor-utils.
- Install selinux and selinux-policy-refpolicy.
- Modify the menu.lst file to enable SELinux on boot by adding "apparmor.enabled=0 selinux=1" to the "#kopt" line.
- Run update-grub to regenerate the menu.lst.
- Reboot.
HardySELinux (last edited 2009-09-22 12:53:50 by pool-71-114-226-175)