1 week ago

How to Use SELinux Targeted Policy to Secure Your Hosts « Null Byte :: WonderHowTo

Hackers often rely on lazy system admins along with unpatched vulnerabilities to get access to a host. Keeping intruders off of our machines requires us to update daily, only run the services we need, along with read the code, among additional things, however we can still make mistakes. Luckily for us, we can limit the damage caused by those mistakes by running SELinux.

SELinux can be a mandatory access control (MAC) system implemented via the Linux kernel along with within extended attributes on the file system. SELinux was originally developed by the NSA with the help of the Secure Computing Corporation (right now defunct), MITRE, along with numerous research labs. SELinux was released under the GPL (GNU General Public License) in 2000.

Don’t Miss: Use Dorkbot for Automated Vulnerability Discovery

What can be Mandatory Access Control?

Mandatory access control can be a system-wide policy which determines who along with what can be allowed to have access to files, sockets, ports, etc. In contrast, a Linux system running without some form of MAC uses discretionary access control (DAC) which relies on the owner of an object to determine the permissions, groups, etc. With discretionary access control, the user has the final say. On a system running MAC, the policy in place has the final say, even over the root user.

Giving the kernel the final say over access keeps users along with processes via interacting with additional objects they shouldn’t be interacting with. SELinux policy can be configured in a very granular manner for use in a a multi-level security environment. This kind of can be time-consuming along with challenging. Luckily, for an average user, major distributions often include some default SELinux policies which come preconfigured for common use-cases.

Modern Fedora, RHEL, along with CentOS distributions all come with SELinux out of the box. Ubuntu along with Debian require the administrator to install additional packages along with configure SELinux. Most well-liked distributions include support for SELinux, so there’s genuinely not an excuse to rely solely on DAC for your hosts.

With the introduction out of the way, we can start interacting with SELinux. I will be using a Fedora system throughout This kind of article, however the commands along with interactions should remain the same no matter which distribution you have selected. However, additional distributions may have varying policies.

Getting SELinux Policy

Even though Fedora supports MLS (multi-level security), we won’t be using MLS since the idea’s outside the scope of This kind of article. We will instead be focusing on the Fedora Linux targeted policy. Even though the targeted policy isn’t as fine-grained as MLS, the idea can be still an effective security tool.

Targeted policy can be the default SELinux policy in Fedora Linux. When using targeted policy, processes which are defined inside the policy run within the confines of SELinux. Processes which are not included in This kind of policy run as they could run in a standard Linux environment.

For example, httpd can be a targeted process, along with SELinux policy applies to the idea. If an attacker were to abuse a file include, SELinux could limit the attackers access to the system via the policy implemented on the httpd service.

There are a few ways to determine your current SELinux policy. You can use the cat command in your terminal to read the SELinux config file.

cat /etc/selinux/config

ere we see which SELinux can be set to enforcing the targeted policy.

We can also use the sestatus command to check the current status of SELinux.

sestatus [-v] [-b]

The -v option can be for verbosity. The -b option shows the configuration of SELinux boolean values. We’ll cover boolean values in a little bit.

The output of This kind of command gives us a bit of information about the current SELinux status.

  • We see which SELinux can be enabled.
  • We see the mount point of the SELinux temporary file system.
  • We see This kind of file system can be used internally by SELinux.s
  • We see the root directory, which tells us where SELinux config files are located. Unlike some configuration files in SELinux, the files contained inside the root directory can be modified by the user.
  • We see which the loaded policy name tells us what SELinux policy can be currently loaded.
  • We see which the current mode tells us whether or not SELinux can be currently enforcing the loaded policy.
  • We won’t worry about the MLS status.
  • We see which the policy deny unknown status controls whether or not the kernel will handle permissions defined within the kernel, however missing via the targeted policy.
  • We see which the max kernel policy variation can be the default set by the operating system.

Another command which can be used to check the status of SELinux can be the getenforce command. This kind of command can be used in shell scripts to determine if SELinux can be currently enforcing its policy.

Understanding How SELinux Works

SELinux can be a complicated tool, however we can still address a bit of the basics here. SELinux works by labeling processes along with files with an SELinux context. inside the case of files along with directories, these labels are stored as extended attributes on the file system. When a user creates a file or directory, which file or directory can be created within the context of the directory the idea was created in.

For example, if I create a webpage in my home directory, the idea inherits the labeling via which directory. If I move which page to the /var/www/html folder, the idea retains the inherited labeling. This kind of can lead to problems where Apache can be unable to read the file, where the idea could need to be re-labeled inside the httpd context. Even though This kind of creates a little bit of work on the system administrators end, the idea adds security.

right now which we know a little about labels, let’s have a look at one along with see some type enforcement at work!

In This kind of example, I’ve executed ls -Z on /etc/resolv.conf. The -Z argument can be the context argument along with can be used with many different command line utilities. Let’s break This kind of information down.

system_object:object_r:net_conf_t:s0 resolv.conf

This kind of output can be interpreted as user:role:type:level, with level being optional. For our purposes, we’re only concerned with the type field. The rest of these fields, of course, can be configured, however the idea starts to get complex quickly.

via the ls -Z command, we see which resolv.conf can be net_conf_t, or net conf type. Processes labeled as net type can interact with This kind of file, however they will not interact with files which are not within their type. So what happens if I create a completely new resolv.conf file in my home directory along with then move the idea to replace the existing resolv.conf?

The first thing to notice here can be which This kind of file can be user_home_t, which means which objects of the net type will be restricted via accessing the idea. When I replace the existing /etc/resolv.conf with my completely new file, we run into some problems.

This kind of alert pops up almost immediately warning me which there are some problems on my system. These alerts are part of the setroubleshoot package. If you are running a server, you will want the setroubleshoot-server package, which will parse SELinux error messages in /var/log/audit/audit.log into a human-readable format. The difference can be genuinely night along with day.

The default output for the audit.log can be pretty gross.

Don’t Miss: Perform a Large-Scale Network Security Audit with OpenVAS’s GSA

So much better!

One thing to note can be which the resolution of the problem can be at the top of the message! This kind of can be genuinely helpful.

This kind of particular message can be suggesting which we fix our resolv.conf issue by creating a custom policy for cupsd. Of course, if we read through the idea, we can see which there can be a label issue with resolv.conf. the idea’s important to always read the full message. inside the case of our resolv.conf issue, we don’t actually have to modify anything. This kind of issue can be resolved simply by removing resolv.conf along with restarting networking. The network manager will make a completely new resolv.conf inside the /etc directory.

Readers who have been following closely are probably asking themselves if the type can be inherited via the directory where the file can be created, wouldn’t the newly created /etc/resolv.conf file be labeled as etc_t? The answer can be yes, if the process creating the type wasn’t part of the targeted policy. In order to address This kind of issue, SELinux includes something called a transition.

File transitions are defined by SELinux policy, in This kind of case, the targeted policy. If I were to create a file inside the /etc directory as the root user, the idea could inherit the etc_t label. In order to get around This kind of, SELinux allows you to create transitions. Transitions can be configured to allow services like the network manager to create a resolv.conf file inside the /etc directory without inheriting the labeling of the /etc directory.

SELinux Boolean Values

Beyond the labeling system, SELinux targeted policy contains hundreds of boolean (true/false) values which configure some of the behavior of SELinux. In order to view all of the boolean values on your system, use the getsebool command.

getsebool -a

I went ahead along with piped the command output into nl just to give an idea of the number of boolean values which can be modified. In targeted policy, these boolean values come preconfigured to work with most configurations. If you’re having an issue with SELinux, This kind of can be one of the places to check. If you’re unsure of what a boolean does, you can get a list with the command semanage boolean -l. SELinux booleans can be managed with the setsebool command.

setsebool smbd_anon_write 1

This kind of command could set smbd_anon_write to true, which could allow SMB to write files in directories labeled public content. This kind of change can be not persistent, which means which the idea’s a great way to troubleshoot. In order to make the change permanent, you will need to add the -P argument.

setsebool -P smbd_anon_write 1

This kind of command could develop the same effect, except the idea could enable the change permanently.

Troubleshooting Your First Problem

The SELinux targeted policy can be a collection of reasonable defaults, along with the idea’s improving all the time. however what happens when you want to deviate via which policy? Things will break. You will experience unexpected behavior along with need to troubleshoot the problem.

Troubleshooting isn’t which bad for most issues, however SELinux carries a bad rap. I’ve seen tutorials for services which start out with “1. Disable SELinux.” which’s just lazy. the idea’s especially bad since by disabling SELinux, you’ll be disabling security across the entire operating system just so you can run one service or process. the idea’s much better to figure out what the problem can be along with resolve the idea.

In our first example, I’m going to create a Perl script along with place the idea inside the /var/www/cgi-bin directory. I create my script, change the permissions, along with enable CGI in Apache. I then move my script over to the cgi-bin directory.

which’s not not bad! My cutting edge “hello world” script isn’t executing! When I check the Apache error log, there’s no information. Next, I have a look in /var/messages, since I’ve installed the setroubleshoot packages.

Alright, right now we’re getting somewhere! At the top of the log entry, I’m given the command to run for a complete error message. These IDs for sealert are system specific, so running This kind of command on your system will not produce a message.

sealert -l 81dd8f63-f56a-4666-9348-3bd1ef4ea534

The -l argument tells sealert to look up alerts by listing number. When I execute This kind of command, I get a nice clean human-readable alert.

At the top of This kind of alert, I see the source context, which can be httpd type, along with the target context, which can be user_home type. There can be also information for configuring a policy module to allow This kind of type of access.

I don’t genuinely want to enact a policy which allows Apache to read user files. The issue can be obviously due to labeling. Labeling issues are the most common issues you will encounter with SELinux.

There are a few ways to modify a file’s label. We could look for a known not bad file inside the directory along with change the labeling to match. I do have a properly labeled copy of hello.cgi in my /var/www/cgi-bin directory.

ls -Z

We can see which hello2.cgi can be labeled user_home_t, along with hello.cgi can be labeled httpd_sys_script_exec_t. We can change the labeling along with context in a few ways.

The long typing intensive way:

chcon -u unconfied_u -r object_r -t httpd_sys_script_exec_t /var/www/cgi-bin/hello2.cgi

This kind of will use the chcon (change context) command to relabel our broken CGI to the proper label, however which’s pretty typing intensive.

The short way:

chcon —reference /var/www/cgi-bin/hello.cgi /var/www/cgi-bin/hello2.cgi

This kind of will use the properly labeled hello.cgi script as a reference for the context to set hello2.cgi to. This kind of can be a lot faster than typing everything out. however what if we don’t know how the idea’s supposed to be labeled? What do we do when there’s no reference? We use the restorecon command.

restorecon -vR /var/www/cgi-bin/

This kind of will restore the proper directory context to all contents of the directory. The -v argument tells restorecon to be verbose, along with the R argument can be for recursive.

Great, so we should be back in business. I fire up my browser along with access the page, only to get an error again. Since I know my labels are correct along with SELinux isn’t throwing any errors into /var/log/messages, the idea’s time to check if there are any boolean values blocking access. We can do This kind of with the getsebool command.

getsebool -a | grep httpd

Well, the idea looks like our problem might be related to the boolean httpd_enable_cgi, which can be currently set to off. We’ll use the setsebool command to set the idea to on.

setsebool -P httpd_enable_cgi 1

Looks like we sorted out our first problem. This kind of wasn’t a very complex example, however these types of issues are what you can expect to crop up when using SELinux. In This kind of case, we knew enough about SELinux to determine the cause of the issue without generating any policy alterations. If we can’t figure out what’s wrong, the idea’s wise to review the suggestion which SELinux makes about modifying policy make sure we understand the effects along with follow the commands given by SEAlert to create a custom policy.

This kind of type of troubleshooting works with smaller problems, however the idea could get frustrating very quickly if there can be more than one issue. In which case, we might want to set SELinux to permissive mode for a bit.

Managing SELinux Modes

If we anticipate which a particular piece of software will cause problems in SELinux, we can change the SELinux mode to permissive. In permissive mode, SELinux doesn’t enforce its policy, instead, the idea logs violations. Once we’ve worked with our completely new configuration for a bit, collected the list of violations, along with fixed them, we should be able to set SELinux back to enforcing along with the configuration should work. To make these alterations, we use the setenforce command.

setenforce [1|0]

The 1 argument sets SELinux to enforcing, along with the 0 argument sets SELinux to permissive.

Disabling & Enabling SELinux

SELinux can be disabled along with enabled via its configuration file /etc/selinux/config.

If you choose to disable SELinux for some reason, you will need to take some extra steps before reenabling the idea. Switching SELinux directly back into enforcing mode can cause issues with your system. Create a file with touch in / to tell SELinux to relabel the system.

touch /.autorelabel

Next, set SELinux to permissive, along with reboot your machine. SELinux will relabel the file system. The last step can be to work with the machine for a little bit, then check your log files for errors. You will need to fix these errors before moving SELinux to enforcing mode.

SELinux can be a powerful security tool, along with when feasible, should be run on all public facing hosts. This kind of article barely scratches the surface of what you can do with SELinux. For more information, you can always consult the man pages on your system. You can also check the blog of Dan Walsh (the writer of the man pages) for current events.

As always, feel free to comment! If you’ve got something you’d like to talk about, you can find me on Twitter @0xBarrow.

Don’t Miss: Use Remote Port Forwarding to Slip Past Firewall Restrictions Unnoticed

Cover image along with screenshots by Barrow/Null Byte

Leave a Comment

Your email address will not be published. Required fields are marked *

6 + 14 =