SELinux: improve the security of your EC2 servers

SELinux provides tools to more finely control the activities allowed to users, processes, and daemons to limit the potential damage from vulnerabilities.

In the third and final part of our server security series, we will look at how we can enhance the security of Linux-based AWS EC2 instances with SELinux. We will learn how to set up SELinux on Amazon Linux, and we will walk through a simple example on Red Hat Enterprise Linux (RHEL).

In Linux, we can easily control access to an individual file or directory by modifying the standard file permissions. We can define if we want to allow read, or write, or even execute permissions to the file owner, to all members of a single group, or to everyone else. If the standard file permissions are insufficient, we can also define Access Control Lists (ACL) which allow us to set permissions on an even finer scale.

However, there is an obvious limitation to this type of access control: there is no good way to restrict or limit a process from accessing files and directories that it should not have access to in the first place. For example, an Apache web server should have access to /var/www/html/index.html, but not /etc/passwd.

This limitation can be addressed by using SELinux as an additional layer of access control. The main model used is called Type Enforcement where processes and file system objects are labelled based on their types. SELinux compartmentalizes processes by defining rules around the types in its policy to determine what the processes are allowed to access. SELinux policies deny everything by default unless it is explicitly allowed.

Activating SELinux

On Amazon Linux AMI release 2015.09, SELinux is disabled by default. I am not sure what the state of SELinux is on Amazon Linux but, in any case, you can enable it by performing the following steps.

$ sestatus
SELinux status:                 disabled

Install the selinux-policy, selinux-policy-targeted and policycoreutils-python packages, and ensure that SELinux is configured to be enforced.

# yum install selinux-policy selinux-policy-targeted policycoreutils-python
# egrep -v -e ^\# -e ^$ /etc/selinux/config
SELINUX=enforcing
SELINUXTYPE=targeted

After that, edit the menu.lst file and append "selinux=1 security=selinux" at the end of the kernel command:

# cd /boot/grub
# cp -prv menu.lst menu.lst.default
‘menu.lst’ -> ‘menu.lst.default’
# vim menu.lst
# diff -u menu.lst.default menu.lst
--- menu.lst.default	2015-11-15 23:43:54.874843843 +0000
+++ menu.lst	2015-11-15 23:44:19.979125318 +0000
@@ -6,6 +6,6 @@
 title Amazon Linux 2015.09 (4.1.10-17.31.amzn1.x86_64)
 root (hd0,0)
-kernel /boot/vmlinuz-4.1.10-17.31.amzn1.x86_64 root=LABEL=/ console=ttyS0
+kernel /boot/vmlinuz-4.1.10-17.31.amzn1.x86_64 root=LABEL=/ console=ttyS0 selinux=1 security=selinux
 initrd /boot/initramfs-4.1.10-17.31.amzn1.x86_64.img

Finally, create an empty .autorelabel file in the root directory to label the entire system with the SELinux context after the instance is rebooted. It will take some time, especially since this is the first time SELinux is enforced on the instance. We need to perform this step to avoid potential issues arising from mislabelled files.

# touch /.autorelabel
# sync; init 6

In the system log, you will see the following message before it is rebooted again.

*** Warning -- SELinux targeted policy relabel is required.
*** Relabeling could take a very long time, depending on file
*** system size and speed of hard drives.

Once the system reboots by itself for the second time, you will find that SELinux is enforced.

$ getenforce
Enforcing

Now we’ll walk through a simple example of how SELinux enforces its policy. We will change the default port number of the OpenSSH service and see how SELinux reacts. We will use Red Hat Enterprise Linux 7.1 to modify the SELinux policy so that we can use the new port number – although we could perform (almost) the exact same steps on Amazon Linux.

Make sure you modify your EC2 instance’s Security Group to include this "Custom TCP Rule" before proceeding further.
SELinux
On Red Hat Enterprise Linux 7.1, SELinux is enabled and enforced by default.

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.1 (Maipo)
# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28

We know that the default port number for the OpenSSH server is 22. We want to change it to port 31337. We can do so by modifying the /etc/ssh/sshd_config configuration file to include "Port 31337".

# cd /etc/ssh
# cp -prv sshd_config sshd_config.default
# vim sshd_config
# egrep -i ^.?port /etc/ssh/sshd_config
#Port 22
Port 31337

After modifying the sshd_config configuration file, we can restart the OpenSSH service.
But before we restart the service, let’s install the setroubleshoot-server RPM package for the sealert tool. I am unable to find this package on Amazon Linux, but it is available on Red Hat Enterprise Linux.

# yum -y install setroubleshoot-server

Everything that SELinux has denied will be logged in /var/log/audit/audit.log. In order to make sense of the logs, you can use the sealert to diagnose the denial messages in layman’s terms. It provides easy-to-understand explanations of the messages and suggests how we can go about addressing such denials next time.

Now we are ready to restart the OpenSSH service.

# systemctl restart sshd.service
# systemctl status sshd.service
sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
   Active: activating (auto-restart) (Result: exit-code) since Sun 2015-11-15 11:29:05 EST; 5s ago
  Process: 10871 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=255)
 Main PID: 10871 (code=exited, status=255)
Nov 15 11:29:05 ip-[redacted].ec2.internal systemd[1]: sshd.service: main process exited, code=.../a
Nov 15 11:29:05 ip-[redacted].ec2.internal systemd[1]: Unit sshd.service entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.

You will find that the OpenSSH service will not start. This is because the SELinux policy insists that the OpenSSH service should only bind the default port 22. If it finds that it uses a different port, it will not allow it. You can look at the /var/log/audit/audit.log log file to find the offending SELinux denial message.

 

# grep 31337 /var/log/audit/audit.log  | tail -1
type=AVC msg=audit(1447605071.365:127): avc:  denied  { name_bind } for  pid=10893 comm="sshd" src=31337 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket

 

Now let’s see what the sealert tool says.

 

# sealert -a /var/log/audit/audit.log
 78% done'list' object has no attribute 'split'
100% done
found 1 alerts in /var/log/audit/audit.log
--------------------------------------------------------------------------------
SELinux is preventing /usr/sbin/sshd from name_bind access on the tcp_socket port 31337.
*****  Plugin bind_ports (92.2 confidence) suggests   ************************
If you want to allow /usr/sbin/sshd to bind to network port 31337
Then you need to modify the port type.
Do
# semanage port -a -t PORT_TYPE -p tcp 31337
    where PORT_TYPE is one of the following: ssh_port_t, vnc_port_t, xserver_port_t.
[...]
Additional Information:
Source Context                system_u:system_r:sshd_t:s0-s0:c0.c1023
Target Context                system_u:object_r:unreserved_port_t:s0
Target Objects                port 31337 [ tcp_socket ]
Source                        sshd
Source Path                   /usr/sbin/sshd
Port                          31337
[...]

Working with SELinux types

The sealert tool hinted that if we wanted to bind a different port, we would have to modify the SELinux port type to include the new port number.

# semanage port -l | grep ssh
ssh_port_t                     tcp      22
# semanage port -a -t ssh_port_t -p tcp 31337
# semanage port -l | grep ssh
ssh_port_t                     tcp      31337, 22

 

Once we have modified the SELinux SSH port type, let’s restart the OpenSSH service and see if it worked this time.

 

# systemctl restart sshd.service
# systemctl status sshd.service
sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
   Active: active (running) since Sun 2015-11-15 11:36:10 EST; 6s ago
 Main PID: 10965 (sshd)
   CGroup: /system.slice/sshd.service
           └─10965 /usr/sbin/sshd -D
Nov 15 11:36:10 ip-[redacted].ec2.internal systemd[1]: Starting OpenSSH server daemon...
Nov 15 11:36:10 ip-[redacted].ec2.internal systemd[1]: Started OpenSSH server daemon.
Nov 15 11:36:10 ip-[redacted].ec2.internal sshd[10965]: Server listening on 0.0.0.0 port 31337.
Nov 15 11:36:10 ip-[redacted].ec2.internal sshd[10965]: Server listening on :: port 31337.
# netstat -napt | grep ssh | grep -i listen
tcp        0      0 0.0.0.0:31337           0.0.0.0:*               LISTEN      10965/sshd
tcp6       0      0 :::31337                :::*                    LISTEN      10965/sshd

 

Awesome! It worked! I hope this article gives you the confidence to learn and explore using SELinux on your EC2 instance.

Avatar

Written by

Eugene Teo

Eugene Teo is a director of security at a US-based technology company. He is interested in applying machine learning techniques to solve problems in the security domain.


Related Posts

Alisha Reyes
Alisha Reyes
— January 6, 2020

New on Cloud Academy: Red Hat, Agile, OWASP Labs, Amazon SageMaker Lab, Linux Command Line Lab, SQL, Git Labs, Scrum Master, Azure Architects Lab, and Much More

Happy New Year! We hope you're ready to kick your training in overdrive in 2020 because we have a ton of new content for you. Not only do we have a bunch of new courses, hands-on labs, and lab challenges on AWS, Azure, and Google Cloud, but we also have three new courses on Red Hat, th...

Read more
  • agile
  • AWS
  • Azure
  • Google Cloud Platform
  • Linux
  • OWASP
  • programming
  • red hat
  • scrum
Alisha Reyes
Alisha Reyes
— December 24, 2019

Cloud Academy’s Blog Digest: Azure Best Practices, 6 Reasons You Should Get AWS Certified, Google Cloud Certification Prep, and more

Happy Holidays from Cloud Academy We hope you have a wonderful holiday season filled with family, friends, and plenty of food. Here at Cloud Academy, we are thankful for our amazing customer like you.  Since this time of year can be stressful, we’re sharing a few of our latest article...

Read more
  • AWS
  • azure best practices
  • blog digest
  • Cloud Academy
  • Google Cloud
Avatar
Guy Hummel
— December 12, 2019

Google Cloud Platform Certification: Preparation and Prerequisites

Google Cloud Platform (GCP) has evolved from being a niche player to a serious competitor to Amazon Web Services and Microsoft Azure. In 2019, research firm Gartner placed Google in the Leaders quadrant in its Magic Quadrant for Cloud Infrastructure as a Service for the second consecuti...

Read more
  • AWS
  • Azure
  • Google Cloud Platform
Alisha Reyes
Alisha Reyes
— December 10, 2019

New Lab Challenges: Push Your Skills to the Next Level

Build hands-on experience using real accounts on AWS, Azure, Google Cloud Platform, and more Meaningful cloud skills require more than book knowledge. Hands-on experience is required to translate knowledge into real-world results. We see this time and time again in studies about how pe...

Read more
  • AWS
  • Azure
  • Google Cloud
  • hands-on
  • labs
Alisha Reyes
Alisha Reyes
— December 5, 2019

New on Cloud Academy: AWS Solution Architect Lab Challenge, Azure Hands-on Labs, Foundation Certificate in Cyber Security, and Much More

Now that Thanksgiving is over and the craziness of Black Friday has died down, it's now time for the busiest season of the year. Whether you're a last-minute shopper or you already have your shopping done, the holidays bring so much more excitement than any other time of year. Since our...

Read more
  • AWS
  • AWS solution architect
  • AZ-203
  • Azure
  • cyber security
  • FCCS
  • Foundation Certificate in Cyber Security
  • Google Cloud Platform
  • Kubernetes
Avatar
Cloud Academy Team
— December 4, 2019

Understanding Enterprise Cloud Migration

What is enterprise cloud migration? Cloud migration is about moving your data, applications, and even infrastructure from your on-premises computers or infrastructure to a virtual pool of on-demand, shared resources that offer compute, storage, and network services at scale. Why d...

Read more
  • AWS
  • Azure
  • Data Migration
Wendy Dessler
Wendy Dessler
— November 27, 2019

6 Reasons Why You Should Get an AWS Certification This Year

In the past decade, the rise of cloud computing has been undeniable. Businesses of all sizes are moving their infrastructure and applications to the cloud. This is partly because the cloud allows businesses and their employees to access important information from just about anywhere. ...

Read more
  • AWS
  • Certifications
  • certified
Avatar
Andrea Colangelo
— November 26, 2019

AWS Regions and Availability Zones: The Simplest Explanation You Will Ever Find Around

The basics of AWS Regions and Availability Zones We’re going to treat this article as a sort of AWS 101 — it’ll be a quick primer on AWS Regions and Availability Zones that will be useful for understanding the basics of how AWS infrastructure is organized. We’ll define each section,...

Read more
  • AWS
Avatar
Dzenan Dzevlan
— November 20, 2019

Application Load Balancer vs. Classic Load Balancer

What is an Elastic Load Balancer? This post covers basics of what an Elastic Load Balancer is, and two of its examples: Application Load Balancers and Classic Load Balancers. For additional information — including a comparison that explains Network Load Balancers — check out our post o...

Read more
  • ALB
  • Application Load Balancer
  • AWS
  • Elastic Load Balancer
  • ELB
Albert Qian
Albert Qian
— November 13, 2019

Advantages and Disadvantages of Microservices Architecture

What are microservices? Let's start our discussion by setting a foundation of what microservices are. Microservices are a way of breaking large software projects into loosely coupled modules, which communicate with each other through simple Application Programming Interfaces (APIs). ...

Read more
  • AWS
  • Docker
  • Kubernetes
  • Microservices
Nisar Ahmad
Nisar Ahmad
— November 12, 2019

Kubernetes Services: AWS vs. Azure vs. Google Cloud

Kubernetes is a popular open-source container orchestration platform that allows us to deploy and manage multi-container applications at scale. Businesses are rapidly adopting this revolutionary technology to modernize their applications. Cloud service providers — such as Amazon Web Ser...

Read more
  • AWS
  • Azure
  • Google Cloud
  • Kubernetes
Avatar
Stuart Scott
— October 31, 2019

AWS Internet of Things (IoT): The 3 Services You Need to Know

The Internet of Things (IoT) embeds technology into any physical thing to enable never-before-seen levels of connectivity. IoT is revolutionizing industries and creating many new market opportunities. Cloud services play an important role in enabling deployment of IoT solutions that min...

Read more
  • AWS
  • AWS IoT Events
  • AWS IoT SiteWise
  • AWS IoT Things Graph
  • IoT