[ << ] [ < ] [ Home ] [ > ] [ >> ]

3. SELinux Commands

• SELinux Information Commands
• Managing SELinux
• Using SELinux

3.a. SELinux Information Commands

Introduction

You should currently have a SELinux enabled system (but running in permissive mode, so it will not enforce its policy rules). So before we introduce you to the world of SELinux and how you can add more rules to make sure your system remains functional when you switch to enforcing mode, we first give a quick overview of the various SELinux related commands.

We start off with state commands where you can get global information on SELinux state (is it running in enforcing mode or not, versions etc.)

Getting SELinux Status

The first command we will talk about is sestatus.

# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          permissive
Policy version:                 24
Policy from config file:        strict

The output of this command shows you that SELinux is enabled and is currently in the permissive mode. It also tells you that the system is configured to run in strict mode - so no unconfined_t domain here.

The sestatus command also has an extended output if you run it with the -v option. When this is done, the command returns the contexts of important processes and files:

# sestatus -v
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        strict

Process contexts:
Current context:                staff_u: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

File contexts:
Controlling term:               staff_u:object_r:user_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:rc_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
/usr/bin/newrole                system_u:object_r:newrole_exec_t
/lib/libc.so.6                  system_u:object_r:lib_t -> system_u:object_r:lib_t
/lib/ld-linux.so.2              system_u:object_r:lib_t -> system_u:object_r:ld_so_t

Another general SELinux status command is getenforce, which allows you to quickly see if your SELinux is running in enforcing mode (SELinux policies are enforced), permissive (SELinux policies are checked and logged, but not enforced) or disabled (SELinux policy is not loaded and thus not checked).

# getenforce
Enforcing

Getting SELinux Object Information

Next on the table is the seinfo command. This command allows you to query the running policy for all objects (types, roles, attributes, users, booleans ...) defined.

Common usages are:

• checking if a specific domain is defined on your system (in case you're wondering if you need to load an additional SELinux policy module or not)
• checking which domains a particular role can be in (in case you're wondering if your regular users are allowed by SELinux policies to even be transitioned towards a specific domain)
• checking which attributes are assigned to a specific domain (or vice versa, which domains have a specific attribute set) as some SELinux policy rules work on attributes rather than domains

As an example, we query if the crontab_t domain is known, if the user_r role can use the contab_t domain and finally which domains have the cron_spool_type attribute set.

# seinfo -tcrontab_t
  crontab_t
# seinfo -ruser_r -x
  user_r
    Dominated Roles:
      user_r
    Types:
      [...]
      crontab_t
      [...]
# seinfo -acron_spool_type -x
  cron_spool_type
    user_cron_spool_t
    system_cron_spool_t

Querying SELinux Policy Rules

A command which you will often use is sesearch. This command allows you to query the current policy allow rules and is a huge help when trying to find out if something is allowed (or why something isn't allowed).

The sesearch command is most often used with a source domain (-s), target domain (-t) or both, the class for which you want to query allow rules for (file, dir, socket, process ...) and the privilege you want to query for (read, write, open, transition, execute ...).

For instance, to find out which domains can write the files that have the shadow_t domain:

# sesearch -t shadow_t -c file -p write -A
Found 8 semantic av rules:
  [...]
  allow portage_t shadow_t : file { ioctl read write ... };
  allow useradd_t shadow_t : file { ioctl read write ... };
  ...

You will notice that there are sometimes results based on attributes rather than domains:

  allow portage_t file_type : file { ioctl read write ... };

In this case, the source domain (portage_t) is allowed to write to files whose domain have the file_type attribute set. If you get the feeling of these things, you'll wonder if the above rule is not a flagrant security issue as almost all domains for files have the file_type set. Yes and no - if we take a look at which domains have file write privileges to file_type domains, you'll notice that this is only portage:

# sesearch -t file_type -c file -p write -A -d
Found 1 semantic av rules:
  allow portage_t file_type : file { ioctl read write ... };

Note that we had one command without the -d option and one with. When -d is given, the search will perform an exact search without resolving the attributes. When -d is not given, it will resolve the attribute. In the last command example, dropping -d would result in hundreds of allow rules: for each domain that has file_type set, the search tries to find rules that allow file-write access to that particular domain.

Another interesting functionality of the sesearch command is to show you the rules that are applicable depending on the state of a boolean. If you want to query on a particular boolean, use -b. If you want to see the logic that the policy uses, use -C (and yes, both can be combined).

As an example, we'll check what we allow (or deny) when the global_ssp boolean is set:

# sesearch -b global_ssp -A -C -d
Found 2 semantic av rules:
ET allow domain device_t : dir { getattr search open } ; [ global_ssp ]
ET allow domain urandom_device_t : chr_file { ioctl read getattr lock open } ; [ global_ssp ]

The prefix you see shows two letters, relating to two important definitions:

• Is the rule currently Enabled or Disabled?
• Does the boolean need to be set to True or False to enable the rule?

Getting Security Context Information

During administrative tasks, and especially when you are checking if a SELinux denial could be made, it is important to find out what the security context is for a particular resource. Luckily, Gentoo Hardened - if properly installed - has already patched some tools to allow you to get this information using your standard tools.

To get the security context of a file, use ls -Z:

~$ ls -Z /etc/make.conf
system_u:object_r:portage_conf_t /etc/make.conf

To get the security context of a process, use ps -Z:

# ps -Z $(pidof init)
LABEL                             PID TTY      STAT   TIME COMMAND
system_u:system_r:init_t            1 ?        Ss     0:00 init [3]  

To get the security context of the current user, use id -Z:

~$ id -Z
staff_u:staff_r:staff_t

3.b. Managing SELinux

Introduction

Managing SELinux objects (booleans, users, ports, contexts ...) is most often done using semanage. As this application offers the interface towards various SELinux configurations, we dedicate an entire section on it, but will also cover the commands that offer similar functionality (and are sometimes easier to remember).

Booleans

We have already covered SELinux booleans earlier in this book as well as the getsebool and setsebool commands. With semanage you can too manage the booleans and, as an added bonus, listing the booleans will also show the description of the boolean (even though there is still work to be done in this area).

# semanage boolean -l
SELinux boolean                 Description

allow_ptrace            -> off  allow_ptrace
rsync_export_all_ro     -> off  rsync_export_all_ro

You can set a boolean with both setsebool and semanage:

# semanage boolean -m --on -F user_dmesg

SELinux Users and Logins

SELinux users and logins are different from Unix accounts. SELinux logins allow you to map a Unix account to a SELinux user:

# semanage login -l
Login Name          SELinux User

__default__         user_u
root                root
swift               staff_u
system_u            system_u

The default behavior is that users are logged on as the user_u SELinux user. This SELinux user is a non-administrator user: it has no specific privileges and should be used for every account that never requires elevated privileges (so no su or sudo rights for anything).

The account you use to administer your system should be mapped to the staff_u SELinux user (or its own user with the appropriate roles). This can be accomplished as follows (example with the Unix account anna):

# semanage login -a -s staff_u anna

As mentioned, SELinux users are configured to be able to join in on one or more roles. To list the available roles, you can use semanage user -l:

# semanage user -l
SELinux User        SELinux Roles

root                staff_r sysadm_r
staff_u             staff_r sysadm_r
[...]

Managing Ports

Even network ports (like port 22 for SSH) are 'protected' by SELinux. To get an overview of which domains are assigned to which ports (or port ranges) use semanage port -l.

# semanage port -l | grep '22$'
ssh_port_t             tcp     22

3.c. Using SELinux

Introduction

Up until now we've covered getting SELinux related information as well as managing SELinux settings. However, users on a SELinux hardened system will also need to know a few things about working with SELinux, including (but not limited to) roles and role transitions.

Switching Roles

As a type enforcement access control system, SELinux allows particular roles to be within a set of domains. If you are using a role which is not allowed within a particular domain, you will not be successful in using that domain and will be denied the actions assigned to that domain.

If your standard users are all SELinux user_u users (with the only supported role being user_r) then those users will never need to switch roles (nor are they allowed to). But users that are staff_u (or other users that have multiple roles) those users should be made clear how they switch between roles. We have already covered how to map such users to the correct SELinux user (see SELinux Users and Logins).

The command that accomplishes switching roles is called newrole. It's use is pretty straight forward.

~$ newrole -r sysadm_r
Password: (Enter the users' password)

When performing a role transition, SELinux will ask the user to re-authenticate through its users' password.

[ << ] [ < ] [ Home ] [ > ] [ >> ]

The contents of this document, unless otherwise expressly stated, are licensed under the CC-BY-SA-2.5 license. The Gentoo Name and Logo Usage Guidelines apply.