NSM 10

Gheorghe Asachi Technical University of Iasi
Faculty of Automatic Control and Computer Engineering
”Network Service Management”

- Course Notes -
Master Study Programme: Distributed Systems and WEB Technologies
Year of Study: 2022-2023
Cristian-Mihai AMARANDEI
Email: cristian-mihai.amarandei@academic.tuiasi.ro
”Network Service Management” – Course Notes
Lecture #10 – Content

●
Linux system security
– SELinux
– Pluggable Authentication Modules (PAM)
NSM Lecture 10 - Linux system security 2/42

SELinux
●
NSA definition [1]:
– NSA Security-Enhanced Linux is a set of patches to the Linux kernel and utilities to provide a
strong, flexible, mandatory access control (MAC) architecture into the major subsystems of the
kernel. It provides an enhanced mechanism to enforce the separation of information based on
confidentiality and integrity requirements, which allows threats of tampering, and bypassing of
application security mechanisms, to be addressed and enables the confinement of damage
that can be caused by malicious or flawed applications. It includes a set of sample security
policy configuration files designed to meet common, general-purpose security goals.
●
RedHat [3]:
– Security-Enhanced Linux (SELinux) is a security architecture for Linux systems that allows
administrators to have more control over who can access the system. It was originally
developed by the United States National Security Agency (NSA) as a series of patches to the
Linux kernel using Linux Security Modules (LSM).

SELinux Coloring Book [2]

●
Learn the basics of
SELinux, including type
enforcement, Multi-
Category Security (MCS)
Enforcement, and Multi-
Level Security (MLS)
Enforcement

SELinux
●
ways that you can configure SELinux to protect your system:
– targeted policy:
●
is the default option and covers a range of processes, tasks, and services
– multi-level security (MLS):
●
MLS can be very complicated and is typically only used by government organizations.
●
SELinux targeted policy:
– consists of sets of policies, defined by the application developers, that declare exactly
what actions and accesses are proper and allowed for each binary executable,
configuration file, and data file used by an application.
– Policies declare predefined labels that are placed on individual programs, files, and
network ports.

Why use SELinux? [3]

●
SELinux defines access controls for the applications, processes, and files on a system.
– It uses security policies, which are a set of rules that tell SELinux what can or can’t be accessed, to
enforce the access allowed by a policy.
●
When an application or process, known as a subject, makes a request to access an
object, like a file, SELinux checks with an access vector cache (AVC), where
permissions are cached for subjects and objects.
– If SELinux is unable to make a decision about access based on the cached permissions, it sends
the request to the security server.
– The security server checks for the security context of the app or process and the file.
– Security context is applied from the SELinux policy database.
– Permission is then granted or denied.
●
If permission is denied, an "avc: denied" message will be available in /var/log/messages.

SELinux
●
SELinux has three modes:
– Enforcing: SELinux is enforcing access control rules. Computers
generally run in this mode.
– Permissive: SELinux is active but instead of enforcing access
control rules, it records warnings of rules that have been violated.
This mode is used primarily for testing and troubleshooting.
– Disabled: SELinux is turned off entirely: no SELinux violations
are denied, nor even recorded. Discouraged!

Basic SELinux Security Concepts

●
Security Enhanced Linux (SELinux) is an additional layer of system
security.
●
The primary goal of SELinux is to protect user data from system services
that have been compromised.
●
Most Linux administrators are familiar with the standard user/group/other
permission security model - model known as Discretionary Access
Control (DAC).
●
SELinux provides an additional layer of security that is object-based and
controlled by more sophisticated rules, known as Mandatory Access
Control (MAC).

Basic SELinux Security Concepts – DAC vs

MAC
●
With DAC, files and processes have owners.
– You can have the user own a file, a group own a file, or other, which can be anyone else.
●
Users have the ability to change permissions on their own files.
– The root user has full access control with a DAC system.
●
If you have root access, then you can access any other user’s files or do whatever you want on the
system.
●
On MAC systems like SELinux, there is administratively set policy around access.
– Even if the DAC settings on your home directory are changed, an SELinux policy in place to
prevent another user or process from accessing the directory will keep the system safe.
– SELinux policies let you be specific and cover a large number of processes.
●
You can make changes with SELinux to limit access between users, files, directories, and more.


●
Web application with database connection:
– To allow remote anonymous access to a web server, firewall ports must be
opened.
– this gives malicious people an opportunity to crack the system through a security
exploit.
– If they succeed in compromising the web server process they gain its
permissions.
●
Specifically, the permissions of the apache user and the apache group.
●
That user and group has read access to the document root, /var/www/html.
●
It also has access to /tmp, and /var/tmp, and any other files and directories that are world
writable.


●
SELinux is a set of security rules that determine which process
can access which files, directories, and ports.
●
Every file, process, directory, and port has a special security label
called an SELinux context.
– A context is a name used by the SELinux policy to determine whether
a process can access a file, directory, or port.
– By default, the policy does not allow any interaction unless an explicit
rule grants access.
– If there is no allow rule, no access is allowed.


●
SELinux labels have several contexts: user, role, type, and
sensitivity.
– The targeted policy, which is the default policy enabled in Red Hat
Enterprise Linux, bases its rules on the third context: the type context.
– Type context names usually end with _t.
– Can be listed with ls -lZ


●
The type context for a web server is httpd_t.
●
The type context for files and directories normally found in
/var/www/html is httpd_sys_content_t.
●
The contexts for files and directories normally found in /tmp and
/var/tmp is tmp_t.
●
The type context for web server ports is http_port_t.


●
Apache has a type context of httpd_t.
– There is a policy rule that permits Apache access to files and
directories with the httpd_sys_content_t type context.
– By default files found in /var/www/html and other web server
directories have the httpd_sys_content_t type context.
– There is no allow rule in the policy for files normally found in
/tmp and /var/tmp, so access is not permitted.


●
The MariaDB server has a type context of mysqld_t.
●
By default, files found in /data/mysql have the mysqld_db_t type context.
●
This type context allows MariaDB access to those files but disables access
by other services, such as the Apache web service.

SELinux
●
commands that deal with files use the -Z option to display
or set SELinux contexts
– ps, ls, cp, and mkdir all use the -Z option to display or set
SELinux contexts

Changing The Current SELinux Mode

●
The SELinux subsystem provides tools to display and change modes.
– getenforce: determine the current SELinux mode
– setenforce: set SELinux to a different mode
●
you can set the SELinux mode at boot time by passing a parameter to the kernel:
– enforcing=0 boots the system into permissive mode;
– enforcing=1 sets enforcing mode.
●
Enable/disable SELinux completely using kernel parameters
– selinux=0 disables SELinux
– selinux=1 enables SELinux.

Setting The Default SELinux Mode

●
Configure SELinux persistently using the
/etc/selinux/config file

Controlling SELinux File Contexts

●
Initial SELinux Context
– On systems running SELinux, all processes and files are
labeled.
– The label represents the security relevant information, known as
the SELinux context.
– New files typically inherit their SELinux context from the parent
directory, thus ensuring that they have the proper context.

Changing the SELinux context of a file

●
Commands to change the SELinux context on files:
– semanage fcontext
– restorecon
– chcon
●
preferred method to set the SELinux context for a file:
– declare the default labeling for a file using the semanage fcontext command
– apply that context to the file using the restorecon command
– This ensures that the labeling will be as desired even after a complete
relabeling of the file system!

Changing the SELinux context of a file

●
chcon command changes SELinux contexts.
– sets the security context on the file, stored in the file system
– it does not save context changes in the SELinux context
database
– When a restorecon command runs, changes made by the
chcon command also do not survive.
– if the entire file system is relabeled, the SELinux context for files
changed using chcon are reverted

SELinux – chcon example

Defining SELinux default file context rules

●
The semanage fcontext command displays and modifies the rules
that restorecon uses to set default file contexts.
– It uses extended regular expressions to specify the path and file names.
– (/.*)? - the most common extended regular expression used
●
means “optionally, match a / followed by any number of characters”.
●
It matches the directory listed before the expression and everything in that directory
recursively.
●
Install tools to manage SELinux contexts
– policycoreutil and the policycoreutil-python package
– These contain the restorecon command and semanage command,
respectively
add a SELinux context for a new directory

SELinux booleans
●
SELinux booleans are switches that change the behavior
of the SELinux policy.
●
SELinux booleans are rules that can be enabled or
disabled.
– They can be used by security administrators to tune the policy
to make selective adjustments.

SELinux booleans
●
Commands for managing SELinux booleans:
– getsebool:
●
lists booleans and their state; un-privileged users can run it
– setsebool:
●
modifies booleans; requires superuser privileges
●
setsebool -P modifies the SELinux policy to make the modification persistent.
– semanage boolean -l reports on whether or not a boolean is
persistent, along with a short description of the boolean.
●
requires superuser privileges

SELinux logs
●
audit messages - /var/log/audit/audit.log
●
SELinux messages - /var/log/messages

Pluggable Authentication Modules (PAM)
●
PAM - is a mechanism to integrate multiple low-level authentication
schemes into a high-level application programming interface (API).
●
It allows programs that rely on authentication to be written
independently of the underlying authentication scheme.
– first proposed by Sun Microsystems in RFC 86.0 dated October 1995
– adopted as the authentication framework of the CDE (Common Desktop
Environment)
●
As a stand-alone open-source infrastructure, PAM first appeared in
Red Hat Linux 3.0.4 in 1996
●
currently supported in: AIX, BSD, HP-UX, Linux, Mac OS X, Solaris.


●
enables the separation of authentication schemes from the applications
●
provides a library of functions that applications can use for requesting user
authentications.
● PAM configuration files are located in the directory /etc/pam.d and the
modules (shared libraries) themselves are located in the directory /lib/security
– /etc/pam.d
●
contains the PAM configuration files for each PAM-aware application
●
applications that do not have a configuration file will automatically be pointed to the default
configuration file 'other'.
●
directives formatted as follows:
– <module interface> <control flag> <module name> <module arguments>
●
!!!! Always check the version of PAM installed in the system - see bibliography

●
Applications communicate with the PAM library through
the PAM application programming interface (API)
●
PAM modules communicate with the PAM library through
the PAM service provider interface (SPI)

Source: http://ldapwiki.willeke.com/attach/Pluggable%20Authentication%20Modules/pam.overview.1.png

<module interface> <control flag> <module name> <module arguments>
●
<module interface>
– Four types of PAM module interface are available
– Each of these corresponds to a different aspect of the authorization process
– account: This module interface verifies that access is allowed. For example, it checks
if a user account has expired or if a user is allowed to log in at a particular time of day.
– auth: it establishes that the user is who they claim to be, by instructing the application
to prompt the user for a password or other means of identification.
– password: used for updating the authentication token associated with the user (i.e.
password)
– session: doing things that need to be done for the user before/after they can be given
service like mounting a user's home directory and making the user's mailbox available


●
<control flag>
– All PAM modules generate a success or failure result when called. Control flags tell PAM what do
with the result
– some valid control flag values are:
●
required: The module result must be successful for authentication to continue. If the test fails at this point, the
user is not notified until the results of all module tests that reference that interface are complete.
●
requisite: The module result must be successful for authentication to continue. However, if a test fails at this
point, the user is notified immediately with a message reflecting the first failed required or requisite module test.
●
sufficient: success of such a module is enough to satisfy the authentication requirements of the stack of
modules. A failure of this module is not deemed as fatal to satisfying the application that this type has
succeeded. If the module succeeds the PAM framework returns success to the application immediately without
trying any other modules.
●
optional: only becomes necessary for successful authentication when no other modules reference the interface.

●
Control flags used by login:
– required - pam_unix.so (main authentication module)
– requisite - pam_securetty.so ( ensures that if the user is
trying to log in as root, the tty on which the user is logging in is
listed in the /etc/securetty file, if that file exists.)
– optional - pam_lastlog.so


●
<module_name>
– The module-path tells PAM which module to use and (optionally) where to find it
– Most configurations only contain the module's name
– PAM looks for the modules in the default PAM module directory, normally /usr/lib/security.
– if your linux distribution conforms to the Filesystem Hierarchy Standard (FHS), PAM
modules can be found in /lib/security
●
<module arguments>
– arguments to be passed to the module
– Each module has its own arguments
● the "nulok" ("null ok"), argument being passed to pam_unix.so module, indicating the a blank ("null")
password is acceptable


password length
●
Example:
– /etc/pam.d/system-auth
#%PAM-1.0
auth required pam_env.so
auth sufficient pam_unix.so likeauth nullok
auth required pam_deny.so
account required pam_unix.so
password required pam_cracklib.so retry=3 minlen=12
password sufficient pam_unix.so nullok use_authtok md5 shadow
password required pam_deny.so
session required pam_limits.so
session required pam_unix.so


/etc/pam.d/other
●
A paranoid configuration
Source: http://tldp.org/HOWTO/User-Authentication-HOWTO/x263.html


●
disabling console program access
– rm -f /etc/security/console.apps/<servicename>
●
<servicename> is the name of the program to which you wish to disable console
equivalent access. (halt, poweroff, reboot, shutdown, xserver)
●
Disabling all console access
# !/bin/sh
cd /etc/pam.d
for i in * ; do
sed '/[^#].*pam_console.so/s/^/#/' < $i > foo && mv foo $i
done
Source: https://www.centos.org/docs//2/rhl-cg-en-7.2/s1-access-console-all.html


Tighten console permissions for privileged users
●
/etc/security/console.perms
# file classes -- these are regular expressions # permission definitions
<console>=tty[0-9][0-9]* :[0-9]\.[0-9] :[0-9]
<console> 0660 <floppy> 0660
<xconsole>=:[0-9]\.[0-9] :[0-9]
root.floppy
# device classes -- these are shell-style globs
<floppy>=/dev/fd[0-1]* <console> 0600 <sound> 0640 root.sys
<sound>=/dev/dsp* /dev/audio* /dev/midi* \ <console> 0600 <cdrom> 0600 root.disk
/dev/mixer* /dev/sequencer
<console> 0600 <pilot> 0660 root.tty
<cdrom>=/dev/cdrom* /dev/cdwriter*
<pilot>=/dev/pilot <console> 0600 <jaz> 0660 root.disk
<jaz>=/dev/jaz <console> 0600 <zip> 0660 root.disk
<zip>=/dev/zip
<scanner>=/dev/scanner
<console> 0600 <scanner> 0600 root
<fb>=/dev/fb /dev/fb[0-9]* <console> 0600 <fb> 0600 root
<kbd>=/dev/kbd <console> 0600 <kbd> 0600 root
<joystick>=/dev/js*
<v4l>=/dev/video* /dev/radio* /dev/winradio* /dev/vtx*
<console> 0600 <joystick> 0600 root
/dev/vbi* <console> 0600 <v4l> 0600 root
<gpm>=/dev/gpmctl
<dri>=/dev/dri/* /dev/nvidia*
<console> 0700 <gpm> 0700 root
Source: http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-The-Ultimate-Solution-v2.0.pdf

Limit access to reources
●
/etc/security/limits.conf
●
Core files (core 0) – prohibit the creation of core files
●
Number of processes (nproc 35)– limited to 35
●
Memmory usage (rss 5000) – 5MB for everyone except root
●
* - cover all users - !!!! can pose problem with daemon users account like httpd

Reading assignment
●
Red Hat Enterprise Linux 7 SELinux User's and Administrator's Guide -
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/pdf/selinux_users_and_administrators_guide/
Red_Hat_Enterprise_Linux-7-SELinux_Users_and_Administrators_Guide-en-US.pdf
●
Securing & Optimizing Linux: The Ultimate Solution (v.2.0) - ftp://ftp.monash.edu.au/pub/linux/docs/LDP/solrhe/Securing-
Optimizing-Linux-The-Ultimate-Solution-v2.0.pdf
– Chapter 4 (pag. 90)
●
Securing & Optimizing Linux: Red Hat Edition (v.1.3) - http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-
v1.3.pdf
– Chapter 3
●
Red Hat Enterprise Linux 7 System-Level Authentication Guide
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/pdf/system-level_authentication_guide/
Red_Hat_Enterprise_Linux-7-System-Level_Authentication_Guide-en-US.pdf
– Chapter 10 (PAM)

References
This presentation is intended for lecturing purposes only and it is based on the references listed below. Therefore, the students are encouraged to (and they should) read
thoroughly the original documents listed below in order to improve their skills.
1. https://en.wikipedia.org/wiki/Security-Enhanced_Linux
2. Dan Walsh, SELinux Coloring Book - http://people.redhat.com/duffy/selinux/selinux-coloring-book_A4-Stapled.pdf
3. What is SELinux? https://www.redhat.com/en/topics/linux/what-is-selinux
4. http://www.opengroup.org/rfc/rfc86.0.html
5. What is PAM? https://medium.com/information-and-technology/wtf-is-pam-99a16c80ac57
6. How PAM works - http://www.tuxradar.com/content/how-pam-works
7. Understanding and configuring PAM - https://developer.ibm.com/tutorials/l-pam/
8. XSSO Sign-on Services - https://pubs.opengroup.org/onlinepubs/8329799/chap4.htm
9. Charlie Lai and Vipin Samar, Making Login Services Independent of Authentication Technologies, 1996,
http://tulip.bu.ac.th/~nattakorn.c/ldap_radius/pam.pdf
10. The Linux-PAM System Administrators' Guide - http://www.linux-pam.org/Linux-PAM-html/Linux-PAM_SAG.html
11. The Linux-PAM Module Writers' Guide - http://www.linux-pam.org/Linux-PAM-html/Linux-PAM_MWG.html
12. The Linux-PAM Application Developers' Guide - http://www.linux-pam.org/Linux-PAM-html/Linux-PAM_ADG.html
13. http://www.linux-pam.org/documentation/Linux-PAM-1.2.0-docs.tar.gz
14. Securing and Hardening Red Hat Linux Production Systems - http://www.puschitz.com/SecuringLinux.shtml
15. Peter Hernberg, User Authentication HOWTO - https://tldp.org/HOWTO/pdf/User-Authentication-HOWTO.pdf
16. Oracle Solaris Security for Developers Guide - https://docs.oracle.com/cd/E19963-01/pdf/819-2145.pdf

NSM 10

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NSM 10

Uploaded by

Copyright:

Available Formats

Gheorghe Asachi Technical University of Iasi

Faculty of Automatic Control and Computer Engineering

”Network Service Management”

Year of Study: 2022-2023

Lecture #10 – Content

NSM Lecture 10 - Linux system security 2/42

NSM Lecture 10 - Linux system security 3/42

SELinux Coloring Book [2]

NSM Lecture 10 - Linux system security 4/42

NSM Lecture 10 - Linux system security 5/42

Why use SELinux? [3]

NSM Lecture 10 - Linux system security 6/42

NSM Lecture 10 - Linux system security 7/42

Basic SELinux Security Concepts

NSM Lecture 10 - Linux system security 8/42

Basic SELinux Security Concepts – DAC vs

NSM Lecture 10 - Linux system security 9/42

Basic SELinux Security Concepts

NSM Lecture 10 - Linux system security 10/42

Basic SELinux Security Concepts

NSM Lecture 10 - Linux system security 11/42

Basic SELinux Security Concepts

NSM Lecture 10 - Linux system security 12/42

Basic SELinux Security Concepts

NSM Lecture 10 - Linux system security 13/42

Basic SELinux Security Concepts

NSM Lecture 10 - Linux system security 14/42

Basic SELinux Security Concepts

NSM Lecture 10 - Linux system security 15/42

NSM Lecture 10 - Linux system security 16/42

Changing The Current SELinux Mode

NSM Lecture 10 - Linux system security 17/42

Setting The Default SELinux Mode

NSM Lecture 10 - Linux system security 18/42

Controlling SELinux File Contexts

NSM Lecture 10 - Linux system security 19/42

Changing the SELinux context of a file

NSM Lecture 10 - Linux system security 20/42

Changing the SELinux context of a file

NSM Lecture 10 - Linux system security 21/42

SELinux – chcon example

NSM Lecture 10 - Linux system security 22/42

Defining SELinux default file context rules

add a SELinux context for a new directory

NSM Lecture 10 - Linux system security 24/42

NSM Lecture 10 - Linux system security 25/42

NSM Lecture 10 - Linux system security 26/42

NSM Lecture 10 - Linux system security 27/42

Pluggable Authentication Modules (PAM)

NSM Lecture 10 - Linux system security 28/42

Pluggable Authentication Modules (PAM)

NSM Lecture 10 - Linux system security 29/42

Pluggable Authentication Modules (PAM)

NSM Lecture 10 - Linux system security 30/42

Pluggable Authentication Modules (PAM)

Pluggable Authentication Modules (PAM)

NSM Lecture 10 - Linux system security 32/42

Pluggable Authentication Modules (PAM)

NSM Lecture 10 - Linux system security 33/42

Pluggable Authentication Modules (PAM)

NSM Lecture 10 - Linux system security 34/42

Pluggable Authentication Modules (PAM)

NSM Lecture 10 - Linux system security 35/42