Gentoo Logo

Gentoo SELinux Handbook

Content:

A. Installing Gentoo SELinux

1. Gentoo SELinux Installation

1.a. Gentoo SELinux Installation

Warning: SELinux is only supported on servers. Workstation support will happen in the future.

The installation of Gentoo SELinux is the same as regular Gentoo. The regular install should be followed from the Gentoo Handbook, keeping in mind the following notes. Then the system should converted to SELinux using the SELinux Conversion Guide.

1.b. Installation Notes

Filesystems

Only ext2, ext3, JFS and XFS are supported at this time.

XFS users should use 512 byte inodes (the default is 256). SELinux uses extended attributes for storing security labels in files. XFS stores this in the inode, and if the inode is too small, an extra block has to be used, which wastes a lot of space, and incurs performace penalties.

Code Listing 2.1: Example XFS filesystem creation command

# mkfs.xfs -i size=512 /dev/hda3

Kernel

Warning: Kernels 2.6.14 and 2.6.15 have broken SELinux XFS support.

You can save time by looking ahead to the kernel options required for SELinux, to save compiling the kernel multiple times.

B. Converting to Gentoo SELinux

1. Initial preparations

1.a. Change Profile

Warning: SELinux is only supported on ext2/3, XFS, and JFS. Other filesystems lack the complete extended attribute support.

Warning: Users should convert from a 2006.1 or newer profile otherwise there may be unpredictable results.

Important: As always, keep a LiveCD at hand in case things go wrong.

First switch your profile to the SELinux profile for your architecture:

Code Listing 1.1: Switch profiles

# rm -f /etc/make.profile

x86:
# ln -sf /usr/portage/profiles/selinux/2007.0/x86 /etc/make.profile
x86 (hardened):
# ln -sf /usr/portage/profiles/selinux/2007.0/x86/hardened /etc/make.profile
AMD64:
# ln -sf /usr/portage/profiles/selinux/2007.0/amd64 /etc/make.profile
AMD64 (hardened):
# ln -sf /usr/portage/profiles/selinux/2007.0/amd64/hardened /etc/make.profile

Important: Do not use any profiles other than the ones listed above, even if they seem to be out of date. SELinux profiles are not necessarily created as often as default Gentoo profiles.

Important: The SELinux profile has significanly fewer USE flags asserted than the default profile. Use emerge info to see if any use flags need to be reenabled in make.conf.

Note: It is not necessary to add selinux to your USE flags in make.conf. The SELinux profile already does this for you.

Note: You may encounter this message from portage: "!!! SELinux module not found. Please verify that it was installed." This is normal, and will be fixed later in the conversion process.

1.b. Update Kernel Headers

We will start by updating essential packages. First check which version of linux-headers is installed.

Code Listing 2.1: Check linux-headers version

# emerge -s linux-headers
or if you have gentoolkit installed:
# equery list -i linux-headers

If the linux-headers version is older than 2.4.20, newer headers must be merged.

Code Listing 2.2: Merge newer headers

# emerge \>=sys-kernel/linux-headers-2.4.20

1.c. Update Glibc

If you have merged new headers, or you are unsure if your glibc was compiled with newer headers, you must recompile glibc.

Code Listing 3.1: Recompile glibc

# emerge glibc

Important: This is a critical operation. Glibc must be compiled with newer linux-headers, otherwise some operations will malfunction.

2. Boot SELinux Kernel

2.a. Merge a SELinux Kernel

Merge an appropriate kernel. A 2.6 kernel is required. The suggested kernel is hardened-sources.

Warning: Kernels 2.6.14 and 2.6.15 should not be used by XFS users as they have bugs in the SELinux XFS support.

Code Listing 1.1: Merge an appropriate kernel

Any 2.6 kernel
# emerge hardened-sources

2.b. Compile the Kernel with SELinux Options

The kernel must be compiled with security module support, SELinux support, devpts, and extended attribute security labels. Refer to the main installation guide for futher kernel options.

Code Listing 2.1: Location and required options under menuconfig

Under "Code maturity level options"
[*] Prompt for development and/or incomplete code/drivers

Under "General setup"
[*] Auditing support
[*]   Enable system-call auditing support

Under "File systems"
<*> Second extended fs support (If using ext2)
[*]   Ext2 extended attributes
[ ]     Ext2 POSIX Access Control Lists
[*]     Ext2 Security Labels
<*> Ext3 journalling file system support (If using ext3)
[*]   Ext3 extended attributes
[ ]     Ext3 POSIX Access Control Lists
[*]     Ext3 Security labels
<*> JFS filesystem support (If using JFS)
[ ]   JFS POSIX Access Control Lists
[*]   JFS Security Labels
[ ]   JFS debugging
[ ]   JFS statistics
<*> XFS filesystem support (If using XFS)
[ ]   Realtime support (EXPERIMENTAL)
[ ]   Quota support
[ ]   ACL support
[*]   Security Labels

Under "Pseudo filesystems (via "File systems")
[ ] /dev file system support (EXPERIMENTAL)
[*]   /dev/pts Extended Attributes
[*]     /dev/pts Security Labels    
[*] Virtual memory file system support (former shm fs)
[*]   tmpfs Extended Attributes
[*]     tmpfs Security Labels

Under "Security options"
[*] Enable different security models
[*]   Socket and Networking Security Hooks
<*>   Default Linux Capabilities
[*] NSA SELinux Support
[ ]   NSA SELinux boot parameter
[ ]   NSA SELinux runtime disable
[*]   NSA SELinux Development Support
[ ]   NSA SELinux AVC Statistics
(1)   NSA SELinux checkreqprot default value
[ ]   NSA SELinux enable new secmark network controls by default
[ ]   NSA SELinux maximum supported policy format version

Note: The available options may vary slightly depending on the kernel version being used. The other extended attribute options should be turned off.

The extended attribute security labels must be turned on for devpts and your filesystem(s). Devfs is not usable in SELinux, and should be turned off. Not all options exist on older 2.6 kernels, such as Auditing support, and runtime disable. In newer kernels, the extended attributes support for proc and the virtual memory fs (tmpfs) are enabled by default; thus, no options will appear in menuconfig.

Warning: Do not enable the SELinux MLS policy option if its available, as it is not supported, and will cause your machine to not start.

Now compile and install the kernel and modules, but do not reboot.

2.c. Update fstab

SElinuxfs must also be enabled to mount at boot. Add this to /etc/fstab:

Code Listing 3.1: Fstab settings for selinuxfs

none	/selinux	selinuxfs	defaults	0	0

2.d. Configure Baselayout

SELinux does not support devfs. You must configure baselayout to use either static device nodes or udev. If using udev, the device tarball must be disabled. Edit the /etc/conf.d/rc file. Set RC_DEVICES to static or udev, and RC_DEVICE_TARBALL to no. If you have several custom device nodes, static is suggested, otherwise udev is suggested.

Code Listing 4.1: Init script configuration

# Use this variable to control the /dev management behavior.
#  auto   - let the scripts figure out what's best at boot
#  devfs  - use devfs (requires sys-fs/devfsd)
#  udev   - use udev (requires sys-fs/udev)
#  static - let the user manage /dev

RC_DEVICES="udev"

# UDEV OPTION:
# Set to "yes" if you want to save /dev to a tarball on shutdown
# and restore it on startup.  This is useful if you have a lot of
# custom device nodes that udev does not handle/know about.

RC_DEVICE_TARBALL="no"

2.e. Reboot

We need to make some directories before we reboot.

Code Listing 5.1: Making Required Directories

# mkdir /selinux
# mkdir /sys

Now reboot.

3. Install SELinux Userland

3.a. Merge SELinux Packages

Merge the libraries, utilities and base-policy. The policy version may need be adjusted, refer to the SELinux Overview for more information on policy versions. Then load the policy.

Code Listing 1.1: Merge base SELinux packages and policy

# emerge checkpolicy policycoreutils
# FEATURES=-selinux emerge selinux-base-policy

Note: The "FEATURES=-selinux" part of the emerge command should only be used on the above command. It is required to merge selinux-base-policy (only for the first time) as the portage SELinux features require both policycoreutils and selinux-base-policy otherwise portage will fail.

3.b. Choose the policy type

New in 2006.1, users now have the choice between the strict policy and the targeted policy.

In the strict policy, all processes are confined. If you are familiar with pre 2006.1 Gentoo SELinux policy, that policy was a strict policy. Strict policy is suggested for servers. Gentoo does not support the strict policy on desktops.

The targeted policy differs with strict, as only network-facing services are confined and local users are unconfined. Gentoo only supports desktops with the targeted policy. This policy can also be used on servers.

Edit the /etc/selinux/config file to set the policy type.

Code Listing 2.1: /etc/selinux/config contents

# This file controls the state of SELinux on the system on boot.

# SELINUX can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - No SELinux policy is loaded.
SELINUX=permissive (This should be set permissive for the remainder of the install)

# SELINUXTYPE can take one of these two values:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.
SELINUXTYPE=strict (Set this as strict or targeted)

3.c. Merge SELinux-patched packages

There are several system packages that have SELinux patches. These patches provide a variety of additional SELinux functionality, such as displaying file contexts.

Code Listing 3.1: Remerge Packages

# emerge sysvinit pam coreutils findutils openssh procps psmisc shadow util-linux python-selinux

Note: If you find that you can't use portage due to a errors like these: !!! 'module' object has no attribute 'secure_rename' or AttributeError: 'module' object has no attribute 'getcontext', this is a portage bug, where it can't handle a missing python-selinux. Merge it with "FEATURES=-selinux emerge python-selinux" to fix the problem. See bug #122517 for more information.

There are other packages that have SELinux patches, but are optional. These should be remerged if they are already installed, so the SELinux patches are applied:

  • app-admin/logrotate
  • sys-apps/fcron
  • sys-apps/vixie-cron
  • sys-fs/device-mapper
  • sys-fs/udev
  • sys-libs/pwdb

Note: Fcron and Vixie-cron are the only crons with SELinux support.

3.d. Merge Application Policies

In future, when merging a package, the policy will be set as a dependency so that it is merged first; however, since the system is being converted, policy for currently installed packages must be merged. The selinux-base-policy already covers most packages in the system profile.

Look in the /usr/portage/sec-policy, it has several entries, each which represent a policy. The naming scheme is selinux-PKGNAME, where PKGNAME is the name of the package that the policy is associated. For example, the selinux-apache package is the SELinux policy package for net-www/apache. Merge each of the needed policy packages and then load the policy. If you are converting a desktop, make sure to include the selinux-desktop policy package.

Code Listing 4.1: Example Merge of Apache and BIND policies

# ls /usr/portage/sec-policy
(many directories listed)

# emerge selinux-apache selinux-bind

3.e. Label Filesystems

Now label the filesystems. This gives each of the files in the filesystems a security label. Keeping these labels consistent is important.

Code Listing 5.1: Label filesystems

# rlpkg -a -r

Warning: There is a known issue with older versions of GRUB not being able to read symlinks that have been labeled. Please make sure you have at least GRUB 0.94 installed. Also rerun GRUB and reinstall it into the MBR to ensure the updated code is in use. You do have a LiveCD handy, right?

Code Listing 5.2: Reinstall GRUB on the MBR (GRUB users only)

# grub

grub> root (hd0,0) (Your boot partition)
grub> setup (hd0) (Where the boot record is installed; here, it is the MBR)

3.f. Final reboot

Reboot. Log in, then relabel again to ensure all files are labeled correctly (some files may have been created during shutdown and reboot)

Code Listing 6.1: Relabel

# rlpkg -a -r

Note: It is strongly suggested to subscribe to the gentoo-hardened mail list. It is generally a low traffic list, and SELinux announcements are made there.

SELinux is now installed!

C. Working with SELinux

1. SELinux Overview

1.a. SELinux Types

A type is a security attribute given to objects such as files, and network ports, etc. The type of a process is commonly referred to as its domain. The SELinux policy is primarily composed of type enforcement rules, which describe how domains are allowed to interact with objects, and how domains are allowed to interact with other domains. A type is generally suffixed with a '_t', such as sysadm_t. This is the most important attribute for a process or object, as most policy decisions are based on the source and target types.

1.b. SELinux Roles

SELinux is type enforcement, so the SELinux role is not the same as those in a role-based access control system. Permissions are not given to roles. A role describes the set of types a user can use. For example, a system administrator that is using the system for regular user tasks should be in the staff_r role. If they need to administrate the system, then a role change to sysadm_r is required. In SELinux terms, the domains that a user can be in is determined by their role. If a role is not allowed to have a certain domain, a transition to that domain will be denied, even if the type enforcement rules allow the domain transition. A role is generally suffixed with a '_r', such as system_r.

1.c. SELinux Identities

What is a SELinux Identity?

The SELinux identity is similar to a Linux username. The change of identity should be limited to very specific cases, since the role-based access control relies on the SELinux identity. Therfore, in general, a user’s SELinux identity will not change during a session. The user ID in Linux can be changed by set(e)uid, making it inappropriate for a SELinux identity. If a user is given a SELinux identity, it must match the Linux username. Each SELinux identity is allowed a set of roles.

Configure SELinux Identity Mapping

The SELinux policy has several generic SELinux identities that should be sufficient for all users. This mapping only needs to be configured on the strict policy. The identity mapping for the targeted policy need not be configured, as the default identity (user_u) is sufficient in all cases.

When a user logs in, the SELinux identity used is determined by this mapping.

SELinux Identity Roles Description
system_u system_r System (non-interactive) processes. Should not be used on users.
user_u user_r Generic unprivileged users. The default identity mapping.
staff_u staff_r, sysadm_r System administrators that also log in to do regular user activties.
sysadm_u sysadm_r System administrators that only log in to do administrative tasks. It is not suggested that this identity is used.
root staff_r, sysadm_r Special identity for root. Other users should use staff_u instead.

See the SELinux HOWTO for semanage syntax for configuring SELinux identity mappings.

1.d. SELinux Contexts

Using the above three security models together is called a SELinux context. A context takes the form identity:role:type. The SELinux context is the most important value for determining access.

Object Contexts

A typical ls -Z may have an output similar to this:

Code Listing 4.1: Example ls -Z output

drwxr-xr-x  root     root     system_u:object_r:bin_t          bin
drwxr-xr-x  root     root     system_u:object_r:boot_t         boot
drwxr-xr-x  root     root     system_u:object_r:device_t       dev
drwxr-xr-x  root     root     system_u:object_r:etc_t          etc

The first three columns are the typical linux permissions, user and group. The fourth column is the file or directory's security context. Objects are given the generic object_r role. From the other two fields of the context, it can be seen that the files are in the system identity, and have four different types, bin_t, boot_t, device_t, and etc_t.

Process Contexts

A typical ps ax -Z may have an output similar to this:

Code Listing 4.2: Example ps ax -Z output

  PID CONTEXT                                  COMMAND
    1 system_u:system_r:init_t                 [init]
    2 system_u:system_r:kernel_t               [keventd]
    3 system_u:system_r:kernel_t               [ksoftirqd_CPU0]
    4 system_u:system_r:kernel_t               [kswapd]
    5 system_u:system_r:kernel_t               [bdflush]
    6 system_u:system_r:kernel_t               [kupdated]
  706 system_u:system_r:syslogd_t              [syslog-ng]
  712 system_u:system_r:httpd_t                [apache]
  791 system_u:system_r:sshd_t                 [sshd]
  814 system_u:system_r:crond_t                [cron]
  826 system_u:system_r:getty_t                [agetty]
  827 system_u:system_r:getty_t                [agetty]
  828 system_u:system_r:getty_t                [agetty]
  829 system_u:system_r:getty_t                [agetty]
  830 system_u:system_r:getty_t                [agetty]
  831 system_u:system_r:httpd_t                [apache]
  832 system_u:system_r:httpd_t                [apache]
  833 system_u:system_r:httpd_t                [apache]
23093 system_u:system_r:sshd_t                 [sshd]
23095 user_u:user_r:user_t                     [bash]
23124 system_u:system_r:sshd_t                 [sshd]
23126 user_u:user_r:user_t                     [bash]
23198 system_u:system_r:sshd_t                 [sshd]
23204 user_u:user_r:user_t                     [bash]
23274 system_u:system_r:sshd_t                 [sshd]
23275 pebenito:staff_r:staff_t                 [bash]
23290 pebenito:staff_r:staff_t                 ps ax -Z

In this example, the typical process information is displayed, in addition to the process's context. By inspection, all of the system's kernel processes and daemons run under the system_u identity, and system_r role. The individual domains depend on the program. There are a few users logged in over ssh, using the generic user_u identity. Finally there is a user with the identity pebenito logged in with the staff_r role, running in the staff_t domain.

1.e. SELinux Policy Files

The SELinux policy source files are no longer installed onto the system. In the /usr/share/selinux/{strict,targeted} directory there are a collection of policy packages and headers for building local modules. The policy files are processed by m4, and then the policy compiler checkmodule verifies that there are no syntactic errors, and a policy module is created. Then a policy package is created with with the semodule_package program, using the policy module and the module file contexts. The policy packaged then can be loaded into a running SELinux kernel by inserting it into the module store.

*.pp

Policy packages for this policy. These must be inserted into the module store so they can be loaded into the policy. Inside the package there is a loadable policy module, and optionally a file context file.

include/

Policy headers for this policy.

1.f. Binary Policy Versions

When compiling the policy, the resultant binary policy is versioned. The first version that was merged into 2.6 was version 15. The version number is only incremented generally when new features are added that require changes to the structure of the compiled policy. For example, in 2.6.5, conditional policy extensions were added. This required the policy version to be incremented to version 16.

What Policy Version Does My Kernel Use?

The policy version of a running kernel can be determined by executing sestatus or policyvers. Current kernels can load the previous version policy for compatibility. For example a version 17 kernel can also load a version 16 policy. However, this compatibility code may be removed in the future.

Note: The policy management infrastructure (libsemanage) will automatically create and use the correct version policies. No extra steps need be taken.

Policy Versions

The following table contains the policy versions in 2.6 kernels.

Version Description Kernel Versions
12 "Old API" SELinux (deprecated).
15 "New API" SELinux merged into 2.6. 2.6.0 - 2.6.4
16 Conditional policy extensions added. 2.6.5
17 IPV6 support added. 2.6.6 - 2.6.7
18 Fine-grained netlink socket support added. 2.6.8 - 2.6.11
19 Enhanced multi-level security. 2.6.12 - 2.6.13
20 Access vector table size optimizations. 2.6.14 - 2.6.18
21 Object classes in range transitions. 2.6.19 - 2.6.24
22 Policy capabilities (features). 2.6.25
23 Per-domain permissive mode. 2.6.26 - 2.6.27
23 Explicit hierarchy (type bounds). 2.6.28 - current

1.g. Conditional Policy Extensions

The conditional policy extensions allow the enabling and disabling of policy rules at runtime, without loading a modified policy. Using policy booleans and expressions, policy rules can be conditionally applied.

Determine Boolean Values

The status of policy booleans in the current running policy can be determined two ways. The first is by using sestatus.

Code Listing 7.1: Example sestatus output

# sestatus
SELinux status:         enabled
SELinuxfs mount:        /selinux
Current mode:           enforcing
Policy version:         17
 
Policy booleans:
user_ping               inactive

The second is getsebool which is a simple tool that displays the status of policy booleans, and if a value change is pending.

Code Listing 7.2: Example getsebool command

# getsebool -a
user_ping --> active: 0 pending: 0

Changing Boolean Values

The value of a boolean can be toggled by using the togglesebool command. Multiple booleans can be specified on the command line. The new value of the boolean will be displayed.

Code Listing 7.3: Example togglesebool command

# togglesebool user_ping
user_ping: active

The value of a boolean can be set specifically by using the setsebool command.

Code Listing 7.4: Example setsebool command

# setsebool user_ping 0

To set the value of a boolean, and make it the devault value, use the -P option.

Code Listing 7.5: Change default value

# setsebool -P user_ping 1

1.h. Policy Kernel Messages

While a system is running, a program or user may attempt to do something that violates the security policy. If the system is enforcing the policy, the access will be denied, and there will be a message in the kernel log. If the system is not enforcing (permissive mode), the access will be allowed, but there will still be a kernel message.

AVC Messages

Most kernel messages from SELinux come from the access vector cache (AVC). Understanding denials is important to understand if an attack is happening, or if the program is requiring unexpected accesses. An example denial may look like this:

Code Listing 8.1: Example AVC Message

avc:  denied  { read write } for  pid=3392 exe=/bin/mount dev=03:03 ino=65554
scontext=pebenito:sysadm_r:mount_t tcontext=system_u:object_r:tmp_t tclass=file

While most AVC messages are denials, occasionally there might be an audit message for an access that was granted:

Code Listing 8.2: Example AVC Message 2

avc:  granted  { load_policy } for  pid=3385 exe=/usr/sbin/load_policy
scontext=pebenito:sysadm_r:load_policy_t tcontext=system_u:object_r:security_t tclass=security

In this case, the ability to load the policy was granted. This is a critical security event, and thus is always audited. Another event that is always audited is switching between enforcing and permissive modes.

SELinux will supress logging of denials if many are received in a short amount of time. However, This does not always imply there is an attack in progress. A program may be doing something that could cause many denials in a short time, such as doing a stat() on device nodes in /dev. To protect from filling up the system logs, SELinux has rate limiting for its messages:

Code Listing 8.3: Example AVC Message 3

AVC: 12 messages suppressed.

The policy would have to be modified to not audit these accesses if they are normal program behavior, but still need to be denied.

Other kernel messages

Code Listing 8.4: inode_doinit_with_dentry

inode_doinit_with_dentry:  context_to_sid(system_u:object_r:bar_t) returned 22 for dev=hda3 ino=517610

This means that the file on /dev/hda3 with inode number 517610 has the context system_u:object_r:bar_t, which is invalid. Objects with an invalid context are treated as if they had the system_u:object_r:unlabeled_t context.

1.i. Dissecting a Denial

Denials contain varying amounts of information, depending on the access type.

Code Listing 9.1: Example Denials

avc:  denied  { lock } for  pid=28341 exe=/sbin/agetty path=/var/log/wtmp dev=03:03 ino=475406
scontext=system_u:system_r:getty_t tcontext=system_u:object_r:var_log_t tclass=file

avc:  denied  { create } for  pid=20909 exe=/bin/ls scontext=pebenito:sysadm_r:mkinitrd_t
tcontext=pebenito:sysadm_r:mkinitrd_t tclass=unix_stream_socket

avc:  denied  { setuid } for  pid=3170 exe=/usr/bin/ntpd capability=7
scontext=system_u:system_r:ntpd_t tcontext=system_u:system_r:ntpd_t tclass=capability

The most common denial relates to access of files. For better understanding, the first denial message will be broken down:

Component Description
avc: denied SELinux has denied this access.
{ lock } The attempted access is a lock.
pid=28341 The process ID performing this access is 28341.
exec=/sbin/agetty The full path and name of the process's executable is /sbin/agetty.
path=/var/log/wtmp The path and name of the target object is /var/log/wtmp. Note: a complete path is not always available.
dev=03:03 The target object resides on device 03:03 (major:minor number). On 2.6 kernels this may resolve to a name, hda3 in this example.
ino=475406 The inode number of the target object is 475406.
scontext=system_u:system_r:getty_t The context of the program is system_u:system_r:getty_t.
tcontext=system_u:object_r:var_log_t The context of the target object is system_u:object_r:var_log_t.
tclass=file The target object is a normal file.

Not all AVC messages will have all of these fields, as shown in the other two denials. The fields vary depending on the target object's class. However, the most important fields: access type, source and target contexts, and the target object's class will always be in an AVC message.

Understanding the Denial

Denials can be very confusing since they can be triggered for several reasons. The key to understanding what is happening is to know the behavior of the program, and to correctly interpret the denial message. The target is not limited to files; it could also be related to network sockets, interprocess communications, or others.

In the above example, the agetty is denied locking of a file. The file's type is var_log_t, therefore it is implied that the target file is in /var/log. With the extra information from the path= field in the denial message, it is confirmed to be the file /var/log/wtmp. If path information was unavailable, this could be further confirmed by searching for the inode. Wtmp is a file that has information about users currently logged in, and agetty handles logins on ttys. It can be concluded that this is an expected access of agetty, for updating wtmp. However, why is this access being denied? Is there a flaw in the policy by not allowing agetty to update wtmp? It turns out that wtmp has the incorrect context. It should be system_u:object_r:wtmp_t, rather than system_u:object_r:var_log_t.

If this access was not understood, an administrator might mistakenly allow getty_t read/write access to var_log_t files, which would be incorrect, since agetty only needs to modify /var/log/wtmp. This underscores how critical keeping file contexts consistent is.

1.j. References

U.S. National Security Agency, SELinux Policy README

2. SELinux HOWTO

2.a. Load policy into a running SELinux kernel

This requires you to be in the sysadm_r role.

Code Listing 1.1: Semodule command

# semodule -B

2.b. Change roles

This requires your user have access to the target role. This example is for changing to the sysadm_r role.

Code Listing 2.1: Newrole

# newrole -r sysadm_r

2.c. Specify available roles for a user

There is a mapping of linux users to SELinux identities. The policy has generic SELinux users for relevant configurations of roles. For example, to map the user pebenito to the SELinux identity staff_u, run:

Code Listing 3.1: Map pebenito to staff_u

# semanage login -a -s staff_u pebenito

The policy does not need to be reloaded. If the user is logged in, it must log out and log in again to take effect.

2.d. Relabel filesystems

This requires you to be in the sysadm_r role.

Code Listing 4.1: Relabel

# rlpkg -a

2.e. Relabel an individual package

In addition to relabeling entire filesystems, individual portage packages can be relabeled. This requires you to be in the sysadm_r role.

Code Listing 5.1: rlpkg example

# rlpkg shadow sash

The script rlpkg is used, and any number of packages can be specified on the command line.

2.f. Scan for libraries with text relocations

SELinux has improved memory protections. One feature supported is the permission for ELF text relocations. The libraries with text relocations have a special label, and the rlpkg tool has an option to scan for these libraries.

Code Listing 6.1: TEXTREL Scan

# rlpkg -t

This will also be done by automatically after a full relabel.

2.g. Start daemons in the correct domain

Controlling daemons that have init scripts in /etc/init.d is slightly different in SELinux. The run_init command must be used to run the scripts, to ensure they are ran in the correct domain. The command can be ran normally, except the command is prefixed with run_init. This requires you to be in the sysadm_r role.

Code Listing 7.1: run_init examples

# run_init /etc/init.d/ntpd start
# run_init /etc/init.d/apache2 restart
# run_init /etc/init.d/named stop

Gentoo run_init integration

run_init has been integrated into Gentoo's init script system. With SELinux installed, services can be started and stopped as usual, but will now authenticate the user.

Code Listing 7.2: Integrated run_init example

# /etc/init.d/sshd restart
Authenticating root.
Password:
 * Stopping sshd...                       [ ok ]
 * Starting sshd...                       [ ok ]

2.h. Switch between enforcing and permissive modes

Switching between modes in SELinux is very simple. Write a 1 for enforcing, or 0 for permissive to /selinux/enforce to set the mode. The current mode can be queried by reading /selinux/enforce; 0 means permissive mode, and 1 means enforcing mode. If the kernel option "NSA SELinux Development Support" is turned off, the system will always be in enforcing mode, and cannot be switched to permissive mode.

Code Listing 8.1:

Query current mode
# cat /selinux/enforce
Switch to enforcing mode
# echo 1 > /selinux/enforce
Switch to permissive mode
# echo 0 > /selinux/enforce

A machine with development support turned on can be started in enforcing mode by adding enforcing=1 to the kernel command line, in the bootloader (GRUB, lilo, etc).

Managed policy

In addition to the above kernel options, the mode at boot can be set by the /etc/selinux/config file.

Code Listing 8.2: /etc/selinux/config

# SELINUX can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - No SELinux policy is loaded.
SELINUX=permissive

The setting in this file will be overridden by the kernel command line options described above.

2.i. Understand sestatus output

The sestatus tool can be used to determine detailed SELinux-specific status information about the system. The -v option provides extra detail about the context of processes and files. The output will be divided into four sections. Sestatus only provides complete information for a user logged in as root (or su/sudo), in the sysadm_r role.

Code Listing 9.1: Status example

SELinux status:         enabled
SELinuxfs mount:        /selinux
Current mode:           enforcing
Policy version:         18

The main status information is provided in the first section. The first line shows if SELinux kernel functions exists and are enabled. If the status is disabled, either the kernel does not have SELinux support, or the policy is not loaded. The second line shows the mount point for the SELinux filesystem. During the normal use, the filesystem should be mounted at the default location of /selinux. The third line shows the current SELinux mode, either enforcing or permissive. The fourth line shows the policy database version supported by the currently running kernel.

Code Listing 9.2: Booleans example

Policy booleans:
secure_mode             inactive
ssh_sysadm_login        inactive
user_ping               inactive

The second section displays the status of the conditional policy booleans. The left column is the name of boolean. The right column is the status of the boolean, either active, or inactive. This section will not be shown on policy version 15 kernels, as they do not support conditional policy.

Code Listing 9.3: Process context example

Process contexts:
Current context:        pebenito:sysadm_r:sysadm_t
Init context:           system_u:system_r:init_t
/sbin/agetty            system_u:system_r:getty_t
/usr/sbin/sshd          system_u:system_r:sshd_t

The third section displays the context of the current process, and of several key processes. If a process is running in the incorrect context, it will not function correctly.

Code Listing 9.4: File context example

File contexts:
Controlling term:       pebenito:object_r:sysadm_devpts_t
/sbin/init              system_u:object_r:init_exec_t
/sbin/agetty            system_u:object_r:getty_exec_t
/bin/login              system_u:object_r:login_exec_t
/sbin/rc                system_u:object_r:initrc_exec_t
/sbin/runscript.sh      system_u:object_r:initrc_exec_t
/usr/sbin/sshd          system_u:object_r:sshd_exec_t
/sbin/unix_chkpwd       system_u:object_r:chkpwd_exec_t
/etc/passwd             system_u:object_r:etc_t
/etc/shadow             system_u:object_r:shadow_t
/bin/sh                 system_u:object_r:bin_t -> system_u:object_r:shell_exec_t
/bin/bash               system_u:object_r:shell_exec_t
/bin/sash               system_u:object_r:shell_exec_t
/usr/bin/newrole        system_u:object_r:newrole_exec_t
/lib/libc.so.6          system_u:object_r:lib_t -> system_u:object_r:shlib_t
/lib/ld-linux.so.2      system_u:object_r:lib_t -> system_u:object_r:shlib_t

The fourth section displays the context of the current process's controlling terminal, and of several key files. For symbolic links, the context of the link and then the context of the link target is displayed. If a file has an incorrect context, the file may be inaccessable or have incorrect permissions for a particular process.

3. SELinux FAQ

3.a. SELinux features

Does SELinux enforce resource limits?

No, resource limits are outside the scope of an access control system. If you are looking for this type of support, GRSecurity and RSBAC are better choices.

3.b. SELinux and other hardened projects

Can I use SELinux and GRSecurity (and PaX)?

Yes, SELinux can be used with GRSecurity and/or PaX with no problems; however, it is suggested that GRACL should not be used, since it would be redundant to SELinux's access control.

Can I use SELinux and the hardened compiler (PIE-SSP)?

Yes. It is also suggested that PaX be used to take full advantage of the PIE features of the compiler.

Can I use SELinux and RSBAC?

Unknown. Please report your results if you try this combination.

3.c. SELinux and filesystems

Can I use SELinux with my primary filesystems?

SELinux can be used with ext2, ext3, JFS, and XFS. Reiserfs (Reiser3) has extended attributes, but the support was never complete, and has been broken since 2.6.14. Reiser4 is not supported.

Can I use SELinux with my ancillary filesystems?

Yes, SELinux can mount ancillary filesystems, such as vfat and iso9660 filesystems, with an important caveat. All files in each filesystem will have the same SELinux type, since the filesystems do not support extended attributes. Tmpfs is the only ancillary filesystem with complete extended attribute support, which allows it to behave like a primary filesystem.

Can I use SELinux with my network filesystems?

Yes, SELinux can mount network filesystems, such as NFS and CIFS filesystems, with an important caveat. All files in each filesystem will have the same SELinux type, since the filesystems do not support extended attributes. In the future, hopefully network filesystems will begin to support extended attributes, then they will work like a primary filesystem.

3.d. Portage error messages

I get a missing SELinux module error when using emerge:

Code Listing 4.1: Portage message

!!! SELinux module not found. Please verify that it was installed.

This indicates that the portage SELinux module is missing or damaged. Also python may have been upgraded to a new version which requires python-selinux to be recompiled. Remerge dev-python/python-selinux. If packages have been merged under this condition, they must be relabed after fixing this condition. If the packages needing to be remerged cannot be determined, a full relabel may be required.

3.e. SELinux kernel error messages

I get a register_security error message when booting:

Code Listing 5.1: Kernel message

There is already a security framework initialized, register_security failed.
Failure registering capabilities with the kernel
selinux_register_security:  Registering secondary module capability
Capability LSM initialized

This means that the Capability LSM module couldn't register as the primary module, since SELinux is the primary module. The third message means that it registers with SELinux as a secondary module. This is normal.

3.f. Setfiles error messages

When I try to relabel, it fails with invalid contexts:

Code Listing 6.1: Invalid contexts example

# make relabel
/usr/sbin/setfiles file_contexts/file_contexts `mount | awk '/(ext[23]| xfs).*rw/{print $3}'`
/usr/sbin/setfiles:  read 559 specifications
/usr/sbin/setfiles:  invalid context system_u:object_r:default_t on line number 39
/usr/sbin/setfiles:  invalid context system_u:object_r:urandom_device_t on line number 120
/usr/sbin/setfiles:  invalid context system_u:object_r:fonts_t on line number 377
/usr/sbin/setfiles:  invalid context system_u:object_r:fonts_t on line number 378
/usr/sbin/setfiles:  invalid context system_u:object_r:krb5_conf_t on line number 445
/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 478
/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 479
/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 492
/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 493
/usr/sbin/setfiles:  invalid context system_u:object_r:system_cron_spool_t on line number 494
Exiting after 10 errors.
make: *** [relabel] Error 1

First ensure that /selinux is mounted. If selinuxfs is not mounted, setfiles cannot validate any contexts, causing it to believe all contexts are invalid. If /selinux is mounted, then most likely there is new policy that has not yet been loaded; therefore, the contexts have not yet become valid.

4. SELinux Management Infrastructure

4.a. SELinux Management Infrastructure

The SElinux management infrastructure manages several aspects of SELinux policy. These management tools are based on the core library libsemanage. There are several management programs to to various tasks, including semanage and semodule. They allow you to configure aspects of the policy without requiring the policy sources.

4.b. SELinux Policy Module Management

What is a policy module?

SELinux supports a modular policy. This means several pieces of policy are brought together to form one complete policy to be loaded in the kernel. This is a similar structure as the kernel itself and kernel modules. There is a main kernel image that is loaded, and various kernel modules can be added (assuming their dependencies are met) and removed on a running system without restarting. Similarly each policy has a base module and zero or more policy modules, all used to create a policy. Modules are built by compiling a piece of policy, and creating a policy package (*.pp) with that compiled policy, and optionally file contexts.

The base module policy package (base.pp) contains the basic requirements of the policy. All modular policies must have a base module at minimum. In Gentoo we have these plus policies for all parts of the system profile. This is contained in the selinux-base-policy ebuild. The other policy ebuilds in portage have one or more policy modules.

For more information on writing a policy module, in particular for managing your local customizations to the policy, please see the policy module guide.

The SELinux module store

When a policy module is inserted or removed, modules are copied into or removed from the module store. This repository has a copy of the modules that were used to create the current policy, in addition to several auxilliary files. This repository is stored in the /etc/selinux/{strict,targeted}/modules. You should never need to directly access the contents of the module store. A libsemanage-based tool should be used instead.

Libsemanage handles the module store transactionally. This means that if a set of operations (a transaction) is performed on the store and one part fails, the entire transaction is aborted. This keeps the store in a consistent state.

Managing the module store is accomplished with the semodule command. Listing the contents of the module store is done with the -l option.

Code Listing 2.1:

# semodule -l
distcc  1.1.1

Since the base module is required in all cases, and is not versioned, it will not be shown in the list. All other modules will be listed, along with their versions.

Inserting a policy module

The module should be referenced by its file name.

Code Listing 2.2:

# semodule -i module.pp

This will insert the module into module store for the currently configured policy as specified in /etc/selinux/config. If the insert succeeds, the policy will be loaded, unless the -n option is used. To insert the module into an alternate module store, the -s option.

Code Listing 2.3:

# semodule -s targeted -i module.pp

Since this refers to an alternate module store, the policy will not be loaded.

Removing a policy module

The module is referenced by its name in the module store.

Code Listing 2.4:

# semodule -r module

This will remove the module into module store for the currently configured policy as specified in /etc/selinux/config. If the remove succeeds, the policy will be loaded, unless the -n option is used. The remove command also respects the -s option.

4.c. Configuring User Login Mappings

The current method of assigning sets of roles to a user is by setting up a mapping between linux users and SELinux identities. When a user logs in, the login program will set the SELinux identity based on the this map. If there is no explicit map, the __default__ map is used.

Managing the SELinux user login map is accomplished with the semanage tool.

Code Listing 3.1: SELinux login user map

# semanage login -l
Login Name                SELinux User

__default__               user_u
root                      root

Add a user login mapping

To map the linux user pebenito to the SELinux identity staff_u:

Code Listing 3.2:

# semanage login -a -s staff_u pebenito

For descriptions on the available SELinux identities, see the SELinux Overview.

Remove a user login mapping

To remove a login map for the linux user pebenito:

Code Listing 3.3:

# semanage login -d pebenito

Note: User login maps specified by the policy (not by the management infrastructure) cannot be removed.

4.d. Configuring Initial Boolean States

The setsebool program is now a libsemanage tool. This tool's basic function is to set the state of a Boolean. However, if the machine is restarted, the Booelans will be set using the initial state as specified in the policy. To set the Boolean state, and make that the new initial state in the policy, the -P option of setsebool is used.

Code Listing 4.1: Set Boolean default state

# setsebool -P fcron_crond 1

This will set the fcron_crond Boolean to true and also make the initial state for the Boolean true.

4.e. Configuring SELinux Identities

Generally SELinux identities need not be added to the policy, as user login mappings are sufficient. However, one reason to add them is for improved auditing, since the SELinux identity is part of the scontext of a denial message.

Managing the SELinux identities is accomplished with the semanage tool.

Code Listing 5.1: SELinux identity list

# semanage user -l
SELinux User    SELinux Roles

root            sysadm_r staff_r
staff_u         sysadm_r staff_r
sysadm_u        sysadm_r
system_u        system_r
user_u          user_r

Add a SELinux identity

In addition to specifying the roles for an identity, a prefix must also be specified. This prefix should match a role, for example staff or sysadm, and it is used for home directory entries. So if staff is used for the prefix, linux users that are mapped to this identity will have their home directory labeled staff_home_dir_t.

To add the test_u identity with the roles staff_r and sysadm_r with the prefix staff:

Code Listing 5.2:

# semanage user -a -R 'staff_r sysadm_r' -P staff test_u

Note: To use the SELinux identity, a user login map still must be added.

Remove a SELinux user identity

To remove the test_u SELinux identity:

Code Listing 5.3:

# semanage user -d test_u

Note: SELinux identities specified by the policy (not by the management infrastructure) cannot be removed.

5. Local Policy Modules

5.a. Introduction

This guide discusses how to set up a policy module for local additions of rules to the policy.

5.b. Preparation

Copy the example Makefile from the selinux-base-policy doc directory to the directory that will be used for building the policy. It is suggested that /root be used. The places that the semodule tool can read policy modules includes sysadm home directories.

Code Listing 2.1:

# zcat /usr/share/doc/selinux-base-policy-20061008/Makefile.example.gz > /root/Makefile

5.c. Write a TE file

In a policy module, most policy statements are usable in modules. There are a few extra statements that must be added for proper operation.

Code Listing 3.1: Example local.te

policy_module(local,1.0)

require {
	type sysadm_su_t, newrole_t;
}
allow sysadm_su_t newrole_t:process sigchld;

In addition to the basic allow rule, it has a couple statements required by policy modules. The first is a policy_module() macro that has the name of the module, and the module's version. It also has a require block. This block specifies all types that are required for this module to function. All types used in the module must either be declared in the module or required by this module.

5.d. Write a FC File (optional)

The file contexts file is optional and has the same syntax as as always.

Code Listing 4.1: Example local.fc

/opt/myprogs/mybin	--	system_u:object_r:bin_t

Types used in the file context file should be required or declared in the TE file.

5.e. Compile Policy Modules

Simply run make to build all modules in the directory. The module will be compiled for the current policy as specified by /etc/selinux/config.

Code Listing 5.1:

# make
Compiling strict local module
/usr/bin/checkmodule:  loading policy configuration from tmp/local.tmp
/usr/bin/checkmodule:  policy configuration loaded
/usr/bin/checkmodule:  writing binary representation (version 6) to tmp/local.mod
Creating strict local.pp policy package

To build the module for a policy other than the configured policy, use the NAME= option.

Code Listing 5.2:

# make NAME=targeted
Compiling targeted local module
/usr/bin/checkmodule:  loading policy configuration from tmp/local.tmp
/usr/bin/checkmodule:  policy configuration loaded
/usr/bin/checkmodule:  writing binary representation (version 6) to tmp/local.mod
Creating targeted local.pp policy package

5.f. Load the Modules

The modules can be loaded into the currently configured policy simply by using the load target of the Makefile.

Code Listing 6.1:

# make load

The load target also respects the NAME= option. Alternatively, the semodule command can be used to load individual modules.

Code Listing 6.2:

# semodule -i local.pp

5.g. Building Reference Policy Modules

The new Gentoo policy is based on the SELinux Reference Policy. For more information on building a complete Reference Policy module, see the Reference Policy Wiki.

6. SELinux Reference Materials

6.a. Background

6.b. Policy

6.c. Books

  • SELinux by Example: Using Security Enhanced Linux, Frank Mayer, Karl MacMillan, and David Caplan, Prentice Hall, 2006; ISBN 0131963694
  • SELinux: NSA's Open Source Security Enhanced Linux, Bill McCarty, O'Reilly Media, 2004; ISBN 0596007167

6.d. Meeting Notes

6.e. Presentations

2006 SELinux Symposium

2005 SELinux Symposium

D. Troubleshooting SELinux

1. Policy Not Loaded on Boot

1.a. Verify Available Policy

You must be in sysadm_r to perform this action.

A binary policy must be available in /etc/selinux/{strict,targeted}/policy. If it is missing, then install the policy.

Code Listing 1.1: Install policy

# semodule -n -B

1.b. Verify Init Can Load the Policy

The final check is to ensure init can load the policy. Run ldd on init, and if libselinux is not in the output, remerge sysvinit.

Code Listing 2.1:

# ldd /sbin/init
  linux-gate.so.1 =>  (0xffffe000)
  libselinux.so.1 => /lib/libselinux.so.1 (0x40025000)
  libc.so.6 => /lib/libc.so.6 (0x40035000)
  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Now reboot so init gains the correct context, and loads the policy.

2. Trouble Logging in Locally

2.a. Begin Here

You must be in sysadm_r to perform these actions.

Run sestatus -v. Click the first context that doesn't match:

Process Context
Init context system_u:system_r:init_t
/sbin/agetty system_u:system_r:getty_t
File Context
/bin/login system_u:object_r:login_exec_t
/sbin/unix_chkpwd system_u:object_r:chkpwd_exec_t
/etc/passwd system_u:object_r:etc_t
/etc/shadow system_u:object_r:shadow_t
/bin/bash system_u:object_r:shell_exec_t

2.b. Incorrect Init Context

Verify Init Label

There are several possible reasons why init may have the wrong context. First, verify that init is labeled correctly, refer to the sestatus's output for /sbin/init. If it is not system_u:object_r:init_exec_t, relabel sysvinit.

Code Listing 2.1: Fix init context

# rlpkg sysvinit

Verify Available Policy

You must be in sysadm_r to perform this action.

A binary policy must be available in /etc/selinux/{strict,targeted}/policy. If it is missing, then install the policy.

Code Listing 2.2: Install binary policy

# semodule -n -B

Verify Init Can Load the Policy

The final check is to ensure init can load the policy. Run ldd on init, and if libselinux is not in the output, remerge sysvinit.

Code Listing 2.3: Check init linking

# ldd /sbin/init
  linux-gate.so.1 =>  (0xffffe000)
  libselinux.so.1 => /lib/libselinux.so.1 (0x40025000)
  libc.so.6 => /lib/libc.so.6 (0x40035000)
  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Now reboot so init gains the correct context, and loads the policy.

2.c. Incorrect agetty Context

Verify that agetty is labeled correctly. Refer to the sestatus's output for /sbin/agetty. If it is not system_u:object_r:getty_exec_t, relabel util-linux. Then restart all gettys.

Code Listing 3.1: Fix agetty context

# rlpkg util-linux
# killall agetty (they will respawn)

All of the agettys should now be in the correct system_u:object_r:getty_exec_t context. Try logging in again.

2.d. Incorrect Login Context

The login program (/bin/login) is not labeled correctly. Relabel shadow.

Code Listing 4.1: Relabel shadow

# rlpkg shadow

/bin/login should now be system_u:object_r:login_exec_t. Try logging in again.

2.e. Incorrect PAM Context

Sshd must be able to use PAM for authenticating the user. The PAM password checking program (/sbin/unix_chkpwd) must be labeled correctly so sshd can transition to the password checking context. Relabel PAM.

Code Listing 5.1: Fix unix_chkpwd context

# rlpkg pam

The password checking program should now be system_u:object_r:chkpwd_exec_t. Try loggin in again.

2.f. Incorrect Password File Contexts

The password file (/etc/passwd), and the shadow file (/etc/shadow) must be labeled correctly, otherwise PAM will not be able to authenticate your user. Relabel the files.

Code Listing 6.1: Fix shadow context

# restorecon /etc/passwd /etc/shadow

The password and shadow files should now be system_u:object_r:etc_t and system_u:object_r:shadow_t, respectively. Try logging in again.

2.g. Incorrect Bash File Context

Bash must be labeled correctly so the user can transition into the user domain when logging in. Relabel bash.

Code Listing 7.1: Fix bash context

# rlpkg bash

Bash (/bin/bash) should now be system_u:object_r:shell_exec_t. Try logging in again.

3. Trouble Logging in Remotely

3.a. Begin Here

You must be in sysadm_r to perform these actions.

Run sestatus -v. Click the first context that doesn't match:

Process Context
Init context system_u:system_r:init_t
/usr/sbin/sshd system_u:system_r:sshd_t
File Context
/sbin/unix_chkpwd system_u:object_r:chkpwd_exec_t
/etc/passwd system_u:object_r:etc_t
/etc/shadow system_u:object_r:shadow_t
/bin/bash system_u:object_r:shell_exec_t

3.b. Incorrect Init Context

Verify Init Label

There are several possible reasons why init may have the wrong context. First, verify that init is labeled correctly, refer to the sestatus's output for /sbin/init. If it is not system_u:object_r:init_exec_t, relabel sysvinit.

Code Listing 2.1:

# rlpkg sysvinit

Verify Available Policy

You must be in sysadm_r to perform this action.

A binary policy must be available in /etc/selinux/{strict,targeted}/policy. If it is missing, then install the policy.

Code Listing 2.2: Install policy

# semodule -n -B

Verify Init Can Load the Policy

The final check is to ensure init can load the policy. Run ldd on init, and if libselinux is not in the output, remerge sysvinit.

Code Listing 2.3:

# ldd /sbin/init
  linux-gate.so.1 =>  (0xffffe000)
  libselinux.so.1 => /lib/libselinux.so.1 (0x40025000)
  libc.so.6 => /lib/libc.so.6 (0x40035000)
  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Now reboot so init gains the correct context, and loads the policy.

3.c. Incorrect sshd Context

Another possibility is sshd is not labeled correctly, meaning it is not running in the right context. Relabel openssh, then restart sshd.

Code Listing 3.1:

# rlpkg openssh
# /etc/init.d/sshd restart

3.d. Incorrect PAM Context

Sshd must be able to use PAM for authenticating the user. The PAM password checking program (/sbin/unix_chkpwd) must be labeled correctly so sshd can transition to the password checking context. Relabel PAM.

Code Listing 4.1:

# rlpkg pam

The password checking program should now be system_u:object_r:chkpwd_exec_t. Try loggin in again.

3.e. Incorrect Password File Contexts

The password file (/etc/passwd), and the shadow file (/etc/shadow) must be labeled correctly, otherwise PAM will not be able to authenticate your user. Relabel the files.

Code Listing 5.1:

# restorecon /etc/passwd /etc/shadow

The password and shadow files should now be system_u:object_r:etc_t and system_u:object_r:shadow_t, respectively. Try logging in again.

3.f. Incorrect Bash File Context

Bash must be labeled correctly so the user can transition into the user domain when logging in. Relabel bash.

Code Listing 6.1:

# rlpkg bash

Bash (/bin/bash) should now be system_u:object_r:shell_exec_t. Try logging in again.

3.g. Other sshd Issues

Valid Shell

First, make sure the user has a valid shell.

Code Listing 7.1:

# grep username /etc/passwd | cut -d: -f7
/bin/bash (or your shell of choice)

If the above command does not return anything, or the shell is wrong, set the user's shell.

Code Listing 7.2:

# usermod -s /bin/bash username

PAM enabled

PAM also must be enabled in sshd. Make sure this line in /etc/ssh/sshd_config is uncommented:

Code Listing 7.3:

UsePAM yes

SELinux currently only allows PAM and a select few programs direct access to /etc/shadow; therefore, openssh must now use PAM for password authentication (public key still works).

Print

Updated July 13, 2009

Summary: This is the Gentoo SELinux Handbook.

Chris PeBenito
Author

Donate to support our development efforts.

Support OSL
Gentoo Centric Hosting: vr.org
Tek Alchemy
SevenL.net
Global Netoptex Inc.
Bytemark
Online Kredit Index
Copyright 2001-2009 Gentoo Foundation, Inc. Questions, Comments? Contact us.