Linux Security

LINUX SECURITY
Prepared by Mahdi Cherif
For the Course Security Engineering, UniFi
2019/2020.
Course lectured by Dr, Rosario Pugliese.

 Linux originally released in 1991 for personal computers, has since met ever increasing
popularity
 Today it is, also, the only OS for top 500 supercomputers
 There is a ‘feeling’ shared by the *nix advocates that it is the best in terms of security compared
to other Operating systems.

Plan
o The DAC
o Linux Vulnerabilities
o OS Hardening
o Application Security
o The MAC
o References

 The Discretionary Access Controls (DAC)
1. The DAC Model:
Users and Groups
Files and Directories permissions
The Sticky Bit
Setuid and Setgid
The Kernel Space and the User Space
2. Tools leveraging the DAC model
Sudo
Tripewire

THE DISCRETIONARY ACCESS CONTROLS (DAC)
 The standard security model for Linux
 Access privileges are based on the user identity and ownership of objects
 Access privileges are at the discretion of the owner of the data.
 Flexible (+)
 Superuser has all privileges (-)
 The model can get complex (-)

DAC (THE OWNER)
 The owner can be defined:
o Implicitly, i.e., the creator of a file or directory is its owner
o Explicitly, i.e, the owner can be reset and defined with the following commands:
1. chown
2. chmod

 Users and Groups
• Root is the superuser
• Users are part of groups
• Groups to Users relation is a many to many relation
• Each user belongs at least to a group, i.e., the primary group or main group
• Unlike Hardware devices or Processes, user accounts and groups are not
represented by files in Linux

 Frequently used commands and operations for managing users and groups
include:

PERMISSIONS FOR FILES AND DIRECTORIES
 Each file on Linux/Unix has a corresponding set of permissions which specify:
▪ Permissions of the owner over the file
(The owner is represented as u)
▪ Permissions of the owner group over the same file
(The owner group is represented as g)
▪ Permissions of ‘others’, i.e., everybody else over the file
(Others are represented as o)
 Linux/Unix has three types of elementary permissions:
• Read permission r
• Write permission w
• Execute permission x

 Attention:
• The execute (x) permission for directories is tricky and three nuances should be
considered for directories permissions in general:
1. Read (r) permission means the right to list the content of the directory, i.e., files and
sub-directories.
2. Write (w) means the right to create and delete sub-content of the directory.
3. Execute (x) converts into the right to use anything in the directory or change the
working directory of the permissions-impacted-user to the current directory.
PERMISSIONS FOR FILES AND DIRECTORIES (BIS)

THE STICKY BIT (THE DELETION PROBLEM)
 It follows from the previous overview of the DAC and permissions model that any
user, part of a group with the write (w) permission on a specific directory, can
delete any file in the said directory or recursively all of its sub-folders and sub-files.
 Linux offers the sticky bit as manner to restrict and avoid such scenarios, i.e., it is not
enough that a user belongs to a group having the (w) privilege over a directory ➔
The user must be either the owner of the file or the directory in order to delete it.
 The Sticky bit is a special permission and it can be defined through the t parameter
for the chmod command:
chmod +t <directory_name>

SETUID AND SETGID
 Additionally to the Sticky bit, setuid and setgid are two more special permissions
Pre-conditions:
 The two special permissions work only on compiled binary executable files and not
on shell scripts
 The binary should be other-executable or at least group-executable depending on
the groups-memberships of the owner of the said binary

SETUID AND SETGID (BIS)
 Setuid and setgid are used to tie every execution of the binary file respectively the
file owner or a user which is member of the own group regardless of the ‘actual’
user who executed it.
➔ This model is considered very risky especially if the owner of the
file is the superuser. This situation is not uncommon given that Linux administrators
tend to favor such special permissions typically in cases of programs requiring
execution by the superuser or a ‘powerful’ user.
❑ The setuid is configured as follows: chmod +s <binary_file>
❑ The setgid is configured as follows: chmod g+s <binary_file>

THE KERNEL SPACE AND THE USER SPACE (TER)
 The Kernel space is isolated from the user space
 The superuser is the only user authorized to load and unload modules from the
Kernel space
 The Kernel enforces the Linux DAC model
 The integrity of the Kernel space is a must ➔ The loss of this integrity following an
intrusion means that the entire OS operated machine has been hijacked

THE KERNEL SPACE AND THE USER SPACE (IV)

NUMERIC MODES
 The numeric mode is used by Unix/Linux to identify uniquely each combination of
permissions for all files and directories.
 It is equivalent to the string of letters and characters representing permissions of
every file and directory, i.e., the string composed of the mnemonics ‘r’, ‘w’ and ‘x’ as
well as the special permissions ‘t’ and ‘s’
 The user space typically uses the mnemonics strings for representation of permissions
 The Kernel space typically uses the numeric mode to represent the same permissions
 Commands such as chmod process consistently the mnemonics representation and
the numeric mode representation

NUMERIC MODES (BIS)
 The numeric mode for permissions representation is a 4 digits number constructed as
follows:
𝒅 𝟏 𝒅 𝟐 𝒅 𝟑 𝒅 𝟒
Wherein,
𝑑1: The special permissions digit
𝑑2: Owner-user permissions
𝑑3: Owner-group permissions
𝑑4: Others permissions

NUMERIC MODES (TER)
 The numeric mode digits are calculated as follows:
𝒅 𝟏 =4*sd+2*sg+sb
Such as,
sd=1 if setuid is set and 0 otherwise.
sg=1 if setgid is set and 0 otherwise.
sb=1 if the sticky bit is set and 0 otherwise.
Furthermore, for the following three digits of ‘ordinary’ permissions, a, b and c are defined as follows:
a=1 if, respectively, the owner-user, owner-group and others has read permission (r) and 0 otherwise
b=1 if, respectively, the owner-user, owner-group and others has write permission (w) and 0 otherwise
c=1 if, respectively, the owner-user, owner-group and others has execute permission (x) and 0 otherwise
Note: a, b and c are different binary membership coefficients for each of the three digits, 𝑑2, 𝑑3 and 𝑑4
𝒅 𝟐=4*a(u)+2*b(u)+c(u)
𝒅 𝟑= 4*a(g)+2*b(g)+c(g)
𝒅 𝟒= 4*a(o)+2*b(o)+c(o)

REMARKS ABOUT THE DAC
 While, mathematically, all combinations are possible:
o Does it make sense to have 𝑑2 < 𝑑3 or 𝑑3 < 𝑑4 ?
o What about the superuser ? He cannot execute a file as part of ‘others’ but he can
still gain the permissions of the owner and execute consequently the file ?
o What happens if the owner-group has ‘strong’ privileges and that they are offered
the right to execute a web server application that may be vulnerable to different
types of attacks ? What happens to the sanctity of the Kernel space ?
o Does the Administrator have to draw a map of permissions and keep it displayed for
himself to make correct daily operations ?

UID, GID, PID AND UMASK
 UID: The user identifier is a number assigned to each user on the system, used to
identify the user in the system and the resources he can access, UIDs are stored in
/etc/passwd, the UID of the root is 0. Usually the first 100 UIDs are reserved for system
use.
 GID: Group identifier, the root group has the GID set to 0. The first 100 GIDs are usually
reserved for system use.
 PID: Process identifier used by the Kernel to uniquely identify an alive process, PIDs
are typically allocated sequentially, beginning at 0 and increasing to a maximum
value then resuming allocation at the next interval start number
 UMASK: The user file-creation mode mask (umask) is used to determine the file
permission for newly created files. Its purpose is the definition of the default file
permission for new files. It is a four-digit octal number.
N.B: The digits are calculated differently than the digits of the permissions number
(Numeric mode)

SUDO (LEVERAGE OF THE DAC)
 Sudo and su as well as the special permissions setuid and setgid have been defined
in Unix/Linux as mitigation plan due to high solicitation of root permissions for various
configuration and regular operations on the OS.
 However, su results in opening a new forked root session, even when the command is
invoked from a shell of a ‘low’ permissions user, given that the superuser password is
introduced correctly at login which prompts following the su command query.
 The root password should be divulgated to everyone expected to use the su
command
➔ The very same scenario the DAC was designed to avoid

SUDO (LEVERAGE OF THE DAC BIS)
 Moreover, setuid and setgid could reveal vulnerable (as illustrated previously)
 Sudo comes as a possible answer:
1. Sudo stands for ‘superuser do’, thus, it allows delegation of superuser permissions
for a specific command
2. Unlike su it does not prompt for password introduction
3. Every command that has been configured in the /etc/sudoers will be run by users
as if executed by the root
4. Sudo allows auditing/logging, given that any command executed through sudo
will be logged as well as its executor, in opposition to the scenario where every
command requiring superuser privileges will be executed by the root

SUDO (LEVERAGE OF THE DAC TER)
 The sudo philosophy is defined by Debian as follows:
“Giving as few privileges as possible but still allowing people to
get their work done.”
 Sudo package is today part of standard releases of major distributions

 # /etc/sudoers
 #
 # This file MUST be edited with the 'visudo' command as root.
 #
 # See the man page for details on how to write a sudoers file.
 #
 Defaults env_reset
 Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

 # Host alias specification
 User_Alias MYADMINS = jdoe

 # User alias specification

 # Cmnd alias specification
 Cmnd_Alias SHUTDOWN = /sbin/reboot, /sbin/poweroff
 Cmnd_Alias PKGMGMT = /usr/bin/dpkg, /usr/bin/apt-get, /usr/bin/aptitude

 # User privilege specification
 # Users listed above (MYADMINS) can run package managers and reboot the system.
 MYADMINS ALL = PKGMGMT, SHUTDOWN

 # Allow members of group sudo to execute any command
 %sudo ALL=(ALL:ALL) ALL
 #Default rule for root.
 root ALL=(ALL) ALL

 #includedir /etc/sudoers.d
SUDO (LEVERAGE OF THE DAC IV)

TRIPWIRE (LEVERAGE OF THE DAC V)
 Tripwire is a file and directory integrity checker
 Tripwire definition by Debian: “Tripwire is a tool that aids system administrators and
users in monitoring a designated set of files for any changes. Used with system files
on a regular (e.g., daily) basis, Tripwire can notify system administrators of corrupted
or tampered files, so damage control measures can be taken in a timely manner.”

TRIPWIRE (LEVERAGE OF THE DAC VI)

LINUX VULNERABILITIES
 The recognized vulnerabilities of Unix/Linux include:
▪ Buffer overflows
▪ Race conditions
▪ Abuse of setuid root
▪ DoS
▪ Web applications (Program input vulnerabilities)
▪ Rootkit attacks
▪ Keyloggers
▪ ...

 Buffer Overflows:
1. Unix/Linux Kernel is to a large-extent C coded
2. Buffer Overflow exploits and vulnerabilities apply for low-level languages such as
Assembly and C, while the latter is not ‘low-level’, it is still directly facing and
interacting with the machine, i.e., no virtual machine or sandbox or any kind of
separation layer is positioned between the programing language and the machine,
precisely, direct access to memory is the cornerstone of the issue
3. Indeed, today many Buffer overflow vulnerabilities for C code of Unix/Linux are
known, C++ and Assembly have been prone to this vulnerability as well
4. The attacker if succeeds may get access to data stored in the machine, delete files
or directories and could even get even entire control of the OS operated machine
through a Buffer Overflow shell code which allow him to get a shell with root session

 Race condition:
 Race condition occurs when multiple threads are competing for the same data
resource in memory
 Race condition supposes some ‘slowness’ in processing the instructions in the code
 This ‘slowness’ creates an opportunity time-window for the attacker

 Abuse of setuid root:
• As presented the setuid for a root-owner binary file may allow a user to get higher
privileges, this by itself is a vulnerability
• Furthermore, the setuid if combined with other vulnerabilities such as the Buffer
overflow or the Race conditions could bring an intruder right into the Kernel space
• Standard Unix/Linux distributions have limited the use of root setuid in the Kernel to
minimum given the history of vulnerabilities related to it.

 DoS:
1. The Denial of service attack strikes all Operating systems and it has evolved to
sophisticated forms, e.g., distributed denial of service (DDoS), multi-folds DoS
involving various victims and broadcasting causing loops of ICMP requests. The
attack may exploit the ICMP and its ping facility, such ‘traditional’ DoS attacks are
cross-platforms, i.e., they cause damage regardless of the victim OS type
2. Unix/Linux has been subject mostly to DoS attacks exploiting the IP fragment in
transactions of data packets, multiple variants of this type of attack include:
• Unresolvable source IP (SYN Spoofing attack)
• Oversized IP fragments, etc.
The Linux OS will consequently face a saturation of its cache and
hence will deny service

 Web applications (Program input) vulnerability is a broad category and it includes:
1. Buffer overflow vulnerabilities, for clarity they are excluded from this section
2. SQL injections attacks are one example of this category, they are easy to launch,
thus, very ‘popular’ among intruders
3. Cross-site scripting
4. Any poorly processed input data for a web application could cause havoc and
theoretically even a shell with a root session is possible in some circumstances
The vulnerability is usually highly risky given that a web application, e.g., Apache Web
Server, processes may be running as a ‘strong’ user or even the superuser ➔ Deface of
an entire website

 Rootkit attacks:
1. Rootkit is a malicious software, i.e., a set of files that the attacker manages to install
in the victim OS after he succeeds at getting root access
2. The files are usually under the cover of ordinary Unix/Linux components such as
packages of standard commands
3. The philosophy of the Rootkit is giving false-assumption to the victim that his OS is
well-behaving and that its integrity is preserved, hence, the ls command, for
instance, may be compromised to render the same output as before the intrusion
and a tool such as Tripwire may detect no changes in the files compared to the
reference version, i.e., the victim will be bluffed
4. Some tools such the chkrootkit endeavor to identify the rootkit infection, this should
be put in doubt given that the OS-operated machine may have been hijacked at
this point
5. Additionally, various types of malicious software exist

 Keylogger malicious software:
1. Once installed, will capture and forward to the attacker anything typed in the
keyboard device
2. This means, identification of the root password or any sensitive data of the victim
such as his banking card secret digit
3. Indeed, today many Buffer overflow vulnerabilities for C code of Unix/Linux are
known, C++ and Assembly have been prone to this vulnerability as well
4. This payload has previously been delivered to victims through spam e-mails and
downloads of purportedly useful and legitimate applications or files

LINUX HARDENING
 Hardening any OS or machine may get very tedious:
1. Significant time investment during system hardening
2. Money investment for the said hardening
3. Slower IT operations on the hardened system
 Hence, as a pre-requisite for the Hardening phase two questions should be
answered:
1. What is this system meant for ? The purpose of the system will most probably
indicate how much attractive it will be for hostile entities
2. Did we secure physically the perimeter ?

LINUX HARDENING (INITIAL SETUP)
 Hardening Unix/Linux can be approached from different angles, hence, a non-
exhaustive list of steps is presented in this section:
1. Securing the Bios with a password (Although not specific to *nix)
2. For initial setup of the OS the next points should be well-thought about:
• The Source of the OS file, usually delivered in an ISO image file. The administrator or
simple owner of the machine should make sure that he is downloading or getting
the OS from a legitimate source
• Additionally, the mean of delivery of the OS, e.g., the usb storage keys have been
proved dangerous, e.g., Stuxnet worm
• The checksum of the file should be verified and has to match the one indicated in
the official distribution website, e.g., MD5, SHA256 checksums
N.B: The assumption is that the machine or the virtual machine is clean at pre-
installation

LINUX HARDENING (INITIAL SETUP BIS)
DEBIAN’S WAY
3. Partitioning the system: Any users-writable directories such as /tmp or /home should be on a separate partition, in order to
keep the / partition aside, i.e., the root partition which will receive the files of the kernel. Henceforth, a recommended
partition scheme for Unix/Linux could be the following:
• 1st partition: /
• 2nd partition: /boot
• 3rd partition: /home
• 4th partition: /tmp
• 5th partition: /usr
• 6th partition: /var
• 7th partition: /srv
• 8th partition: /opt:
• 9th partition: /var/www
• 10th partition: SWAP
The partition /var/tmp could be added, typically a user-writable partition for user-browsing related processes are stored in that
directory
The isolation of user-writable partitions from / could protect from DoS attacks aiming to saturate the / ➔ The Dos attack will not
reach the kernel space
Any partition that is expected to fluctuate in terms of size, i.e., big variations of its size, is better kept in a separate partition as to
avoid DoS
Debian stores downloaded packages in /var ➔ /var is a size-fluctuating partition

LINUX HARDENING (INITIAL SETUP TER)
DEBIAN’S WAY
Debian recommends keeping non-distribution software in /opt or /usr/local, this is
motivated by two reasons:
o The partition is size-fluctuating
o The partition could survive in case of Debian re-installation
If an smtp server is needed, the creation of two extra partitions is recommended, i.e.,
/var/mail and /var/spool/mail
Note: the 9th partition is useful in case of installation of a web server
The partitions 3 and 5 can be merged into one partition in some cases, the same stands
for the partitions 7 and 8.
4. Do not plug the internet until ready
5. Set an acceptable root password

LINUX HARDENING (SOFTWARE AND PACKAGES
SELECTION)
 The recommended philosophy for this step is ‘Installing and keeping exclusively the necessary
software and packages’. Thus, the list of software and packages should be minimal and the
administrator has to know very well all components of his ‘eco-system’. The Administrator has to ask
himself such questions:
• Having the ssh deamon activated is necessary ? The ssh server package may be deleted altogether
?
• Is the Java virtual machine required ?
• Is Perl needed ?
• Why does the OS have multiple packages for handling the graphic desktop GUIs ? ➔ Installing
multiple utilities serving the same purpose should be avoided unless in very particular cases
• Why is an SMTP server installed ? Why is a HTTP server or FTP server installed ?
• The software or packages having the biggest attack surface, i.e., facing the DMZ and the external
networks should have their existence on top of the OS very-well justified, particularly risky are the
solutions allowing any kind of remote interactions or queries, e.g., sshd, inetd (Internet Daemon), RPC
(Remote Procedure call), SMTP Daemon, X Window server which allows remote user instructions to
the Unix/Linux machine, Telnet etc. Additional packages have known vulnerabilities and hence
should them as well be part of the ‘black list’, e.g., R-Services with its different variants for using clear-
text authentication
➔ For an isolation of the Kernel space, all external-networks facing applications or packages should be
removed or jailed. Unfortunately, this security ‘policy’ is easier said than done

LINUX HARDENING (AFTER THE INSTALLATION)
 The Administrator has to keep up-to-date with relevant news and issues related to Unix/Linux security, particularly issues
related to the distribution he manages and Security issues and news in general.
 While zero-day vulnerabilities will continue to pop-up regularly such as the most security aware administrator could get
defeated, the following steps should minimize the repercussions of an intrusion:
1. Subscribe to the official mailing list of the chosen distribution, e.g., the mailing list of Debian
2. Execute a security update:
▪ The sources, i.e., mirrors that the OS will use to undertake updates are included in the file /etc/apt/sources.list
▪ The update will impact ‘ordinary’ packages as well as Kernel packages
▪ Yet, the update of the Kernel image will be restricted to packages pertaining to the same version, i.e., an update of the
Kernel packages will never cause a kernel version migration unless explicitly allowed
▪ The update system for Debian has a limit obsolete point related to the Kernel image version prior to which it will perform
no updates of the OS Kernel
N.B: The version of a Linux distribution and the version of the kernel image are two different concepts
3. Change the Bios password (again)
4. Set a password for the Boot loader, i.e., LILO or GRUB. This has to be undertaken in order to avoid that an intruder gets
access to a root-shell through a specific re-configuration of the boot loader at boot prompt. The procedure is simple
and involves changing the root password and rebooting at boot prompt.

LINUX HARDENING (AFTER THE INSTALLATION BIS)
5. Disable root prompt on the initramfs
This prompt occurs on Error, For GRUB, this prompt can be removed by adding to the
file /etc/default/grub the line:
▪ GRUB_CMDLINE_LINUX=“panic=0”
▪ Then issue the command update-grub
6. Reconfigure your kernel image such as to remove a secondary root prompt
possibility on boot
Adding the line DELAY=0 to /etc/mkinitrd/mkinitrd.conf
Then, reconfiguring the kernel image
#dpkg-reconfigure –plow kernel-image-<version_installed>

LINUX HARDENING (AFTER THE INSTALLATION TER)
7. Restrict console login access:
Enforcing a ‘login policy’, su root or sudo involving root privileges for a specific command
will not be permitted through insecure consoles, this type of restriction can be configured
with the help of the PAM (Pluggable Authentication Modules), henceforth, when the root
tries to login on the mentioned console his ‘su root’ or even sudo <command> will be
rejected. Additionally, the console will refrain from inquiring about the superuser password
altogether
This restriction can be configured:
▪ In the /etc/pam.d/login which enables the pam_securetty.so module, the PAM allows
also other configurations, to be made in the latter file, related to the login process such as
restrictions targeting specific users or specific groups or prohibition of blank passwords
▪ In /etc/securetty, the administrator refines the list of terminals to which root access is
permitted, i.e., addition and suppression of Unix/Linux terminals , thus the administrator
has the possibility to provide root access strictly for local consoles which are most often
the consoles ttyX, vc/X and ttySX wherein X is an integer representing the number of the
session/instance. Note, that the list of terminals may be found in the file /etc/inittab

LINUX HARDENING (AFTER THE INSTALLATION IV)
8. Restricting the use of the Ctrl+Alt+Del and the use of the Magic SysRq key
▪ Ctrl+Alt+Del is not permitted according to some Security policies, if such is the case then a list of users
allowed to perform the Ctrl+Alt+Del reboot signal has to be explicited in the file /etc/shutdown.allow
▪ For disabling entirely Ctrl+Alt+Del the line, in /etc/inittab, with the ctrlaltdel definition should be
commented or suppressed. Then init q should be executed
• Magic SysRq Key is a key combination which allows users connected to the system console of a Linux
kernel to perform some low-level commands. The low-level commands are performed by pressing
alt+SysRq+<command_key>, the SysRq is the Print Screen key in many keyboards
• The activation of the SysRq keyboard signal can be verified, in Debian, in the file
/proc/sys/kernel/sysrq. To read and update this file, a table of Integers-identifiers representing the
type of SysRq commands allowed exists, the integers are additive, i.e., the commands possible are
cumulative
• For the desactivation of the SysRq feature, the following statement line should be added to
/etc/sysctl.conf
#Disables the magic SysRq key
kernel.sysrq = 0

LINUX HARDENING (AFTER THE INSTALLATION V)
9. Securing the mounting of partitions
The fstab (/etc/fstab) or ‘file systems table’ file is a system configuration file on Debian. The fstab lists all available disks and disk partitions, it indicates as-well how they are to be
initialized and integrated in the global file system of the OS.
The configuration of the mounting process of partitions has many parameters that can harden the Unix/Linux OS. Nonetheless, attackers have developed many workarounds to
neutralize them. The Unix/Linux developers reacted and corrected multiple vulnerabilities and issues of the mount.
The mount is configured in the file /etc/fstab. The next lines present an illustration of a suggested best-practice mounting configuration of an example of three meaningful
partitions:
/dev/sda6 /usr ext3 defaults, ro,nodev 0 2
#defaults=rw,suid,dev,exec,auto,nouser,async
#ro=read-only, rw=read-write
#auto= automatically mounted, dev= allow devices on this partition
#suid= allow suid and sgid bits on this partition, nosuid= disallow suid and sgid
#user= permit any user to mount the filesystem ➔ Implies noexec, nosuid, nodev unless overridden
#nouser= only allow root to mount the file system
#nodev= Disallow device files on the partition
#exec=allow the execution of binaries that are on the partition (default), noexec=do not allow binaries to be executed on the filesystem
Thus, stricter mounting rules are possible, e.g., for /tmp
/dev/sda7 /tmp ext3 default, nodev, nosuid, noexec, usrquota, grpquota 0 2
/dev/sda8 /home ext3 rw, nosuid, nodev, exec, auto, nouser, async, usrquota, grp quota 0 2
/dev/hda /mnt/cdrom iso9660 ro, user, nodev, nosuid, noexec
Attention: Attackers learned how to get around the fstab restrictions, as an example, if an attacker manages to find a sub-partition of /dev/sda7 that has a file system different to
ext2 or ext3 than he will circumvent (break) the restriction rules for that partition, the sub-partition can just exist through a symbolic link in sda7 and not necessarily physically
The /tmp was set set to noexec, programs using this directory which require execution permission should be configured to use another directory, e.g., apt uses /tmp and can be
configured to use another by changing /etc/apt/apt.conf

LINUX HARDENING (AFTER THE INSTALLATION VI)
10. Applications user authentication with PAM
In a previous step, PAM (Pluggable Authentication Modules) was used to enforce a specific
login process for the superuser. PAM can also be used for all users and for applications, i.e.,
not necessarily packages related to the Kernel or the entire Debian. An application, must
have been compiled with PAM integrated. Today, most of the applications shipped with
Debian starting from version 2.2 are PAM-equipped. Similarly to step 7 (Restriction of login
access) /etc/pam.d/ should be modified in order to implement the desired policy. PAM was
designed for a services-centric architecture, thus, an OS could host multiple sub-systems
offering multiple services having different login credentials and processes
• Linking the authentication to a backend
• Linking the authentication of specific sessions to different backends
• Definition of a login process, such as a multi-steps authentication or the use of multiple
backends simultaneously, e.g., the standard Unix/Linux password file and a Berkley
database
• It is also possible to set rules for passwords acceptation and storage, the rules are defined
in /etc/pam.d/common-password and /etc/pam.d/passwd, e.g., enforcing passwords
encryption at storage, passwords minimal length or passwords complexity
• PAM can be used to define limits of resource usage for each user and other features

LINUX HARDENING (AFTER THE INSTALLATION VII)
11. Denial of remote access
Adding the following line to /etc/security/access.conf:
-:<administrative_group>:ALL EXCEPT LOCAL
12. Input and output audit with script
The script command is useful for the audit of what users run and their results, as such the
following statements if added to the files of shell-initialization in /etc/profile.d will allow the
audit of users actions
umask 077
exec script –q –a “/var/log/sessions/$USER-’date +%Y%m%d’”
13. Setting users umask in the shell initialization file, i.e., Debian default umask is 022
equivalent to:
• The creator of the file will be its owner having (rwx) permissions on it
• The owner-group will have (rx) permissions
• Others will have (rx) permissions as well
Hence, umask can be modified according to the desired security policy, c.f., umask octal
notation table.

LINUX HARDENING (AFTER THE INSTALLATION IIX)
14. Logging
Logging is an important security feature, for both real-time monitoring and post-attack
forensics: Debian offers mature log analysis tools, e.g., swatch, logcheck, log-analysis,
additionally to the out-of-the-box logging package syslog which seats configured in
modern Debian and requires 2 quick steps for its activation:
• Uncommenting the lines in /etc/syslog.conf
• Running /etc/init.d/syslogd restart
• Consequently, syslog will be launched and will adopt a default configuration
• Alerts for user-defined events may be created

LINUX HARDENING (AFTER THE INSTALLATION IX)
15. Using tcpwrappers
Tcp wrappers were developed prior to packet filters, they take position at the
application layer and allow or deny a service for a host or a domain
In Debian, two options are offered in order to make a service ‘tcp-wrapped’:
• Launch the service through tcpwrapper (tcpd)
• Recompile with libwrapper integrated
For the first option, services configured in/etc/inetd.conf such as telnet or ftp execute
/usr/sbin/tcpd first, i.e., allowed services are specified in /etc/hosts.allow and denied
ones in /etc/hosts.deny

LINUX HARDENING (AFTER THE INSTALLATION X)
16. Kernel patches
Different Linux kernel patches are available, they have different approaches but one
aim, i.e., protection of the Kernel space. The administrator of the OS will have to make a
list of patches among all possibilities such as the following:
▪ Linux Intrusion Detection patch provided in the kernel-patch-2.4-lids package. This
patch implements mandatory access control capabilities and makes it ‘easier’ to
restrict, hide and protect processes even from the root
▪ The exec-shield patch provided in the kernel-patch-exec-shield package which
provides protection against buffer stack smashing attacks, i.e., a type of buffer
overflow vulnerability
▪ NSA Linux package SELinux

LINUX HARDENING (AFTER THE INSTALLATION XI)
17. Configuration of the Kernel network features
Various configurations can be made in order to counter-measure known network
vulnerabilities for Unix/Linux:
 Turning On source address verification in all interfaces as to enable spoof protection:
/sbin/sysctl –w net.ipv4.conf.all.rp_filter=1
 If possible, ignore any ICMP echo request: /sbin/sysctl –w
net.ipv4.icmp_echo_ignore_all=1
 ICMP restriction rules can get tailored, such as ignoring ICMP redirects requests for re-
emissions:
/sbin/sysctl –w net.ipv4.conf.all.accept_redirect=0
/sbin/sysctl –w net.ipv6.conf.all.accept_redirect=0
 Logging data packets with impossible addresses: /sbin/sysctl –w
proc.sys.net.ipv4.conf.all.log_martians=1
 Other options can be checked by running /sbin/sysctl –A or reading /etc/sysctl.conf
 For the changes to be permanent, they should be saved in /etc/sysctl.conf
 The changes must be loaded to ensure the update online: /sbin/sysctl –p
N.B: The rules can be network interface-specific

LINUX HARDENING (AFTER THE INSTALLATION XII)
18. Enforce a static cache for the ARP (Address resolution protocol)
The ARP which resolves IP addresses to MAC addresses has been exploited in the past,
at LAN level, for this reason, it is considered a better practice to create a static APR
cache, static entries can be created as follows:
arp –s <host_name> <hdwr_addr>
This allows,
o Implementing efficient IP traffic filtering rules, i.e., MAC-based rules
o Detect easily suspicious ARP traffic
o No ARP spoofing aiming to send fake ARP inquiries, i.e., fake ARP entries cannot be
created
o Quicker transactions given that the resolution of addresses uses a static table

LINUX HARDENING (AFTER THE INSTALLATION XIII)
19. Setting a firewall
A firewall defines a deny policy that is a set of filtering rules of outgoing and incoming
from network transactions. Major Linux distributions package, currently, iptables
(netfilter) by default in standard releases. In general terms, a proper firewall
configuration would involve a default deny policy with explicated exceptions, i.e.:
▪ Incoming connections are allowed only to allowed local services by allowed
machines
▪ Outgoing connections are only allowed to allowed services used by your system
(DNS, POP, SMTP, etc.)
▪ The forward rule denies everything (Except the cases of network routers, gateways,
etc.)
▪ All other incoming and outgoing connections are denied
This policy should be enforced by iptables or equivalent.
Iptables is a firewall-rules engine with shell prompts which makes it quite unfriendly,
graphical tools are available for rules creation and compilation for different firewall
engines including iptables, e.g., firestarter, fwbuilder.

LINUX HARDENING (AFTER THE INSTALLATION XIV)
20. Setting an IDS (Snort)
Snort is a free open source network intrusion detection system, acquired by Cisco in 2013.
Snort is a reference IDS, the solution acts as legitimate ‘sniffer’ activated by the legitimate
administrators of the system and installed usually as part of the administrated network, Snort
can be configured and has 3 standard modes:
❑ Sniffer mode, which simply read the packets of the network and displays them for the
administrator in real-time as a continuous stream on the console (shell interface)
❑ Packet logger mode, which logs the packets to disk
❑ Network Intrusion Detection System (NIDS) mode, which performs detection and analysis
on network traffic. This is the most complex and configurable model. The configuration is
possible through a set of administrator-defined rules, the rules will allow logging
transaction verifying specific conditions on parameters of a typical network connection,
e.g., connection protocol, source address, source port, destination address, destination
port.
After installation, the basic mode, i.e., the Sniffer mode can be activated with the following
commands:
./snort –v ➔ Displays on the screen the TCP/IP packet headers OR
./snort –vd ➔ Didplays the TCP/IP packet headers and the application data in transit

LINUX HARDENING (AFTER THE INSTALLATION XV)
21. Antivirus installation ?
Linux distributions are gaining new users at a significant rate, especially for general-
purpose desktop use. Thus, Linux viruses are expected to become increasingly
common, in such circumstances regular patches wont be enough and a signature-
based protection will be necessary:
Indeed, antiviruses are now a reality for Linux major distributions, e.g., the Debian
official website is listing 9 antiviruses in the Antivirus section, including one anti-virus,
clamav, which is part of the official distribution. Like professional antiviruses of the
Windows World, Clam Antivirus has a regular update process for the database of
signatures.
Although, major distributions still claim they are safe and do not face serious threats of
malicious software, such as worms, viruses and Trojans, the installation of an anti-virus
could get part of the standard hardening process of Unix/Linux in the upcoming years.

APPLICATION SECURITY
Application security is a complex topic requiring multifold approach:
❖ The security records emphasize the need for different approaches for different
applications, e.g., the security strategy and daily monitoring of Apache web server
cannot be exactly the same as the ones adopted for a distributed file server or a simple
file conversion application ➔ An efficient security policy is application-specific policy
❖ The security strategy and daily operations of resource-intensive applications, and even
simple stand-alone applications, should be planned starting from the initial setup, c.f., the
section related to OS installation
❖ Securing the smallest applications requiring superuser privileges for one of its processes,
such as the daemon, could prove a very daunting task for the Unix/Linux administrator
➔Securing applications is a horizontal and vertical process, i.e., for different applications
and along different levels of abstraction. An application could be secured at one level or
different levels according to its risk factor, e.g., creating a separate partition dedicated for
it, defining a login process for the application, enforcing that it is using a randomized
memory buffer, defining specific rules for the network interface it uses for Network
connections, jailing the application or some of its components requiring a root access, etc.

APPLICATION SECURITY (BIS)
22. Jailing
Jailing is probably an administrator’s best option if the requirements include ssh access to remote users
or running any kind of server(s) in the OS-operated machine(s):
▪ As the name implies, the main function of this component is jailing a process and its children, the
concept has evolved, though, to a jail for a collection of processes (process containers)
▪ chroot is the reference package for Unix/Linux today, however, like many other alternative
packages, not necessarily supported by official distributions are available, additionally, tools or
packages executing chroot back-end can be installed, e.g., Coffer, cgroups, etc.
▪ It is possible to install, through different manners and forwarding workarounds, graphical desktops
for the chrooted sub-directory wherein is jailed a process and its children, xhost, Xnest, xchroot and
X11 are graphic windows systems for Unix/Linux described as offering support for chroot jails. Hence,
it is even possible to open a graphical desktop manager in the jail for users uncomfortable with the
shell, it is also technically possible, that applications are installed graphically in that jail ➔ A
simulated ‘jailed-session’ or ‘jailed-graphical-session’ is possible
▪ Theoretically, the ‘jailed’ user(s) and process(es) should have the ‘impression’ that they enjoy
superuser privileges
▪ The same configurations and hardening measures described previously, e.g., defining the DAC,
securing the partitions, etc., can be planned and operated for the jailed sub-directory which could
be perceived as a ‘jailed-session’

APPLICATION SECURITY (TER)
22. Jailing (bis 1)
✓ A directory tree where all system files needed for the target process to run are
copied, not the entire OS or Kernel ➔ This is an advantage compared to virtualization
✓ The chroot command changes the apparent root directory for the currently running
process and its children
✓ The chroot is called in order to change the base directory for the invoked command
which should consider the jailed sub-directory as the new root path on which it will
execute its command instructions, henceforth, the related process and its children will
be executed strictly in the chrootd environment and cannot reference paths outside
the new base root directory, i.e., above the level of the new base directory
according to the ‘true’ origin root directory ➔ The chrooted process and its children
cannot access the protected zones and therefore malicious access to them is
prevented.
X Unfortunately, a possible ‘break-out-of-jail’ scenarios exist too.

APPLICATION SECURITY (IV)
22. Jailing (bis 2)
Illustration: Suppose we would like to create a ‘jail’ wherein a user could perform ls and
sysctl commands with full privileges, additionally, the bash available for the user outside the
jail will be made available inside it
1) Install the chroot package if not already available
2) Create the sub-directory where to hold the jail: mkdir /home/space1
3) Position the shell in the jail: cd /home/space1
4) Create the required directories inside space1: mkdir –p bin sbin lib64/x86_64-linux-gnu
lib/x86_64-linux-gnu
5) Unlias the commands to copy into the jail if they are aliased in the OS: unlias ls
unlias sysctl
unlias bash
5) Copy the commands and the bash into the jail:
cp $(which ls) ./bin/
cp $(which /sbin/sysctl) ./sbin/
cp $(which bash) ./bin/

APPLICATION SECURITY (V)
22. Jailing (bis 3)
6) Identify the dependencies/libraries necessary for the execution of each command:
ldd $(which bash)
ldd $(which ls)
ldd $(which /sbin/sysctl)
For practical considerations, the remaining part of the illustration will be restrained to sysctl.
The output for ldd $(which /sbin/sysctl) is:
linux-vdso.so.1 (0x00007ffdb978a000)
libprocps.so.7 => /lib/x86_64-linux-gnu/libprocps.so.7 (0x00007f1277aa2000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1277a9d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f12778dc000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f127783b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1277ef8000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f1277831000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f1277809000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f12777e8000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f12776ca000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f12776a9000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f1277686000)
7) All libraries listed should be copied such as the exact path for root file system starting from / is reproduced from the newly created
base directory for the jail, i.e., starting from /home/space1, e.g.,
For, libprocps.so.7, run in the jail directory, the following command: cp /lib/x86_64-linux-gnu/libprocps.so.7 ./lib/x86_64-linux-gnu/
Now, repeat this instruction, which can be automatized through a loop, for all dependencies of all the commands that will be imported
into the jail
8) Check that the /home/space1/bin/bash/ is a perfect image of /…/bin/bash/, same verification should be undertaken for
/home/space1/bin/ls/ and /…/bin/ls/, /home/space1/sbin/sysctl and /…/sbin/sysctl
Same verification should be made for /home/space1/lib/ and /home/space1/lib64/
9) Go up in the directory path: cd ..
10) Make sure chroot is configured in your /etc/sudoers file

APPLICATION SECURITY (VI)
22. Jailing (bis 4)
11) Execute chroot for the bash command in the jail: sudo chroot space1 /bin/bash
12) Unless, some compatibility or dependency issues occur a new shell should prompt
with ‘root’ privileges. In this ‘jailed’ shell, two commands should be available, i.e., ls
and sysctl besides the shell which has two extra commands integrated in it, i.e., cd
and pwd. Hence, it is possible to discover the new session file system
This solution, can be ameliorated with extra commands imported, the import should
adopt the same approach explained in this section.
The solution is deployed at low-level and costs the OS simple user-level process in the
host OS, it has minimal cost and is appreciated for the isolation feature it offers, as such,
it is often used when multiple isolated instances of the host OS are needed, this OS
kernel-level virtualization has significantly less overhead compared to the application-
layer virtualization used by virtual machines, i.e., one OS and one Kernel are alive and
not two as it is the case for virtual machines (VM).

APPLICATION SECURITY (VII)
Applications design properties and impact on Unix/Linux security
✓ Loosely coupled applications-components, i.e., having minimal inter-dependencies
are intuitive for administrators, they can be virtualized whether at OS-level or
application-level and may even be deployed in a distributed environment.
✓ Modular applications are easier to trace, easier to control and have an attack
surface that can be better apprehended and handled through different
approaches such as jails, firewalls or DAC
✓ Strongly cohesive applications are equally appreciated, such applications can be
addressed by a uniform and feasible security policy
✓ Traceability involves finer granularity of applications components and non-intuitive
and seemingly ‘archaic’ architecture and infrastructure decisions, e.g., dedicating
a specific network interface for a specific application, creating a static caching
table for MAC-IP addresses resolution.
X Modularity, strong cohesion, loose-coupling and traceability have a price, whether
in terms of engineering or network bandwidth, time-memory Complexity, storage
cost or difficulty of usage and maintainability ➔ The decision should be balanced.

APPLICATION SECURITY (IIX)
Applications Encryption
In recent years, encryption emerged as a standard. It is possible in Unix/Lix to substitute every standard network service by its
SSL substitute:
▪ Major distributions provide an SSL infrastructure which ensures local-installation of SSL certificates in a central repository of
certificates, e.g., Debian holds the certificates provided to it and approved as part of the package ca-certificates, such
certificates can be used by any OpenSSL application which implements SSL connections, i.e., X.509 digital certificates
▪ The PKI technology has not matured in the Linux World: It is still unclear how much legitimate the certificates available in
each distribution, Linux version and how much centralized and legal are the certificates delivered, is a local certificate
credible ? How to verify the certificates and who is really issuing them for each distribution ? What is the guarantee for
quick update of the certificates repository and deletion of expired or falsified certificates and who is accountable in such
case ? Who should broadcast the updates ? For instance, Debian says that the maintainer of the package ca-certificates
is the entity which approves the certificates, can the package maintainer be considered as a certificate authority ? What
happens if a new distribution appears in the Linux World and claims it is relying on some certificate authority which is, in
fact, its own creation ?
▪ For standard internet services, FTP can be replaced by FTP-SSL, HTTPS instead of HTTP, telnet-SSL, POP-SSL, etc.
▪ Furthermore, disabling every service making plain-text data exchange has been suggested in a previous section, e.g., R-
services authentication is made through plain-text exchange or source-IP-address-based authentication and in both
cases it is vulnerable, thus, it has to be substituted, SSH uses encryption and can be the replacement.
▪ Another materialization of encryption algorithms is related to Cryptographic file systems, e.g., AdvFS, Novell storage
Services, Ext4, etc. Typically, they encrypt all data contained in the file system, including metadata, which makes them
costly.

MANDATORY ACCESS CONTROLS
▪ Oppositely to DAC where permissions are at the discretion of the owner of the data
in Mandatory access controls (MAC) the owner of data cannot define permissions
that are weaker then the permissions of the global security policy of the MAC
empowered OS, i.e., the rules of the global security policy apply in all cases
▪ This is a radical shift given that it terminates the idiom of the superuser does
everything which was prevailing for many years for Unix/Linux
▪ The superuser unlimited permissions reduced the hijacking of an entire Unix/Linux
operated machine to the intrusion in a vulnerable root executed (owned) process
or the modification of a root executed (owned) file ➔ MAC design was motivated
by this major weakness
▪ The superuser is, in MAC, the guardian of the global security policy
▪ Today, many MAC adopting solutions exist, SELinux, AppArmor, grsecurity, TOMOYO
Linux, RSBAC.

MANDATORY ACCESS CONTROLS (BIS)
▪ SELinux is reportedly the most prominent MAC solution today
But,
▪ SELinux is developed by the National security agency, USA
▪ There is a significant discussion about the issuing institution of SELINUX:
▪ Will the CISO of a Chinese corporation retain it ? Or the IT head of
Airbus ? Or the IT head of the Iranian nuclear agency ?
▪ Given the track record of NSA and the E.Snowden revelations, is the NSA credible ?
▪ Has Linus Torvalds been approached, in the past, by the same NSA for a backdoor in
Linux ?
▪ Additionally, SELinux has a reputation of a steep learning curve and difficult
configuration
▪ Hopefully, substitutes are available, e.g., AppArmor, grsecurity, TOMOYO Linux, RSBAC.

CONCLUSIONS
There is no silver bullet
Securing Unix/Linux must be planned
The multi-steps plan we presented is not exhaustive
The security plan must reviewed regularly in light of operations log, feedback of the
users and security news
Securing Unix/Linux is a continuous and cumulative process
Unix/Linux is one of the best choices, if not the best, in terms of Security when
managed correctly.

REFERENCES
Security Engineering lectures, UniFi 2019, Rosario Pugliese.
Computer Security: Principles and Practice (4th ed.) - William Stallings, Lawrie Brown - Pearson (2017).
https://www.debian.org/doc/manuals/securing-debian-howto/index.en.html#contents
https://unix.stackexchange.com/questions/16828/what-roles-do-dac-file-permissions-acl-and-mac-selinux-play-in-linux-file-s
https://en.wikipedia.org/wiki/Discretionary_access_control
https://www.digitalocean.com/community/tutorials/how-to-add-and-delete-users-on-debian-8
https://www.howtogeek.com/50787/add-a-user-to-a-group-or-second-group-on-linux/
https://www.techrepublic.com/article/dealing-with-denial-of-service-attacks-in-linux/
https://en.wikipedia.org/wiki/Ping_(networking_utility)
https://www.debian.org/releases/stable/ppc64el/release-notes/ch-upgrading.en.html
https://phoenixnap.com/kb/how-to-enable-ssh-on-debian
https://www.cyberciti.biz/faq/how-do-i-restart-sshd-daemon-on-linux-or-unix/
https://phoenixnap.com/kb/how-to-enable-ssh-on-debian
https://unix.stackexchange.com/questions/87580/partition-scheme-for-installation-of-debian
https://www.planetcobalt.net/sdb/grub_settings.shtml
https://linux.die.net/man/8/sysctl
https://www.cs.mcgill.ca/~guide/help/man.html
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/sect-security_guide-server_security-disable-source-routing
https://www.cyberciti.biz/faq/ubuntu-exec-shield-protection-nx-bit-protection-sysctl/
https://www.cyberciti.biz/faq/what-is-rhel-centos-fedora-core-execshield/
https://bbs.archlinux.org/viewtopic.php?id=169828
https://en.wikipedia.org/wiki/Address_Resolution_Protocol
https://github.com/snort3/snort3
https://snort-org-site.s3.amazonaws.com/production/document_files/files/000/000/214/original/snort_manual.pdf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIXACIED2SPMSC7GA%2F20191217%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20191217T044839Z&X-Amz-Expires=172800&X-Amz-SignedHeaders=host&X-Amz-Signature=175bd5d2df21eeebcfced506b148367d3fc30142629a64be7ca8aed2604b2eac
https://security.stackexchange.com/questions/42593/alternatives-to-selinux-and-apparmor
https://www.cyberciti.biz/tips/selinux-vs-apparmor-vs-grsecurity.html
http://tomoyo.osdn.jp/
https://www.rsbac.org/links
https://wiki.debian.org/sudo
https://www.geeksforgeeks.org/buffer-overflow-attack-with-example/
https://en.wikipedia.org/wiki/Buffer_overflow
http://www.cis.syr.edu/~wedu/Teaching/cis643/LectureNotes_New/Race_Condition.pdf
https://en.wikipedia.org/wiki/Chroot
https://www.geeksforgeeks.org/linux-virtualization-using-chroot-jail/
https://stackoverflow.com/questions/15670387/chroot-alternative
https://github.com/f-prime/Coffer
https://en.wikipedia.org/wiki/Ldd_(Unix)
https://www.debian.org/releases/stretch/amd64/apds03.html.en
https://en.wikipedia.org/wiki/List_of_cryptographic_file_systems
https://en.wikipedia.org/wiki/Disk_encryption
https://www.reddit.com/r/linux/comments/54in5s/the_nsa_has_tried_to_backdoor_linux_three_times/
https://www.theregister.co.uk/2013/09/19/linux_backdoor_intrigue/
https://en.wikipedia.org/wiki/Edward_Snowdenhttps://en.wikipedia.org/wiki/List_of_cryptographic_file_systems
https://en.wikipedia.org/wiki/Disk_encryption
www.quora.com
https://geek-university.com/linux/uid-user-identifier-gid-group-identifier/
https://en.wikipedia.org/wiki/Process_identifier
https://www.cyberciti.biz/tips/understanding-linux-unix-umask-value-usage.html
https://www.reddit.com/r/linux/comments/54in5s/the_nsa_has_tried_to_backdoor_linux_three_times/
https://www.theregister.co.uk/2013/09/19/linux_backdoor_intrigue/
https://en.wikipedia.org/wiki/Edward_Snowden

Linux Security

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Linux Security

Similar to Linux Security (20)

Recently uploaded

Recently uploaded (20)

Linux Security