System Security II (141341) - Ruhr

Transcription

Ruhr-Universität
Bochum
http://www.rub.de
Chair for
System Security
http://www.trust.rub.de
Practical Assignments for the Course
System Security II (141341)
Prof. Dr.-Ing. Ahmad-Reza Sadeghi
Last updated: December 22, 2010
Authors
B. Cubaleska, A. Filyanov, T. Hommel, C. Kowalski, M. Steegmanns
Contact: [email protected]
Place: Lab for Operating System Security and Trusted Computing
Building ID, 2/167
Course webpage: http://www.ei.rub.de/studium/lehrveranstaltungen/265/
c
2010-2011
Ruhr Universität Bochum
Contents
1. Exercise: Logging and Auditing
1.1. Introduction . . . . . . . . . .
1.1.1. Log Analysis . . . . .
1.1.2. Logging Infrastructure
1.1.3. Linux auditing . . . .
1.1.4. Regular Expressions .
1.2. Theoretical Assignments . . .
1.3. Practical Assignments . . . .
1.3.1. Linux . . . . . . . . .
1.3.2. Windows . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
13
14
14
15
16
17
19
19
19
2. Exercise: Discretionary Access Control
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1. Basics: Users and Groups . . . . . . . . . . . .
2.1.2. Access Control Concepts in Unix-Like Systems
2.1.3. Access Control on Windows Vista . . . . . . .
2.2. Theoretical Assignments (Homework) . . . . . . . . .
2.2.1. Access Control on Unix-Like Systems . . . . .
2.2.2. Access Control on Windows . . . . . . . . . . .
2.2.3. General Questions . . . . . . . . . . . . . . . .
2.3. Practical Exercise on Unix . . . . . . . . . . . . . . . .
2.3.1. Standard Unix Permissions . . . . . . . . . . .
2.3.2. ACLs in Unix . . . . . . . . . . . . . . . . . . .
2.4. Practical Exercise on Windows Vista (8 Points) . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
23
23
27
29
29
30
31
33
33
34
35
3. Exercise: Mandatory Access Control
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . .
3.1.1. OpenSolaris . . . . . . . . . . . . . . . . . . .
3.1.2. The Zettabyte File System (ZFS) . . . . . . .
3.1.3. Discretionary Access Control in OpenSolaris
3.1.4. Trusted Extensions for OpenSolaris . . . . . .
3.2. Theoretical Assignments . . . . . . . . . . . . . . . .
3.3. Practical Assignments . . . . . . . . . . . . . . . . .
3.3.2. Preparing OpenSolaris Trusted Extensions . .
3.3.3. Configuring OpenSolaris Trusted Extensions
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
39
39
40
42
46
47
47
47
47
.
.
.
.
.
.
.
.
.
.
3
Exercises System Security 2
WS 2010/2011
System Security Lab
3.3.4. Using OpenSolaris Trusted Extensions . . . . . . . . . . . . . . . . 48
4. Exercise: Role Based Access Control
4.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1. Applications . . . . . . . . . . . . . . . . .
4.1.2. Roles . . . . . . . . . . . . . . . . . . . . .
4.1.3. Domains/Types . . . . . . . . . . . . . . . .
4.1.4. Permissions . . . . . . . . . . . . . . . . . .
4.2. Theoretical Assignments . . . . . . . . . . . . . . .
4.2.1. Prepare a SELinux Policy (max. 25 Points)
4.3. Practical Assignments . . . . . . . . . . . . . . . .
4.3.1. Implement the Policy (max. 25 Points) . .
.1. Short Reference for the Applications . . . . . . . .
.1.1. mutt . . . . . . . . . . . . . . . . . . . . . .
.1.2. boa . . . . . . . . . . . . . . . . . . . . . .
.1.3. exim . . . . . . . . . . . . . . . . . . . . . .
.1.4. Other Useful Commands . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
51
51
51
51
52
52
54
54
54
54
56
56
56
56
56
A. Appendix: Python Language
A.1. Regular Expressions . . . . . . . . . . . . . . . . . . . . . . .
A.2. Syscalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2.1. fork - create a child process . . . . . . . . . . . . . . .
A.2.2. exit - terminate the calling process . . . . . . . . . .
A.2.3. wait, waitpid, waitid - wait for process to change state
A.2.4. getpid, getppid - get process identification . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
59
59
61
61
63
64
70
B. Appendix: SELinux Introduction
B.1. Introduction . . . . . . . . . . . . . . . . .
B.1.1. Motivation . . . . . . . . . . . . .
B.2. SELinux Terms . . . . . . . . . . . . . . .
B.3. How it Works . . . . . . . . . . . . . . . .
B.3.1. Linux Security Modules . . . . . .
B.3.2. The SELinux Architecture . . . . .
B.3.3. SELinux Files and Filesystems . .
B.3.4. File Labeling . . . . . . . . . . . .
B.3.5. Enforcing, Permissive or Disabled?
B.3.6. The Boot Process on SELinux . .
B.3.7. Domains, Types and Transition . .
B.3.8. Roles . . . . . . . . . . . . . . . .
B.3.9. Optional Policies . . . . . . . . . .
B.3.10. Booleans . . . . . . . . . . . . . .
B.3.11. Dominance . . . . . . . . . . . . .
B.3.12. Constraints . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
71
71
72
73
78
78
78
80
80
81
82
82
85
85
86
86
87
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
WS 2010/2011
System Security Lab
B.4. The Policy . . . . . . . . . . . . . . .
B.4.1. The Reference Policy . . . . .
B.4.2. Compiling the Policy . . . . .
B.4.3. Type Enforcement Rules . . .
B.4.4. Strict and Targeted Policy . .
B.4.5. Multi-Level-Security . . . . .
B.4.6. Multi-Category-Security . . .
B.4.7. Policy Files . . . . . . . . . .
B.4.8. Audit Log . . . . . . . . . . .
B.5. Basic Commands . . . . . . . . . . .
B.6. Usage Examples . . . . . . . . . . .
B.6.1. Adding a User . . . . . . . .
B.6.2. Using Booleans . . . . . . . .
B.6.3. Inspecting the logfiles . . . .
B.6.4. Writing a new Policy Module
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
87
87
88
88
90
91
93
94
98
99
100
101
101
102
103
WS 2010/2011
System Security Lab
Organisatorische Aspekte
Im diesem Wintersemester werden wir praktische Übungen zu vier Themenbereichen
bearbeiten. Die Übungen sollen zeigen, wie in der Vorlesung Systemsicherheit II vorgestellte
theoretische Konzepte der Systemsicherheit (z. B. reaktive Sicherheitsmechanismen, Zugriffskontrolmechanismen) in der Praxis umgesetzt werden. Der in den Labor-Übungen
behandelte Stoff ist ein integrativer Teil der Veranstaltung und somit prüfungsrelevant.
Die Übungen finden im Labor für Betriebssystemsicherheit und Trusted Computing (ID
2/167) statt. Die Termine sind in den Kalenderwochen 49. und 50. im Jahr 2010
(Dezember) und 2. und 4. im Jahr 2011 (Januar), wie in der Tabelle dargestellt. Berücksichtigen Sie bitte, dass diese Tabelle ein vorläufiger Plan ist und dass sich Änderungen ergeben könnten. Eventualle Änderungen werden so schnell wie möglich auf der
Vorlesungs-Webseite und über die Mailingliste angekündigt.
Gruppe 1
Gruppe 2
Gruppe 3
6.12.2011
7.12.2011
7.12.2011
LaborSprechstunde
Übung 1 (49. KW)
Logging and Auditing
8.12.2011
13.00-14.30 Uhr 10.00-11.30 Uhr 12.00-13.30 Uhr 14.00-15.30 Uhr
Übung 2 (50. KW)
DAC (Discretionary
Access Control)
14.12.2010
13.12.2010
14.12.2010
15.12.2010
13.00-14.30 Uhr 10.00-11.30 Uhr 12.00-13.30 Uhr 14.00-15.30 Uhr
Übung 3 (2. KW)
MAC (Mandatory
Access Control)
11.01.2011
10.01.2011
11.01.2011
12.01.2011
13.00-14.30 Uhr 10.00-11.30 Uhr 12.00-13.30 Uhr 14.00-15.30 Uhr
Übung 4 (4. KW)
RBAC(Role-Based
Access Control)
24.01.2011
25.01.2011
25.01.2011
26.01.2011
13.00-14.30 Uhr 10.00-11.30 Uhr 12.00-13.30 Uhr 14.00-15.30 Uhr
Bitte kommen Sie ins Labor nur zu dem Termin, für den sie sich während der Übung am
22. November 2010 eingetragen haben. Sie können zu einem anderen Termin kommen,
nur wenn Sie einen ”Tauschpartner” finden. Dies ist wichtig, da wir im Labor nur 20
Arbeitsplätze haben.
7
WS 2010/2011
System Security Lab
Für jede der vier Übungen sind 90 Minuten vorgesehen (2 Stunden). Erfahrungsgemäß reicht die Zeit für durchnittliche Studenten, die sich für die Übung durch die
Hausaufgabe vorbereitet haben. Falls Sie mehr Zeit brauchen, Fragen haben, oder etwas
wiederholen möchten, können Sie während der Lab-Sprechstunde kommen. Bitte melden
Sie sich vorher per e-Mail an, wenn Sie ganze Übung wiederholen möchten, damit wir
entsprechende Ressourcen (Betreuer, Rechner) zur Verfügung stellen können.
Jede Übung besteht aus einem theoretischen und einem praktischen Teil. Der theoretische Teil ist zu Hause zu bearbeiten und die Antwort auf die Aufgaben ist vor der
jeweiligen Übungsstunde dem Übungsbetreuer abzugeben. Ohne Bearbeitung der
theoretischen Aufgaben ist die Bearbeitung des praktischen Teils im Labor
nicht möglich!!!
Notieren Sie die Ergebnisse der im Labor durchgeführten praktischen Aufgaben und
geben Sie den Zettel am Ende der Übung dem Übungsleiter ab (wenn Sie einen Feedback wünschen). Der Übungsleiter bewertet nach der Übung sowohl die abgegebenen
Antworten der theoretischen Fragen als auch die im Labor durchgeführten praktischen
Aufgaben. Sie bekommen die Korrekturen in der Regel zwei Wochen später.
Um Ihnen optimal helfen zu können, werden wir versuchen, dass zu jedem Termin drei
Betreuer von dem folgenden Team des Lehrstuhls für Systemsicherheit im Labor sind:
Biljana Cubaleska
Christoph Kowalski (Verantwortlich fr den Lab-Betrieb)
Atanas Filyanov (Verantwortlich fr den Lab-Betrieb)
Tobias Hommel
Martin Steegmans
Immo Wehrenberg
Alle Betreuer sind über die Mailingliste [email protected] zu erreichen. Bitte nutzen
Sie ausschlies̈slich diese Mail-Adresse. So kann gewährleistet werden, dass Ihre Fragen
rechtzeitig beantwortet werden!
8
WS 2010/2011
System Security Lab
Some Notes on Virtualization
Nearly all practical exercises for this course will use the virtualization software VirtualBox. Using this software we can run several guest operating systems on a single machine.
In the following, we give just a very short introduction in virtualization.
The idea behind a virtual machine is to abstract the hardware of a single computer
(the CPU, memory, disk drives, network interface cards) into several different execution
environments, thereby creating the illusion that each separate execution environment
is running its own private computer. Each guest is provided with a (virtual) copy
of the underlying computer and the operating system host creates the illusion that
each guest has its own processor and (virtual) memory. A virtual machine takes the
layered approach to its logical conclusion and treats the hardware and the OS kernel as
though they were all hardware and provides an interface identical to the underlying bare
hardware. Virtual machines first appeared commercially in IBM mainframes in 1972.
processes
programming
interface
processes
processes
processes
kernel
kernel
kernel
VM 1
VM 2
VM 3
kernel
virtual-machine
implementation
hardware
hardware
(a) nonvirtual machine
(b) virtual machine
Figure 0.1.: Non-virtual vs. virtual machine.
Reasons for creating a virtual machine Fundamentally, several different execution
environments (i.e. different OSs) are able to share the same hardware and execute concurrently. In a VM environment, there is complete protection of the various system
resources, with each VM completely isolated from all the other, so there are no protection problems. There is no direct sharing of resources at the same time, except some
controlled and permitted sharing. Moreover, a VM environment is a perfect tool for OS
research and development, as there is no need to change the current OS and there is no
need to stop the working OS in order to start a development environment. Another rea-
9
WS 2010/2011
System Security Lab
son is that many low-resource systems could be consolidated onto fewer busier-systems.
Examples of VMs Despite the advantages of VMs, they received little attention for a
number of years after they were first developed. Today they are being “rediscovered”
again. Examples of virtualization technologies include VMware, Java virtual machine,
VirtualBox and others.
application
application
application
application
guest operating
system
guest operating
system
guest operating
system
(freeBSD)
(Windows NT)
(Windows XP)
virtual CPU
virtual memory
virtual devices
virtual CPU
virtual memory
virtual devices
virtual CPU
virtual memory
virtual devices
virtualization layer
host operating system (Linux)
hardware
CPU
memory
I/O devices
Figure 0.2.: VirtualBox architecture.
Since we will use the virtualization software VirtualBox for the practival exercises, it is
essential that you are familiar with it. Figure 0.2 shows the architecture of VirtualBox.
If needed, you can use the VirtualBox User Manual ([Ora]).
10
References Virtualization
[Ora] Oracle. Virtualbox user manual.
http://download.virtualbox.org/virtualbox/3.2.10/UserManual.pdf.
11
1. Exercise: Logging and Auditing
Duration: 90min
Contents
1.1. Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2. Theoretical Assignments . . . . . . . . . . . . . . . . . . . . . . 17
1.3. Practical Assignments . . . . . . . . . . . . . . . . . . . . . . . . 19
Motivation and goals: We will have a look on logging and auditing
mechanisms in operating systems. The goal is to learn, how you can
gather information in a running OS and what conclusions can be drawn
from logs.
1.1. Introduction
Logging is the tracking of a machine’s activity. Log files are a record of the events
occurring within an organization’s systems and networks, and can be as simple as a
plain text file or as complex as a database. Auditing is the analysis of log records
to present information about the system in a clear and understandable manner. On
Windows Operating Systems, logging is provided by the Event Log Service, storing data
in three different sets of logs. The system event log contains records of events such as
system crashes, component failures and other events. The application event log contains
records that the applications have added. These records are under the control of the
applications. The security event log contains records corresponding to security-critical
events such as logins and logouts, exhaustive system resource usage, and accesses to
system files. Only administrators are allowed to access the security event log. On Linux
Operating Systems, data is often stored in /var/log and is provided by the syslog
service. Linux logging information is saved in a human readable format, thus can be
easily read with a standard text editor (e.g. gedit, Kate, vim), while the Windows
logs are only viewable using the Windows Event Viewer. In addition, Windows uses a
proprietary format to store logs, and third party software might be needed to convert
the files into a processable format. This exercise will demonstrate logging events on both
Windows and Linux systems. Additionally a logging infrastructure should be created,
which allows filtering and transmitting log files to a central location automatically.
13
WS 2010/2011
System Security Lab
An example of a Windows security event log might look like the following:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Date :
Time :
Type :
User :
Computer :
8/12/2008
13:03
Success
PC05\ l a b o r
PC05
Source :
Category :
EventID :
Security
D e t a i l e d Tracking
592
Description :
A new p r o c e s s has been c r e a t e d :
New P r o c e s s ID :
2216594592
Image F i l e Name :
\ Program F i l e s \ I n t e r n e t E x p l o r e r \IEXPLORE .EXE
C r e a t o r P r o c e s s ID : 2217918496
User Name :
Administrator
Logon ID :
( 0 x0 , 0 x14B4c4 )
1.1.1. Log Analysis
After being collected, a log record is being analysed. One of the most common programs
for log analysis is swatch[swa]. It uses regular expressions (see Apendix) to match a
line. In the next pattern example, swatch looks for a line in the log file that contains
the word denied, Denied, or anything that starts with DEN and ends with ED. Once it
finds a line that contains one of the three search strings, it echoes the line in bold into
the terminal and sends an E-Mail to the user that is running swatch:
1 watchfor
/ [ dD ] e n i e d | /DEN. ∗ED/
2
echo b o l d
3
mail
Using swatch is very simple. For using swatch to check a log file once, run:
swatch --examine=/var/log/messages
This assumes that the default configuration file for swatch is used, which should be located in the user’s home directory and is called .swatchrc and that /var/log/messages
is the file to be checked. To use swatch running as a service that scans lines of a log file
as they come in, run:
swatch --tail-file=/var/log/messages
1.1.2. Logging Infrastructure
In today’s large and complex information systems, managing a logging infrastructure
is a challenge. The open source syslog-ng[sysa] application enables you to send log
messages of your hosts to a central logserver using the latest syslog protocol standards.
The syslog-ng application can sort the incoming log messages based on their content
14
WS 2010/2011
System Security Lab
and various parameters like the source host, application, and priority. It can also separate
parts of log messages to named fields or columns, and modify the values of these fields,
for example to remove sensitive data. Complex filtering using regular expressions and
boolean operators offer almost unlimited flexibility to forward only the important log
messages to the selected destinations. The syslog-ng application is the ideal choice for
collecting logs in massively heterogeneous environments using several different operating
systems and hardware platforms, including Linux, Unix, BSD and Sun Solaris. Agents
are available for Microsoft Windows hosts to transfer logs to the central syslog-ng
server. A sample syslog-ng server configuration file looks like the following:
1
2
3
4
5
6
7
8
9
10
11
12
source s s r c {
t c p ( i p ( 0 . 0 . 0 . 0 ) p o r t ( 5 0 0 0 ) max−c o n n e c t i o n s ( 3 0 0 ) ) ;
};
destination d authlog {
f i l e ( ” / var / l o g / auth . l o g ” ) ;
};
log {
source ( s s r c ) ;
destination ( d authlog ) ;
};
In the example above, the server listens for ip connections on port 5000 and if a message
comes it is redirected and saved to /var/log/auth.log. The next variables can be used
to create subdirectories:
1. $HOST creates a directory with the hostname, from which the log came.
2. $R YEAR creates a directory with the current year.
3. $R MONTH creates a directory with the current month.
4. $R DAY creates a directory with the current day.
5. $R HOUR creates a directory with the current hour.
They are appended to the destination’s path, e.g. /var/log/$HOST/$R YEAR/auth.log
1.1.3. Linux auditing
auditd is the userspace component to the Linux Auditing System. It writes audit records
to the disk. You can configure auditd to record any activity for a specific file (reading,
writing, executing, etc.). The audit rules are configured with the auditctl utility, and
viewing the logs is done with the ausearch.
15
WS 2010/2011
System Security Lab
1.1.4. Regular Expressions
As you should have noticed, one of the most important parts of logging and auditing
is the analysis of log files. This surely cannot be done fully automated, but doing this
assisted by the computer is usually the only way to handle large amounts of log files
in a realistic time period. To extract relevant text data, one usually describes patterns
and lets a computer program extract this. For basic tasks, the grep command (or more
advanced tools like swatch) on Unix systems are sufficient, but often it is interesting to
use more advanced tools like the perl or the python programming language. What all
these tools have in common is a formalized syntax to analyze text strings. This syntax
is called regular expressions. You can get familiar with regular expressions by reading
A.1.
16
WS 2010/2011
System Security Lab
1.2. Theoretical Assignments
If you want a feedback for your solutions, please prepare the theoretical assignments at
home and your answers to us at the beginning of the practical assignment!
1. Why do you think audit policies are disabled by default?
2. What do you think are the advantages and disadvantages of storing log files on a
central server? Give a short explanation.
3. Assume that a big company has implemented a logging infrastructure. The raw
log messages are transmitted to a central storage location with a rate of 2000
messages/second, each message with a size of 200 Bytes. How much storage space
is needed per month? There are different ways to optimize the result. Give at
least two ideas.
4. Consider the following log. Which information can you extract from it? In which
file can this information be found?
1 Nov 30 1 9 : 2 1 : 5 3 kubuntu sudo : l a b o r : TTY=p t s /4 ; PWD=/y
home/ l a b o r ; USER=r o o t ; COMMAND=/u s r / s b i n / u s e r a d d −d y
/home/ t e s t u s e r −m t e s t u s e r
2 Nov 30 1 9 : 2 1 : 5 3 kubuntu sudo : pam unix ( sudo : s e s s i o n ) : y
s e s s i o n opened f o r u s e r r o o t by ( u i d =0)
session closed for user root
4 Nov 30 1 9 : 2 1 : 5 3 kubuntu u s e r a d d [ 3 1 1 8 3 ] : new group : name=y
t e s t u s e r , GID=1003
5 Nov 30 1 9 : 2 1 : 5 3 kubuntu sudo : n a s k a t a : TTY=p t s /4 ; PWDy
=/var / l o g ; USER=r o o t ; COMMAND=/b i n / mkdir HOSTS
8 Nov 30 1 9 : 2 1 : 5 3 kubuntu CRON[ 1 0 8 3 1 ] : pam unix ( c r o n : y
s e s s i o n ) : s e s s i o n opened f o r u s e r r o o t by ( u i d =0)
9 Nov 30 1 9 : 2 1 : 5 3 kubuntu CRON[ 1 0 8 3 1 ] : pam unix ( c r o n : y
session ) : session closed for user root
10 Nov 30 1 9 : 2 1 : 5 3 kubuntu u s e r a d d [ 3 1 1 8 3 ] : new u s e r : name=y
t e s t u s e r , UID=1001 , GID=1003 , home=/home/ t e s t u s e r , y
s h e l l =/b i n / sh
11 Nov 30 1 9 : 2 1 : 5 3 kubuntu CRON[ 7 9 0 3 ] : pam unix ( c r o n : s e s s i o n y
) : s e s s i o n opened f o r u s e r r o o t by ( u i d =0)
) : session closed for user root
17
WS 2010/2011
System Security Lab
18 Nov 30 1 9 : 2 2 : 0 0 kubuntu sudo : l a b o r : TTY=p t s /4 ; PWD=/y
home/ l a b o r ; USER=r o o t ; COMMAND=/u s r / b i n / passwd y
testuser
19 Nov 30 1 9 : 2 2 : 0 0 kubuntu sudo : n a s k a t a : TTY=unknown ; y
PWD=/home/ n a s k a t a ; USER=r o o t ; COMMAND=/u s r / b i n /y
adept updater
24 Nov 30 1 9 : 2 2 : 0 5 kubuntu passwd [ 3 1 1 9 3 ] : pam unix ( passwd : y
chauthtok ) : password changed f o r t e s t u s e r
5. Write a small Python script that reads the /var/log/auth.log file and outputs
the users which failed to authenticate, together with the date and time when that
happened. Output only the username and the corresponding date and time, not
the whole line. Sample lines in the file look like this:
1 Nov 30 2 0 : 4 4 : 1 0 kubuntu sudo : pam unix ( sudo : auth ) : y
a u t h e n t i c a t i o n f a i l u r e ; logname= u i d=0 e u i d=0 t t y=/devy
/ p t s /4 r u s e r= r h o s t= u s e r=l a b o r
2 Dec 20 1 5 : 1 7 : 2 7 kubuntu sudo : pam unix ( sudo : auth ) : y
a u t h e n t i c a t i o n f a i l u r e ; logname= u i d=0 e u i d=0 t t y=/devy
/ p t s /4 r u s e r= r h o s t= u s e r = r o o t
6. Give a regular expression that matches on a) a date b) valid e-mail-address
18
WS 2010/2011
System Security Lab
1.3. Practical Assignments
1.3.1. Linux
1. Generate some logs by entering 3 wrong passwords when executing the command
sudo nano /var/log/auth.log.
2. Write and execute a sample swatch configuration file that prints the lines, which
contain ”authentication failure” and ”user=xxxx or user xxxx” in bold, where
xxxx can be either labor or root, and the lines that contain ”3 incorrect password
attempts” in bold and red. Write down your results!
3. As both /etc/passwd and /etc/shadow are security critical, we want to audit
them. Use the auditctl1 command to define rules for both files. Audit the files
for reading and writing.
4. Now generate some logs by adding a new user to the system and check out the logs
using the ausearch2 command.
5. You have to configure a logging infrastructure. For this exercise you have to use the
Ubuntu VM as a server and the host system as a client. Configure the server to listen for connections and store the incoming logs to /var/log/archive/messages/.
Subdirectories for host, year, month and day should be automatically created. The
server’s /var/log/auth.log should also be backed-up.
Hints: Use the syslog-ng documentation[sysb] as a reference. The default syslog-ng
listening port is 514.
6. Configure the client to send the logs from /var/log/messages, /var/log/auth.log
and /var/log/audit/audit.log to the server. Test your results and write down
your answers!
1.3.2. Windows
Use a Windows VM for this exercise. Leave the VM logserver running, as it will be
needed further in this exercise.
1. By default, all Audits in Windows are disabled. To enable it, select Start and
type secpol.msc. The Local Security Settings Management control window will
show up.
2. Configure the Audit Policy to track user logons.
3. Create entries in the log by logging out and in again.
1
2
man auditctl
man ausearch
19
WS 2010/2011
System Security Lab
4. As mentioned in the introduction, the windows logs are accessible via the Event
Viewer. To see them, select Start and type compmgmt.msc. Find where the logs
are!
5. Sometimes it is quite a good idea to audit the access to security-related files and
folders. To do that in Windows Vista you have to enable the Audit Policy first.
Select Success and Failure.
6. Your task now is to configure the access to which a security-critical file should
be monitored. For this use the C:\Test\security.log file. Make the neccessary
configuration, so that an audit record is generated when the file is read.
Hint: Look for the Audit tab in the file’s properties.
7. Read the file to generate a log and try to find out the Event ID of the generated
log!
8. Since Windows does not support syslog natively, a third-party application is required to support the syslog facility. Snare[Snaa] is a freeware Windows application that will run as a service in Windows, monitor Application, System and
Security events, format them into a single line and send them to a syslog server.
Your task is to configure Snare so that the logs are forwarded to the already running syslog-ng server (Section 1.3.1). Refer to the Snare documentation[Snab].
You can configure Snare by entering localhost:6161 in a browser.
20
References Chapter Logging and Auditing
[Snaa] Snare.
http://www.intersectalliance.com/projects/SnareWindows/.
[Snab] Snare documentation.
http://www.intersectalliance.com/resources/Documentation/Guide_to_
Snare_for_Windows-2.8.pdf.
[swa]
swatch.
http://sourceforge.net/projects/swatch/.
[sysa] syslog-ng.
http://www.balabit.com/network-security/syslog-ng/
opensource-logging-system/.
[sysb] syslog-ng documentation.
http://www.balabit.com/dl/guides/syslog-ng-v3.0-guide-admin-en.
pdf.
21
2. Exercise: Discretionary Access Control
Duration: 90min
Contents
2.1.
2.2.
2.3.
2.4.
Introduction . . . . . . . . . . . . . . . .
Theoretical Assignments (Homework) .
Practical Exercise on Unix . . . . . . . .
Practical Exercise on Windows Vista (8
. . . . .
. . . . .
. . . . .
Points)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
29
33
35
Motivation and goals: In this practical exercise we are going to learn
how Discretional Access Control (DAC) is used in practice. We will
have a look on the access control mechanisms in Unix-like systems
and Windows. Goal of this exercise is showing the concepts and the
limitations of DAC in practice.
2.1. Introduction
2.1.1. Basics: Users and Groups
Most operating systems (e.g. Solaris [Opeb], OpenBSD [Opea], GNU/Linux [Wika],
Windows [Wikb], etc.) are designed for multiple users and groups. A group is simply
a set of subjects (users or system processes). A single subject may be a member of
multiple groups.
2.1.2. Access Control Concepts in Unix-Like Systems
Traditional Unix Permissions
Unix-like systems uses discretionary access control (DAC) to control access to files and
directories. There are some important notions that you have to know:
• Subjects: A subject on a linux system is a user (more precisely, it is the process
the user controls, which is trying to access an object). A user is represented by a
username, which is mapped to a numerical user ID (UID).
• Groups: A user can be a member of one or more groups.
• Owner: A user who owns an object has special permissions on it, like right to
delete it or to change permissions.
23
WS 2010/2011
System Security Lab
• Superuser or root: The superuser (UID 0) has special privileges that are divided
into a set of capabilities. He can do nearly everything that is not restricted by the
underlying hardware.
• Objects: Files and directories represented by their filename.
There are 3 types of permission, that a subject (user, process) can have on an object (a
file or a directory).
• Read (r): A subject may read the file content
• Write (w): A subject may change the file
• Execute (x): A subject may execute the file
Furthermore, access rights to objects are managed for three different categories of users:
• Owner: Owner of the object. A file or a directory always belongs to one user and
one group. Unlike on Windows, files cannot be owned by multiple groups
or users.
• Group: User belonging to some group. If more than one user has to access a file,
users can be assigned to groups. That means if two users U0 and U1 need to write
to the file example.txt, one (root) has to create a new group for these two users
and set the group permissions for the file accordingly.
• Others: Other users, not belonging to the group
“owner” rights
“group” rights
“other” rights
r wx r wx r wx
111101100
5
4
7
Example:
Figure 2.1.: Traditional Unix access control flags attached to an object
So, as shown in figure 2.1, an access control information of 9 bits (or flags) is attached
to each object in the system. The flags are translated into a bitwise representation as
follows:
• Bit 0: Execute flag (x)
24
WS 2010/2011
System Security Lab
• Bit 1: Write flag (w)
• Bit 2: Read flag (r)
These bits can be interpreted as an octal number. Flags for the user, the group and
others can be concatenated into a 3-digit representation. E.g., the number 754 means
that the owner has rights to read, write and execute, the group has permission to execute
and read, and everyone else may only read the file. Because it may be difficult to handle
for many users the octal representation of access flags, it has become common to use the
letters r, w and x as representation for access rights.
Example: The command ”ls -ld /etc/mail” displays the output below:
Figure 2.2 illustrates how Unix-like systems check if a subject can access an object.
process tries to
access a file
process uid == process owner?
no
“others” have necessary yes
group section of file permissions allows access?
owner section of file permissions allows access?
access
granted
no
permissions?
yes
yes
user in files group?
no
access
denied
yes
access
granted
yes
no
access
granted
access
denied
no
access
denied
Figure 2.2.: Processing of access request in Unix
Utilities The programs chmod, chgrp and chown can be used to modify access rights
on most Unix-like systems. chmod changes the access flags of a file or a directory (for
all three sections), chgrp is used to change the group and chown changes the owner of
a file (chown can change the group too). Normally just the superuser can change the
user-owner and object’s group. The real owner can just use chown and chgrp to change
the group to another group of which he is a member. The owner without root rights can
25
WS 2010/2011
System Security Lab
not give the ownership to another user or to another group if he is not a member of a
new group.
Syntax
• chmod < permissions > < user : group > object
• chgrp < group > object
• chown < user : group > object
Examples
• chmod 600 file.txt or chmod u=rw file.txt - Make the file file.txt read- and
writeable exclusively to its owner (the digitwise binary representation of 600 is 110
000 000).
• chmod 640 file.txt or chmod u=rw,g=r file.txt - Owner can read and write;
members of the group can read the file file.txt and allow its owner to read and
write (The digitwise binary representation of 640 is 110 100 000).
• chgrp students file.txt - Change the group of file.txt to the group students.
• chown user1 file.txt - Change the ownership of file.txt to the user user1.
• chown user1:grp1 file.txt - Change the ownership of file.txt to the user user1
and to the group grp1 (user1 is a member).
The setuid and setgid bits are special bits to change the user or the group of an
executable during runtime. When set, they allow other users to execute a program with
rights of its owner and or group.
Access Control Lists in Unix
The traditional access control model does not scale well on systems with a large amount
of users. So-called Access Control Lists (ACL) provide an extension to the traditional
filesystem access model. Access control lists allow more fine-grained setups of access
rights in contrast to the traditional Unix access control model.
Utilities The utilities setfacl and getfacl can be used to set and print the access
control rights of a file. They have the following syntax:
• setfacl -m accessrights filename
Modifies the permissions accessrights for the file or directory filename
• getfacl filename
Prints the permissions for the file or directory filename
26
WS 2010/2011
System Security Lab
When using setfacl, the accessrights field must have a certain format which is described in the setfacl manpage1 .
Most of the GNU/Linux systems don’t have ACL support enabled by default. You
need to invoke mount with the additional argument (-o acl) to enable ACLs for a certain
mountpoint.
2.1.3. Access Control on Windows Vista
In Microsoft Windows two different types of users have been defined. The first one is
called ”administrator” and the second one is called ”standard user”. The operating
system allocates Security Identifiers (SIDs) to each user and their group memberships.
They are used by the access control lists (ACLs), which define rights to the resources to
be accessed. For any user action that requires a permissions check, Windows checks the
SID to see if the action is allowed. The SID is equivalent to the UID in UNIX.
In Windows there are five simple right levels that summarize 24 specific rights. The
simple rights are listed below:
• modify
• read
• write
• execute
• full control
An overview of the special rights is given in [Mic].
When a file is created within a directory having a set of access rights, these access
rights are also applied (inherited ) to the file. A standard user is just allowed to set
rights on own objects (i.e., the user or the user’s group is the object’s owner). So it is
not possible that a standard user set the permission for C:\.
Windows uses access tokens to identify the security context of a process or a thread
when it interacts with a secure object or tries to perform a system task that requires
elevated privileges. The security context stores information on the privileges, accounts
and groups the process is associated with. Depending on the ordering of the access
control entries (ACE) in the object’s DACL that are compared with the user’s access
token, access is permitted or denied. Factors to permit access are:
• global group membership
• local group membership
• local permissions
1
man 1 setfacl
27
WS 2010/2011
System Security Lab
• local privileges
• global universal group memberships
The ordering is fixed for a standard system, but it is possible to change the order.
Utilities The permissions can be viewed by the graphical user interface (gui). One
should click right on a object-icon (file or directory) and choose then ”properties”. In
the new dialog choose the slider ”security” (see the Figure 2.3). In the introduction, four
access control entries (Authenticated User, SYSTEM, Administrators and Users) have
been mentioned. By clicking on one ACE your can see the permissions of these groups
and users. The ordering of the ACE-Entries is important for allowing or denying
access to the object.
Figure 2.3.: Windows GUI-Dialog to see permission
The other way to set / view permissions to an object is to use ICACLS.EXE [Mic]. It
is a command line program that allows to get better granular control over permissions.
It can be invoked by Start→Execute→icacls.exe.
28
WS 2010/2011
System Security Lab
2.2. Theoretical Assignments (Homework)
2.2.1. Access Control on Unix-Like Systems
1. Imagine a company having a Server with 100 users on it. These users all work in
groups of two users per group. One day a manager decides to form groups with
four users each. How many groups do you have at the end, assuming that the old
groups are retained? Jusify your answer!
2. Why is the transferring of he ownership right to another user not allowed for a
normal user?
3. Write down the representation for the following access flag combinations (octal
form and with abbreviation letters (r,w,x)) and for the different levels (user, group,
other):
• Read / Write for user and group, no rights for others
• Read / Execute for user, Read for group and others
• Read / Write / Execute for user, Read / Execute for group and Read for
other
4. You are the owner of the file report1.txt. How can you achieve that all user in
the system, except the user praktikant can read the file?
5. You are the owner of the file report2.txt. The file can just be read by the group
consisting of the users u1 , u2 , ...., u7 . You now want to enable the user u8 to read
the file. What should you do?
6. Who is responsible for creating and maintaining groups in Unix? What are the
advantages and disadvantages of this?
29
WS 2010/2011
System Security Lab
2.2.2. Access Control on Windows
1. Is there a flag that can be set in order to set permissions for every other user on
the system? If not, explain what has to be done in order to allow every user on
the system to access a file.
2. Explain the difference between the rights ”modify” and ”write”!
3. What right(s) is (are) necessary in order to modify access control to a file or
directory?
4. The following icacls.exe output2 is given:
test.txt
labor − V M \u1 : (DEN Y )(S, W D, AD)
labor − V M \u2 : (DEN Y )(W )
labor − V M \u4 : (N )
labor − V M \u1 : (Rc, W DAC, W O, S, RD)
labor − V M \u2 : (RX)
labor − V M \u3 : (RX)
V ORDEF IN IERT \Benutzer : (W, RD, REA, X, RA)
V ORDEF IN IERT \Administratoren : (I)(F )
N T − AU T ORIT AET \SY ST EM : (I)(F )
V ORDEF IN IERT \Benutzer : (I)(RX)
N T − AU T ORIT AET \Authentif izierteBenutzer : (I)(M )
1 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler aufgetreten.
Describe which rights the user u1, u2, u3 and u4 have. The users are
in the group ”Benutzer”.
2
Command: icacls.exe test.txt > acl.doc
30
WS 2010/2011
System Security Lab
2.2.3. General Questions
1. Revoking an individual’s access to a particular file is easy when an ACL is used.
How hard is it to revoke a user’s access to a particular set of files, but not to all
files? Compare and contras this with the problem of revocation using capabilities.
2. It is said that Unix uses access control lists. Does the Unix include also capabilities?
(Hint: Consider file descriptors. If a file is opened, and its protection mode is
changed to exclude access by the opener, can the process still access the file using
the file descriptor?)
3. A noted computer security expert has said that without integrity, no system can
provide confidentiality.
• Do you agree? Yustify your answer!
• Can a system provide integrity without confidentiality? Justify your answer!
4. A cryptographer once claimed that security mechanisms other than cryptography
were unnecessary because cryptography could provide any desired level of confidentiality and integrity. Either justify or refuse the cryptographer’s claim (ignore
the goal availability)!
31
WS 2010/2011
System Security Lab
5. Compare the HRU protection model with the Take-Grant protection model. Think
about the following points:
• Which policy do the models represent?
• How the protection system is represented?
• What is the set of rights?
• How do the states of the system changes?
• Safety question?
• Limitations of the models?
• Other points?
32
WS 2010/2011
System Security Lab
2.3. Practical Exercise on Unix
2.3.1. Standard Unix Permissions
1. Write down the commands to
• Create a group named ”team0”:
• Add the users user0 and user1 to that group:
• Change the group of the file ”example.txt” to the newly created group:
2. Let G0 be a group consisting of the users u0 and u1 . Over time, the users u0 and
u1 have created many files to which only they have access. One day a third user
u2 needs to have write access to a directory which is owned by the group G0 , but
must not have access to other directories owned by the group (therefore adding
the user to G0 is not an option).
Describe the steps necessary to give U2 write access to the directory without utilizing ACLs!
3. Check the permissions of hello.py (ls -l) and remember it (permissions, owner,
group) Use chmod (as user labor) and set the rights to the file hello.py as follows:
For the user read / write, for the group read / execute and others just read. Set the
group to ”labor”. Try to start the script hello.py in a terminal (./hello.py).
The execute-flag is set for the group ”labor” and the script does not
start. Why?
How can you fix it?
Put the settings (permissions, group) back to initial status.
Why it is not possible so set the group back?
4. Take a look at the access rights set for the program /bin/ping on your local system.
What is different compared to other binaries like /bin/sleep for example? (use
ls -l). Describe it.
5. Who is the owner of /bin/ping? Suppose there is an exploitable buffer-overflow
in the ping program. What implications does this have on system security?
33
WS 2010/2011
System Security Lab
2.3.2. ACLs in Unix
1. Assume the scenario from the exercise 3.1.2. Describe the steps neccessary to give
u2 write access to the directory using ACLs!
2. Follow the following instructions:
• Create a file of 100 megabytes in size with the command head -c 100m
/dev/zero > fsimage0.
• Create an ext3 filesystem in that file with the command mkfs.ext3 fsimage0.
The program mkfs will warn you about creating a filesystem in a file - you
can safely answer that question with yes.
• Now mount the newly created image with the additional argument for ACLs
(mount -o acl ...).
• Add the user ”user2”. Create a file named ”example.txt” in your newly
created filesystem image. Use setfacl to grant write permissions to the user
user2.
• Create the group ”team0”, add the users ”user0” and ”user1” to that group
and change the group of the file to ”team0”.
3. Run ls -l example.txt and then execute getfacl example.txt. What are
the differences between the two outputs? Give a short explanation for the
different behavior:
34
WS 2010/2011
System Security Lab
2.4. Practical Exercise on Windows Vista (8 Points)
Boot Ubuntu and start VirtualBox → Boot Windows Vista as virtual machine. The
login-screen shows three user-accounts: admin, user1 and user2. The last two accounts
are Standard user and admin is in the group Administrators.
User admin created a file called admin.txt in the folder ”‘c:/test/”’. He gave no
permissions to read/write the file admin.txt to user1. user2 is allowed to read the file.
1. Is it possible that user2 can help user1 to read the text of the admin.txt? If it
is possible, what would you have to do (as user2) to make it work? Verify your
solution practically.
2. Can you prohibit the scenario (see Question 1)? Login as ”labor” and configure
the permissons of admin.txt. Write down your solution.
3. How can you make that the other users have no access to your file? If it is possible,
can you prohibit that administrators can access your file? Configure it and make
a ICACLS.EXE ouput3 of example.txt and send your solution via e-mail.
3
Command: icacls.exe test.txt > acl.doc
35
References Discretionary Access Control
[Mic]
Microsoft. icacls.exe description.
http://technet.microsoft.com/en-us/library/cc753525%28WS.10%29.
aspx.
[Opea] Openbsd.
http://www.openbsd.org/.
[Opeb] Opensolaris.
http://hub.opensolaris.org/bin/view/Main/.
[Wika] Wikipedia. Linux.
http://en.wikipedia.org/wiki/Linux.
[Wikb] Wikipedia. Windows.
http://de.wikipedia.org/wiki/Microsoft_Windows.
37
3. Exercise: Mandatory Access Control
Duration: 90min
Contents
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3. Practical Assignments . . . . . . . . . . . . . . . . . . . . . . . 47
Motivation and goals: In this exercise we present how access control in OpenSolaris works. The first practical assignments deal with
the default discretionary access control (DAC) and the further assignments show how mandatory access control (MAC) is implemented in
OpenSolaris.
3.1. Introduction
3.1.1. OpenSolaris
OpenSolaris [Opec] is an open-source, Unix-like Operating System (OS) developed by
Sun. It is based on the commercial Solaris OS and is licensed under the Common Development and Distribution License (CDDL) [CDD] with some pre-compiled proprietary
binaries. The latest stable release is 2009.06 and the next is planned for 2010.02/03.
The default user interface in the current release is the GNU Network Object Model
Environment (GNOME) [gno] and the default file system is the Zettabyte File System
(ZFS).
3.1.2. The Zettabyte File System (ZFS)
The ZFS [ZFS] is a file system, developed by Sun. It is a great advance over the
existing file systems and provides more space for files, improved administration and
greatly improved data security and integrity. It is implemented as open-source software
and, as OpenSolaris, is distributed under the CDDL license. It provides very useful
features and here is a list of some of them:
1. Data integrity: All data in ZFS is protected by 256-bit checksums, which results
in huge error detection and correction rate. ZFS constantly monitors the data in
order to ensure its correctness and if an error occurs it is automatically repaired.
This feature eliminates the need of manual filesystem checks and greatly reduces
39
WS 2010/2011
System Security Lab
data loss, due to hardware or software failure. ZFS uses two sophisticated technologies to provide checksumming - copy-on-write and end-to-end checksumming.
With copy-on-write data is always written to a new block before changing the
pointers to the data and commiting the write.
2. Capacity: ZFS is a 128-bit file system so it could handle huge storage capacity
for files (2128 Bytes = 340 quadrillion zettabytes), providing many times greater
capacity as the now known 32- and 64-bit operating systems (resp. 232 and 264
Bytes).
3. High performance: ZFS increases the performance of the write operations by
using new block algorithms, which perform the write into a single, more efficient
operation, instead of many small random writes.
4. Snapshots: ZFS support snapshots. A snapshot is an image of the file system
at a given time. For example, if an important file is deleted, or several settings
have been changed, which resulted in a system crash, one can always revert to the
most recent snapshot and continue working as normal. Snapshots are created very
quickly, since all the data to be included in the snapshot is already written on the
disk.
5. Zones: Solaris Zones provide an operating system-level virtualization1 . Zones in
Solaris are completely isolated from each another, with the separation managed by
the kernel. The idea is that processes from inside the zone cannot affect processes
outside. If a process or a service in a zone is compromised, the security flaw will
not leave the zone but will be visible to the administrator, without putting the
other zones at risk. Compared to VirtualBox for example, you don’t need two
guest operating systems to isolate two programs, which is a serious performance
improvement. As a drawback, you cannot choose the operating systems but only
use Solaris. The default zone (the original instance of OpenSolaris) is the “global”
zone. It runs system-wide processes and is aware of all devices and all zones
installed on the system. You can use the global zone to administer the further
zones (non-global zones).
In exercise 2 you were introduced to DAC in Linux and Windows. In this exercise you
will get familiar with the implementation of DAC in OpenSolaris with the ZFS file
system.
In contrast to Linux, where we have the traditional read/write/execute right for ACL
entries, and similar to Windows, in OpenSolaris we have many more different permissions
(e.g. append, read acl, etc.). For a full list refer to Table 3.1. In Linux ACLs are
configured and viewed with the commands setfacl and getfacl - for example the
1
For more information about virtualization see the Operating System Security lecture slides available
at http://www.ei.rub.de/studium/lehrveranstaltungen/232/
40
WS 2010/2011
System Security Lab
command setfacl -m user:user2:w file.txt adds an ACL entry to the file file.txt,
which gives write permission to user2. Further with getfacl file.txt we can print
the ACL information for the file. In OpenSolaris setfacl and getfacl are no longer
required - you can use chmod A to set ACL and ls -v to display “verbose” information,
including ACLs, instead.
Each file has 6 default ACL entries - “allow” and “deny” for owner, group and everyone.
With ls -v file, we can display ACL information. One sample output looks like the
following:
1 n a s k a t a @ o p e n s o l a r i s : ˜ $ / u s r / b i n / l s −v s e c r e t . t x t
2 −rw−r−−r−−
1 naskata s t a f f
0 Dec 21 2 1 : 2 3 s e c r e t . t x t
3
0 : owner@ : e x e c u t e : deny
4
1 : owner@ : r e a d d a t a / w r i t e d a t a / append data / w r i t e x a t t r /y
w r i t e a t t r i b u t e s / w r i t e a c l / write owner : allow
5
2 : group@ : w r i t e d a t a / append data / e x e c u t e : deny
6
3 : group@ : r e a d d a t a : a l l o w
7
4 : everyone@ : w r i t e d a t a / append data / w r i t e x a t t r / e x e c u t e /y
w r i t e a t t r i b u t e s / w r i t e a c l / w r i t e o w n e r : deny
8
5 : everyone@ : r e a d d a t a / r e a d x a t t r / r e a d a t t r i b u t e s / r e a d a c l /y
synchronize : allow
Attribute
read data
write data
list directory
add file
append data
add subdirectory
read xattr
write xattr
execute
delete child
read attributes
write attributes
delete
read acl
write acl
write owner
synchronize
Description
Read the contents of a file
Modify an existing file
List the contents of a directory
Add a new file to a directory
Modify an existing file, but only from EOF
Create subdirectories
Read extended attributes
Write extended attributes
Execute a file
Delete a file within a directory
Read basic attributes (non-ACL) of a file
Write basic attributes to a file or directory
Delete a file
Read the ACL
Modify the ACL (needed to use chmod or setfacl)
Use chown to change ownership of a file
Access file locally via synchronous reads and writes
Table 3.1.: Access Contol Permissions in OpenSolaris
The syntax for the chmod A command is the following2 :
owner@:<perms > [ : i n h e r i t a n c e f l a g s ]: < a l l o w | deny>
group@:<perms > [ : i n h e r i t a n c e f l a g s ]: < a l l o w | deny>
1
2
2
man -s 5 acl
41
WS 2010/2011
System Security Lab
everyone@ :<perms > [ : i n h e r i t a n c e f l a g s ]: < a l l o w | deny>
u s e r :< username > [ : i n h e r i t a n c e f l a g s ]: < a l l o w | deny>
group :<groupname > [ : i n h e r i t a n c e f l a g s ]: < a l l o w | deny>
3
4
5
Note that the owner, group and everyone, as seen with “ls -l” contain the @ character.
Multiple entries could be grouped together, separated by commas. To demonstrate the
command we give special permissions for user2: chmod A+user:user2:read data/write data/
read attributes:allow,user:user2:delete:deny secret.txt. The output after that
looks like this:
1 n a s k a t a @ o p e n s o l a r i s : ˜ $ / u s r / b i n / l s −v s e c r e t . t x t
2 −rw−r−−r−−+ 1 n a s k a t a s t a f f
0 Dec 21 2 1 : 2 3 s e c r e t . t x t
3
0: user : user2 : read data / write data / read attributes : allow
4
1 : u s e r : u s e r 2 : d e l e t e : deny
5
...
Removing the above ACL entry, or only some of the attributes is done with the same
command with a minus sign (chmod A−...) instead of plus (chmod A+...).
3.1.4. Trusted Extensions for OpenSolaris
What are Trusted Extensions
The Trusted Extensions (TX) software provides special security features for the OpenSolaris system, such as Multi-Level Security, Labeling, etc. Organizations can make use
of these features to design and implement security policies for the system. A security
policy is a statement of what is allowed and what is not allowed in the system.
Multi-Level Security provided by TXs
The TX package enables Solaris to strictly separate parts of the system using zones and
labeled security. With this approach, Multi-Level Security (MLS) can be implemented
in Solaris. The separation is done by assigning each zone and its file systems a unique
security label, which are administered from a special protected global zone. The user can
interact with the global zone securely through a trusted path, without any other zones
interfering. A trusted path is a security mechanism that can convince the user that he is
communicating with what he intends to, while providing the assurance that adversaries
cannot eavesdrop the channel or modify the information that is being exchanged. Users
can log in via the trusted path and use one of the multilevel enabled desktop environments Common Desktop Environment (CDE)3 or GNOME (with Java Desktop System
(JDS)). Windows and workspaces are visibly labeled according to their execution environment. There should exist a different zone for each security label, which not only
guarantees the complete isolation, but also the confidentiallity of data, residing on these
zones. The labeling provides further obstacles for adversaries, as access is controlled by
the system (Mandatory Access Control), in addition to the normal Discretionary Access
Control (DAC).
3
CDE comes with commercial versions of Solaris, but is not available in OpenSolaris.
42
WS 2010/2011
System Security Lab
The Multi-Level Security approach in OpenSolaris is designed to protect the confidentiality of data, rather than the integrity. It can be compared to the Bell-LaPadula Model,
presented in the lecture, although differences exist.
A security label consists of a classification (level ) and compartments (categories). The
classification indicates a hierarchical level of security, representing the degree of trust,
when applied to subjects (e.g. users, processes) and the degree of protection, when
applied to objects (e.g. data). The compartments represent a grouping, such as department, project, etc. TX defines the following compartments: Restricted, Need to Know,
Internal Use Only and Public. Users are allowed to self define compartments as well.
In the context of OpenSolaris a security label looks like the following: Confidential:
Restricted, where the classification and the compartment are separated by semicolon.
There is at most one compartment in the security label.
Labels and Transactions
All security-related transactions are managed by the system. The system compares the
subject’s and the object’s labels and decides if a transaction is allowed, based on which
security label is dominant (see also lecture slides [lec]). In theory both the classification
and the compartment are compared to determine the dominance and the compartment
list is not ordered. In practice (OpenSolaris) they are also both compared, i.e. the
compartments are an ordered list with Restricted > Need to Know > Internal Use
Only > Public (see Table 3.2). A label that dominates another label is allowed access.
If the two labels are disjoint access is not permitted. For a read transaction, the subject’s
label must dominate the object’s one. This ensures that a subjects with lower level of
trust will not be allowed to read an object with higher level of trust (confidentiality
of data). Write transactions are only allowed in the corresponding zone, i.e. write is
not permitted from one zone to another. When you exchange information between files
with different labels, TX shows a confirmation dialog, waiting for authorization of the
information upgrade or downgrade.
Label1
Confidential:
Confidential:
Confidential:
Confidential:
Confidential:
Confidential:
Sandbox
Restricted
Restricted
Restricted
Need to Know
Need to Know
Internal
Relationship
dominates
dominates
dominates
dominates
dominates
dominates
is disjoint with
Label2
Confidential:
Confidential:
Public
Confidential:
Public
Public
All other labels
Need to Know
Internal Use Only
Internal Use Only
Table 3.2.: Examples of Label Relationships in OpenSolaris
Installing Trusted Extensions
Trusted Extension can be installed from the Packet Manager and can then be enabled
with the following comand: svcadm enable -s labeld. Installing Trusted Extensions
43
WS 2010/2011
System Security Lab
is one of the practical assignments in the lab. The labeld daemon is the TX’s label
daemon, which is available to processes that run in the global zone, as well as in labeled
zones. It starts at boot time.
Login via Trusted GUI
After the installation of TX the system needs to be rebooted in order to login in a TX
session. At the login menu, the Trusted Extensions session needs to be selected: Options
-> Select Session... -> Solaris Trusted Extensions (GNOME) -> Change Session ->
Make Default. After this selection, the system will boot into TX session each time. After
typing the user name and the password, the user can select if he wants to operate at
a single-level or a multi-level session, that’s why he needs to select a session clearance
or a session label. If a single-level session is selected, then the user can access files that
are equal to the session label or are dominated by the label. If a multi-level session is
selected, then the user has to select the highest label at which he is permitted to work,
also known as session clearance. The lowest label is also assigned (normally Public).
After logging in the user is able to change his label within the range. For example,
a user could be assigned Confidential: Restricted as the clearance. The initial
workspace label is Public and during the session, the user can create workspaces at
Confidential: Internal Use Only and Confidential: Need to Know. The user
can also have different workspaces at the same label. If the user selects single-level
session with the session label Confidential: Need To Know for example, then he can
only access objects with the Confidential: Need To Know label. In the screenshot
below you can see the different labeled workspaces in the bottom right corner (different
color means different label). The current workspace has the clearance Confidential:
Internal Use Only.
44
WS 2010/2011
System Security Lab
Trusted stripe
The trusted stripe appears in a reserved area at the top of the screen in all TX sessions
with GNOME/Trusted JDS. Its purpose is to give information and visual confirmation
about the legitimacy of the current TX session. It also displays the label of the current
workspace, the current user name and the trusted symbol. In the screenshot above one
can immediately see the trusted stripe in the reserved area at the top. It shows the
current label, the current user and that there exists a trusted path to the Terminal. One
can change the user and the label through the trusted stripe.
Trusted Extensions Zone Manager Configuration Utility
The Trusted Extensions Zone Manager Configuration Utility (txzonemgr) is a shell script
that provides a simple wizard for creating, installing, initializing and booting labeled
zones on TX-enabled systems. It provides a menu with appropriate choices. During
the first zone installation several packages and installation files need to be downloaded
and installed. With every further labeled zone creation, the administrator can clone the
already downloaded files and configure the zone much faster, which also saves bandwidth.
45
WS 2010/2011
System Security Lab
1. Summarize the multilevel security concept in OpenSolaris?
2. How can the copy-on-write algorithm be used to create snapshots?
3. Is the trusted stripe a security critical component? Justify your answer!
4. Why doesn’t ZFS have a fsck-like [fsc] utility?
5. (Optional, for 3 extra bonus points. Deadline: 24. January)
Prove the Basic Security Theorem of the Bell-LaPadula model! All neccessary
notations are explained in subsection 5.4 of the slides (266-275).
46
WS 2010/2011
System Security Lab
1. Start virtualbox and boot OpenSolaris. Login as user “labor” with password “labor”.
2. Create a file named testfile.
3. Modify the ACL such that user2 can append data and read the basic attributes,
but cannot read the ACL information. Verify your solution!
4. Change the default /var/log/syslog ACL permissions to deny the group and
everyone to read the file and allow user2 to read the file and delete it! Again, test
your solution!
3.3.2. Preparing OpenSolaris Trusted Extensions
1. Start the OpenSolaris Package Manager System->Administration->Package Manager and install the package trusted-extensions. This package provides utilities
and services needed to integrate security mechanisms like OpenSolaris zones and
Mandatory Access Control.
2. Enable the Trusted Extensions service labeld via the Service Management Framework. Open a terminal window (Applications->Accessories->Terminal and enter:
svcadm enable -s labeld
3. The system is now prepared to use Trusted Extensions including Mandatory Access
Control. To finish the setup, reboot the system.
3.3.3. Configuring OpenSolaris Trusted Extensions
1. Before you log in, change your session type to GNOME Trusted Extensions GUI.
Options->Select Session->Solaris Trusted Extensions (GNOME)
You can then use the labor account to log into the system.
2. Open a terminal window und start the txzonemgr. Create two new zones. The
first one should be labeled as PUBLIC, the second as CONFIDENTIAL : INTERNAL
USE ONLY.
Hints: Do not use white space in the names of your zones.
3. After booting the two new zones, you should change at least one of your workspace
labels to PUBLIC and another one to CONFIDENTIAL : INTERNAL USE ONLY.
47
WS 2010/2011
System Security Lab
3.3.4. Using OpenSolaris Trusted Extensions
1. Open a terminal window on your workspace labeled as public and enter some text.
Copy the text to a different terminal window on a workspace labeled as confidential. What did you expect and what did you discover? Explain it in context of
Multi Level Security with attention to Bell-LaPadula. Hints: To copy a text
on OpenSolaris, you can simply mark the area you want to copy, move
the cursor to your destination window and press the mouse wheel to
insert the text.
2. Now, write some text in a terminal window on a workspace labeled as confidential
and try to copy it to a window labeled as public. What did you expect and what
did you discover? Explain it in context of Multi Level Security with attention to
Bell-LaPadula.
3. Try to copy some text from the zone labeled as public into the global zone and
vice versa. Describe your results!
4. We now want to have a look at how separation and labeling is done in OpenSolaris.
• In a terminal window that is assigned to the Trusted Path, create a file named
trusted.test in your home directory. What label is associated with that file?
Use the command getlabel to view the associated label.
• In the same terminal window, create a file named public.test in your home directory of the public zone. Typically the directory has the form /zone/ZON EN AM E/
root/export/home/USERNAME. What label is assigned to that file?
• Use the command setlabel to change the label of public.test to “CONFIDENTIAL : INTERNAL USE ONLY”. Describe your results!
• Still in Trusted Path, create a file named confidential.test in your home directory of the confidential zone. What label is assigned to that file?
• Change the label of confidential.test to “PUBLIC” and describe your results!
48
References Mandatory Access Control
[CDD] Common development and distribution license.
http://opensource.org/licenses/cddl1.php.
[fsc]
fsck man page.
http://linux.die.net/man/8/fsc.
[gno]
Gnome website.
http://www.gnome.org/.
[lec]
System security 2 lecture slides.
http://www.ei.rub.de/studium/lehrveranstaltungen/265/.
[Ope] Opensolaris website.
[ZFS] The zfs filesystem.
http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome.
49
4. Exercise: Role Based Access Control
Duration: 90min
Contents
4.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3. Practical Assignments . . . . . . . . . . . . . . . . . . . . . . . . 54
.1.
Short Reference for the Applications . . . . . . . . . . . . . . . 56
Motivation and goals: In this practical exercise we a have a look
into SELinux. The main task will be to learn how to design SELinux
security policies and to activate them.
4.1. Scenario
A company usually has different administrators for different services. For economic
reasons, two services, webhosting and mail, reside on the same server. Nevertheless,
there are two different Administrators, one for its mailserver and one for webhosting,
which, by the companys security policy, should not be able to interfere with each other
as the “separation of duty” principle shall be implemented. Thus, there should exist a
mandantory policy that ensures proper separation.
The Chief Security Officer of the company decided to use SELinux, which provides
RBAC. Your job is, to implement an appropriate policy on the system. Luckily, the
major work is already done:
4.1.1. Applications
Beside standard applications available for all users and already covered by the base
policy, the company decided to use the exim-mailserver and the boa-webserver(Note,
that this is for simplicity, there is probably better server software.). Normal users should
be able to send/receive mail using the mutt-mailclient.
4.1.2. Roles
The following roles have been defined:
user r: standard unprivileged user role
51
WS 2010/2011
System Security Lab
staff r: standard (unprivileged) role for every admin (is allowed to change to adm-roles)
webadm r: Administrators of the web server
mailadm r: Administrators of the mail server
4.1.3. Domains/Types
To achieve the desired security-goal, the following domains respectively types have been
identified and defined:
staff t: the unprivileged domain of administrator’s roles
user t: standard domain of the user r role
mailadm t: standard domain of the mailadm r role and type of the running mailserver
webadm t: standard domain of the webadm r role and type of the running webserver
var run t: type of files in the /var/run directory
node t: standard type of a network node
etc exim t: type of the configuration files of the exim mailserver
log exim t: type of the log files of exim
var spool t: type of files in /var/spool
mail spool t: type of files in /var/spool/mail
smtp port t: type of tcp sourceports needed for smtp
etc boa t: type of configuration files of boa
log boa t: type of log files of boa
var www t: type of files in /var/www
http port t: type of sourceports needed for http (and https)
4.1.4. Permissions
While testing, you identified the permissions associated with the roles and types:
staff r: must be allowed to change into the mailadm r and the webadm r roles
user t and staff t: must be able to write, remove name and add name on directories as
well as create, unlink and link on files of type mail spool t in order to send
and receive their mail.
52
WS 2010/2011
System Security Lab
webadm t: must be able to kill his own processes and bind to the http socket, therefore
it requires the kill and net bind service linux capabilities on self as well as
the name bind permission on tcp sockets of type http port t and the node bind
permission on tcp sockets of type node t.
In order to access and edit the configuration of the webserver, the webadm t domain
must be allowed to use the search, read, create, write, getattr, rmdir, open
add name and remove name permissions on the directories and the write, setattr,
getattr, create, unlink, open, append, rename and read permissions on the files
of type etc boa t.
Furthermore, both, the admin and the webserver program must be able to access
the content itself, so it needs search, getattr, read and open permissions on the
directories and getattr, read and open permissions on the files of type var www t.
Since it is very likely, that some new content has to be added, or old content has to
be removed, the admin should also be able to create and delete files and directories
of type var www t. To accomplish this, he needs write, remove name, add name,
create, rmdir permissions on directories of this type and write, create, unlink,
append permissions on the files.
Last but not least, the webserver must, of course, be able to write logfiles, as well
as the web administrator must be able to read those. Thus, write, search, read,
open, setattr, getattr and add name permissions on the directory and read,
getattr, setattr, create, open and append on the files of type log boa t must
be permitted.
mailadm t: must be able to kill its own processes. It must also be allowed to bind to
the smtp port, which is of type smtp port t. To start exim, it is also necessary to
have the setuid linux capability.
A mailadmin is able to change the configuration of the server and therefor needs
access to the config files. The configuration directory and the files are of type
etc exim t.
Furthermore it must be able to read (and create) the logfiles, which are of type
log exim t.
The mailserver must be able to write its own Process ID file in /var/run, therefor
it needs open, write, getattr and setattr permissions on files of type var run t.
Finally, the mailserver and the mailadmin must be able to access exims spool since
this is the place, where the mail is prepared for sending and receiving. In order
to do their work, they need write, remove name and add name on directories and
write, create, unlink, append and setattr on files of type var spool t.
Don’t forget, that the admins must also be able to send and receive mail.
53
WS 2010/2011
System Security Lab
4.2.1. Prepare a SELinux Policy (max. 25 Points)
Please prepare the theoretical assignments at home. You have to hand in your answers
at the beginning of each practical assignment!
Tasks:
1. Create an SELinux policy for the described scenario!
Note, that it must be a complete .te file, which can be compiled without errors.
The .fc and .if files are not needed.
Start the SELinux virtual machine in Virtualbox. Make sure you boot the first entry in
the boot menu (Gentoo SELinux).
4.3.1. Implement the Policy (max. 25 Points)
A working policy module (should be homomorph to that one you created as homework)
has been prepared and is located at /exercisefiles/extra-policy/sysi2. A makefile
can also be found there. Furthermore, the company has the following users: alice, bob,
claudia, donald, eko, fritz, gunter, heinz, ida, and jin which all have a linux user account
on the system. There exist the groups mail and www, which the respective admin should
be a member of.
For the sake of simplicity, the passwords are all set to “0”. Changing to another role
can be done with the command newrole -r <target role>. Note that root has also
access to different roles, namely staff r and sysadm r.
Tasks:
1. Alice is the designated webadm, bob the mailadm. Create a corresponding SELinux
user for every linux user and map them properly!
2. Assign the roles to the users! Keep in mind that user r is not allowed to change
into other roles.
3. Load the policy!
4. Test if the following things work!
• users can send and receive mail
• mailadmins can read and edit the config in /etc/exim
• mailadmins can read and edit the mailspool in /var/spool/mail
54
WS 2010/2011
System Security Lab
• mailadmins can read the eximspool in /var/spool/exim
• mailadmins can read the logfiles in /var/log/exim
• webadmins can read and edit the config in /etc/boa
• webadmins can read and edit web content in /var/www
• webadmins can read the logfiles in /var/log/boa
5. Claudia should assist Alice in administrating the webserver. She must therefor get
access. Make the necessary changes and confirm that they work as expected!
6. Eko is most experienced in server administration and should be able to assist both,
the mailadmins and the webadmin. Assign him the appropriate permissions!
7. Test, if the new admins can do their job as expected!
55
WS 2010/2011
System Security Lab
.1. Short Reference for the Applications
.1.1. mutt
start up mutt by typing mutt in the command prompt. You can send a new mail by
typing m, then write your text, exit the editor and then type y to send the mail. To abort
sending mails, use q. To exit mutt, use also q in mutts main window. If you accidently
started any command, you can abort it by typing ctrl-g.
.1.2. boa
• start up boa – boa -c /etc/boa
.1.3. exim
• start up exim – exim -bd
• list unsent mail waiting in exims queue – mailq
• delete all unsent mail from exims queue – exim -Mrm $(mailq|exiqgrep -i)
.1.4. Other Useful Commands
• kill a program – killall progname
• add a user to a group – usermod -aG users bob
• list all linux users – getent passwd
• list all groups – getent group
• create a file – touch foo
• write to a file – echo blah > foo
• append to a file – echo blub >> foo
56
References
[aud]
Homepage of the auditd daemon.
http://people.redhat.com/sgrubb/audit/.
[bye]
Selinux by example, book by three authors that are quite involved in the development of selinux, not free.
http://www.selinuxbyexample.com/.
[CDD] Common development and distribution license.
http://opensource.org/licenses/cddl1.php.
[fsc]
fsck man page.
http://linux.die.net/man/8/fsc.
[gen]
Gentoo selinux handbook.
http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.
xml.
[gno]
Gnome website.
http://www.gnome.org/.
[hpf]
homepage of flask.
http://www.cs.utah.edu/flux/fluke/html/flask.html.
[lec]
System security 2 lecture slides.
http://www.ei.rub.de/studium/lehrveranstaltungen/265/.
[lsm]
Lsm design.
http://www.usenix.org/event/sec02/wright.html.
[man]
Linux man pages.
http://linuxmanpages.com/.
[Mic]
Microsoft. icacls.exe description.
http://technet.microsoft.com/en-us/library/cc753525%28WS.10%29.
aspx.
[obj]
list of object classes and permissions.
http://oss.tresys.com/projects/refpolicy/wiki/ObjectClassesPerms.
[Opea] Openbsd.
http://www.openbsd.org/.
57
WS 2010/2011
System Security Lab
[Opeb] Opensolaris.
[Opec] Opensolaris website.
[Ora]
Oracle. Virtualbox user manual.
http://download.virtualbox.org/virtualbox/3.2.10/UserManual.pdf.
[refa]
interface documentation of the reference policy.
http://oss.tresys.com/docs/refpolicy/api/.
[refb]
reference policy from tresys.
http://oss.tresys.com/projects/refpolicy.
[Snaa] Snare.
http://www.intersectalliance.com/projects/SnareWindows/.
[Snab] Snare documentation.
http://www.intersectalliance.com/resources/Documentation/Guide_to_
Snare_for_Windows-2.8.pdf.
[swa]
swatch.
http://sourceforge.net/projects/swatch/.
[sysa]
syslog-ng.
http://www.balabit.com/network-security/syslog-ng/
opensource-logging-system/.
[sysb]
syslog-ng documentation.
http://www.balabit.com/dl/guides/syslog-ng-v3.0-guide-admin-en.
pdf.
[tea]
statement of assurance regarding type enforcement from secure computing.
http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf.
[Wika] Wikipedia. Linux.
http://en.wikipedia.org/wiki/Linux.
[Wikb] Wikipedia. Windows.
http://de.wikipedia.org/wiki/Microsoft_Windows.
[ZFS]
The zfs filesystem.
http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome.
58
A. Appendix: Python Language
Contents
A.1. Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . 59
A.2. Syscalls
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Abstract: The following information is not mandatory for the assignment. It is meant as background knowledge, if you are interested in
one particular detail or have difficulties understand the things above.
Many of the details included in the appendix are not comprehensible
given only the information given in the lecture and in the introducion.
A.1. Regular Expressions
Log files usually contain large amounts of plain text. You will most often only need
parts of such a file. Extraction of relevant parts from a text is normally done with the
help of “regular expressions”(regex). A regular expression is a generic pattern, which
describes the format of a text string.
Classic unix tools, which support regular expressions are for instance grep and sed.
The perl scripting language is well known for it’s great support of regular expressions
and is probably the best way to go when dealing with text. To spare you learning another
scripting language, we will use Python’s implementation of regular expression.
Since regular expressions can get very complex very fast, this subsection tries to give
a good overview of the basics.
General Syntax of a Regular Expression
Regular expressions consist of a set of literals and control strings for quantification,
alternation or grouping. Literals are in general case sensitive. (Though most tools
provide an option to change this behaviour.)
Literals
Characters and digits are simple literals. This means, an a matches on an a and b
matches on a b. Most special characters are not. They must be escaped by the \
(backslash) character. A \ must also be escaped by a \, thus matching a single \ would
be \\. Example: c:\\Windows\\System would match on c:\Windows\System
59
WS 2010/2011
System Security Lab
Sets of Literals can also be matched. This can be done by enclosing multiple literals
in square brackets. Example: [abcd]x matches on ax or bx or cx or dx. You can also
give ranges like [a-z] or [0-9].
Special Literals
. matches any character
ˆ matches the beginning of a line
$ matches the end of a line
[ˆa] matches on not a, where a is replaceable by any other character
\t matches the TAB-character
\n matches a newline (be careful with newlines, as this can get confusing with multilinematches or other weird options that are often implemented)
Examples:
• ^$ matches an empty line.
• ^.$ matches on a line that contains exactly one character.
• ^foobar matches any line that starts with the word foobar.
Quantifier
Often it is useful to match more than one occurrence of a (set of) literal(s). In this
case, you must specify how often the literal may/must appear. This can be done by the
following quantifiers:
? matches on zero or one occurrences
* matches on zero or more occurrences
+ matches on one or more occurrences
{m,n} matches on at least m up to n occurrences. You can omit either m or n. If you
omit m, this means zero to n occurrences, if you omit n, this means at least m
occurrences.
Examples:
• .* matches on anything including the empty string (‘‘’’)
• .+ matches on anything but the empty string
• {,5} matches up to 5 spaces.
60
WS 2010/2011
System Security Lab
Grouping
Sometimes it is useful to group a regular expression into sub regular expressions. This
is done by parenthesis. In most tools, you can access these groups directly.
Alternation
In some cases, you need alternative words that cannot be achieved by matching a set of
literals (for example if you want to allow two different words). In this case, you need
alternation. Alternation is done by the | character. This usually appears in combination
with grouping.
Example: the this is a (test|task) matches on this is a test as well as on
this is a task.
Greedy and Non Greedy Matching
By default, a regular expression matches greedy. This means, if you have a string ‘‘this
is a string that is some string’’ and you try to match with the regular expression
th.*is, you will match ‘‘this is a string that is’’. If this behaviour is unwanted,
it can be changed by appending a question mark after the quantifier. Thus, th.*?is is
the non greedy regular expression and will only match this from the string above. Note
that the question mark is also a quantifier and this is easily mixed up.
Backreferences
Sometimes you need to match a string that contains the same pattern more than once.
Let’s say you want to match HTML-tags. This is no problem, if you know exactly what
tag to match. You could, for example, match a DIV-section with <div.*?>.+?</div>. If
you want to match DIV and SPAN tags, you might want to use <(div|span).*?>.+?</(div|span)>.
The problem is, that this would not work with DIV and SPAN nested. The solution
is to use a backreference. If you use the ()-pair somewhere in your pattern, the match
between the brackets is saved. It can later on be recalled with \1 . . . \9. So a better
regular expression for HTML-tags would look like <(div|span).*?>.+?</\1>.
A.2. Syscalls
This is the (complete) documentation of selected syscalls for the linux operating system.
Since it is real world documentation, it is quite not easy to understand.
A.2.1. fork - create a child process
description: fork creates a new process by duplicating the calling process. The new
process, referred to as the child, is an exact duplicate of the calling process, referred to
as the parent, except for the following points:
61
WS 2010/2011
System Security Lab
• The child has its own unique process ID, and this PID does not match the ID of
any existing process group (see man setpgid).
• The child’s parent process ID is the same as the parent’s process ID.
• The child does not inherit its parent’s memory locks (mlock, mlockall).
• Process resource utilizations (getrusage) and CPU time counters (times) are reset
to zero in the child.
• The child’s set of pending signals is initially empty
• The child does not inherit semaphore adjustments from its parent
• The child does not inherit record locks from its parent
• The child does not inherit timers from its parent
• The child does not inherit outstanding asynchronous I/O operations from its parent
The process attributes in the preceding list are all specified in POSIX.1-2001. The
parent and child also differ with respect to the following Linux-specific process attributes:
• The child does not inherit directory change notifications (dnotify) from its parent
(see the description of F NOTIFY in the man-page of fcntl).
• The prctl PR SET PDEATHSIG setting is reset so that the child does not receive a
signal when its parent terminates.
• Memory mappings that have been marked with the madvise MADV DONTFORK flag
are not inherited across a fork.
• The termination signal of the child is always SIGCHLD (see the manpage of clone).
Note the following further points:
• The child process is created with a single thread – the one that called fork.
The entire virtual address space of the parent is replicated in the child, including the states of mutexes, condition variables, and other pthreads objects; the use
of pthread atfork may be helpful for dealing with problems that this can cause.
• The child inherits copies of the parent’s set of open file descriptors. Each file
descriptor in the child refers to the same open file description (see man open) as
the corresponding file descriptor in the parent. This means that the two descriptors
share open file status flags, current file offset, and signal-driven I/O attributes (see
the description of F SETOWN and F SETSIG in man fcntl).
• The child inherits copies of the parent’s set of open message queue descriptors (see
man mq overview). Each descriptor in the child refers to the same open message
queue description as the corresponding descriptor in the parent. This means that
the two descriptors share the same flags (mq flags).
62
WS 2010/2011
System Security Lab
• The child inherits copies of the parent’s set of open directory streams (see man
opendir). POSIX.1-2001 says that the corresponding directory streams in the
parent and child may share the directory stream positioning; on Linux/glibc they
do not.
return value: On success, the PID of the child process is returned in the parent, and
0 is returned in the child. On failure, -1 is returned in the parent, no child process is
created, and errno is set appropriately.
errors:
EAGAIN fork cannot allocate sufficient memory to copy the parent’s page tables and
allocate a task structure for the child.
EAGAIN It was not possible to create a new process because the caller’s RLIMIT NPROC
resource limit was encountered. To exceed this limit, the process must have either
the CAP SYS ADMIN or the CAP SYS RESOURCE capability.
ENOMEM fork failed to allocate the necessary kernel structures because memory is
tight.
conforming to:
SVr4, 4.3BSD, POSIX.1-2001.
notes: Under Linux, fork is implemented using copy-on-write pages, so the only penalty
that it incurs is the time and memory required to duplicate the parent’s page tables,
and to create a unique task structure for the child.
Since version 2.3.3, rather than invoking the kernel’s fork system call, the glibc fork
wrapper that is provided as part of the NPTL threading implementation invokes clone
with flags that provide the same effect as the traditional system call. The glibc wrapper
invokes any fork handlers that have been established using pthread atfork.
A.2.2. exit - terminate the calling process
description: The function exit terminates the calling process ”immediately”. Any
open file descriptors belonging to the process are closed; any children of the process are
inherited by process 1, init, and the process’s parent is sent a SIGCHLD signal.
The value status is returned to the parent process as the process’s exit status, and
can be collected using one of the wait family of calls.
return value: This function does not return.
conforming to:
SVr4, POSIX.1-2001, 4.3BSD.
63
WS 2010/2011
System Security Lab
notes: For a discussion on the effects of an exit, the transmission of exit status, zombie
processes, signals sent, etc., see the manpage of exit.
The function exit is like exit, but does not call any functions registered with atexit
or on exit. Whether it flushes standard I/O buffers and removes temporary files created
with tmpfile is implementation-dependent. On the other hand, exit does close open
file descriptors, and this may cause an unknown delay, waiting for pending output to
finish. If the delay is undesired, it may be useful to call functions like tcflush before
calling exit. Whether any pending I/O is canceled, and which pending I/O may be
canceled upon exit() is implementation-dependent.
A.2.3. wait, waitpid, waitid - wait for process to change state
description:
All of these system calls are used to wait for state changes in a child of
the calling process, and obtain information about the child whose state has changed. A
state change is considered to be: the child terminated; the child was stopped by a signal;
or the child was resumed by a signal. In the case of a terminated child, performing a
wait allows the system to release the resources associated with the child; if a wait is not
performed, then the terminated child remains in a “zombie” state (see NOTES below).
If a child has already changed state, then these calls return immediately. Otherwise
they block until either a child changes state or a signal handler interrupts the call (assuming that system calls are not automatically restarted using the SA RESTART flag of
sigaction). In the remainder of this page, a child whose state has changed and which
has not yet been waited upon by one of these system calls is termed waitable.
wait and waitpid The wait system call suspends execution of the calling process until
one of its children terminates. The call wait(&status); is equivalent to:
1 w a i t p i d ( −1 , &s t a t u s , 0 ) ;
The waitpid system call suspends execution of the calling process until a child specified by pid argument has changed state. By default, waitpid waits only for terminated
children, but this behavior is modifiable via the options argument, as described below.
The value of pid can be:
< -1 meaning wait for any child process whose process group ID is equal to the absolute
value of pid.
64
WS 2010/2011
System Security Lab
-1 meaning wait for any child process.
0 meaning wait for any child process whose process group ID is equal to that of the
calling process.
> 0 meaning wait for the child whose process ID is equal to the value of pid.
The value of options is an OR of zero or more of the following constants:
WNOHANG return immediately if no child has exited.
WUNTRACED also return if a child has stopped (but not traced via ptrace). Status for
traced children which have stopped is provided even if this option is not specified.
WCONTINUED (since Linux 2.6.10) also return if a stopped child has been resumed
by delivery of SIGCONT.
(For Linux-only options, see below.)
The WUNTRACED and WCONTINUED options are only effective if the SA NOCLDSTOP flag
has not been set for the SIGCHLD signal (see sigaction).
If status is not NULL, wait and waitpid store status information in the int to which it
points. This integer can be inspected with the following macros (which take the integer
itself as an argument, not a pointer to it, as is done in wait and waitpid!):
WIFEXITED(status) returns true if the child terminated normally, that is, by calling
exit or exit, or by returning from main().
WEXITSTATUS(status) returns the exit status of the child. This consists of the least
significant 8 bits of the status argument that the child specified in a call to exit
or exit or as the argument for a return statement in main(). This macro should
only be employed if WIFEXITED returned true.
WIFSIGNALED(status) returns true if the child process was terminated by a signal.
WTERMSIG(status) returns the number of the signal that caused the child process to
terminate. This macro should only be employed if WIFSIGNALED returned true.
WCOREDUMP(status) returns true if the child produced a core dump. This macro
should only be employed if WIFSIGNALED returned true. This macro is not specified
in POSIX.1-2001 and is not available on some Unix implementations (e.g., AIX,
SunOS). Only use this enclosed in #ifdef WCOREDUMP ... #endif.
WIFSTOPPED(status) returns true if the child process was stopped by delivery of a
signal; this is only possible if the call was done using WUNTRACED or when the child
is being traced (see manpage of ptrace).
65
WS 2010/2011
System Security Lab
WSTOPSIG(status) returns the number of the signal which caused the child to stop.
This macro should only be employed if WIFSTOPPED returned true.
WIFCONTINUED(status) (since Linux 2.6.10) returns true if the child process was
resumed by delivery of SIGCONT.
The waitid() system call (available since Linux 2.6.9) provides more precise control over
which child state changes to wait for.
The idtype and id arguments select the child(ren) to wait for, as follows:
idtype == P PID Wait for the child whose process ID matches id.
idtype == P PGID Wait for any child whose process group ID matches id.
idtype == P ALL Wait for any child; id is ignored.
The child state changes to wait for are specified by ORing one or more of the following
flags in options:
WEXITED Wait for children that have terminated.
WSTOPPED Wait for children that have been stopped by delivery of a signal.
WCONTINUED Wait for (previously stopped) children that have been resumed by
delivery of SIGCONT.
The following flags may additionally be ORed in options:
WNOHANG As for waitpid.
WNOWAIT Leave the child in a waitable state; a later wait call can be used to again
retrieve the child status information.
Upon successful return, waitid fills in the following fields of the siginfo t structure
pointed to by infop:
si pid The process ID of the child.
si uid The real user ID of the child. (This field is not set on most other implementations.)
si signo Always set to SIGCHLD.
si status Either the exit status of the child, as given to exit (or exit), or the signal
that caused the child to terminate, stop, or continue. The si code field can be
used to determine how to interpret this field.
si code Set to one of: CLD EXITED (child called exit); CLD KILLED (child killed by
signal); CLD STOPPED (child stopped by signal); or CLD CONTINUED (child continued
by SIGCONT).
66
WS 2010/2011
System Security Lab
If WNOHANG was specified in options and there were no children in a waitable state, then
waitid returns 0 immediately and the state of the siginfo t structure pointed to by
infop is unspecified. To distinguish this case from that where a child was in a waitable
state, zero out the si pid field before the call and check for a non-zero value in this field
after the call returns.
return value:
wait on success, returns the process ID of the terminated child; on error, -1 is returned.
waitpid on success, returns the process ID of the child whose state has changed; if
WNOHANG was specified and one or more child(ren) specified by pid exist, but have
not yet changed state, then 0 is returned. On error, -1 is returned.
waitid returns 0 on success or if WNOHANG was specified and no child(ren) specified by id
has yet changed state; on error, -1 is returned.
Each of these calls sets errno to an appropriate value in the case of an error.
errors:
ECHILD (for wait) The calling process does not have any unwaited-for children.
ECHILD (for waitpid or waitid) The process specified by pid (waitpid) or idtype and
id (waitid) does not exist or is not a child of the calling process. (This can happen
for one’s own child if the action for SIGCHLD is set to SIG IGN. See also the Linux
Notes section about threads.)
EINTR WNOHANG was not set and an unblocked signal or a SIGCHLD was caught.
EINVAL The options argument was invalid.
conforming to: SVr4, 4.3BSD, POSIX.1-2001.
notes: A child that terminates, but has not been waited for becomes a “zombie”. The
kernel maintains a minimal set of information about the zombie process (PID, termination status, resource usage information) in order to allow the parent to later perform a
wait to obtain information about the child. As long as a zombie is not removed from
the system via a wait, it will consume a slot in the kernel process table, and if this table
fills, it will not be possible to create further processes. If a parent process terminates,
then its “zombie” children (if any) are adopted by init, which automatically performs
a wait to remove the zombies.
POSIX.1-2001 specifies that if the disposition of SIGCHLD is set to SIG IGN or the
SA NOCLDWAIT flag is set for SIGCHLD (see manpage of sigaction), then children that
67
WS 2010/2011
System Security Lab
terminate do not become zombies and a call to wait or waitpid will block until all
children have terminated, and then fail with errno set to ECHILD. (The original POSIX
standard left the behavior of setting SIGCHLD to SIG IGN unspecified. Note that even
though the default disposition of SIGCHLD is ”ignore”, explicitly setting the disposition
to SIG IGN results in different treatment of zombie process children.) Linux 2.6 conforms
to this specification. However, Linux 2.4 (and earlier) does not: if a wait or waitpid
call is made while SIGCHLD is being ignored, the call behaves just as though SIGCHLD
were not being ignored, that is, the call blocks until the next child terminates and then
returns the process ID and status of that child.
linux notes: In the Linux kernel, a kernel-scheduled thread is not a distinct construct
from a process. Instead, a thread is simply a process that is created using the Linuxunique clone system call; other routines such as the portable pthread create call are
implemented using clone. Before Linux 2.4, a thread was just a special case of a process,
and as a consequence one thread could not wait on the children of another thread, even
when the latter belongs to the same thread group. However, POSIX prescribes such
functionality, and since Linux 2.4 a thread can, and by default will, wait on children of
other threads in the same thread group.
The following Linux-specific options are for use with children created using clone;
they cannot be used with waitid:
WCLONE Wait for “clone” children only. If omitted then wait for “non-clone” children only. (A ”clone” child is one which delivers no signal, or a signal other than
SIGCHLD to its parent upon termination.) This option is ignored if WALL is
also specified.
WALL (since Linux 2.4) Wait for all children, regardless of type (“clone” or “nonclone”).
WNOTHREAD (since Linux 2.4) Do not wait for children of other threads in the
same thread group. This was the default before Linux 2.4.
example: The following program demonstrates the use of fork and waitpid. The program creates a child process. If no command-line argument is supplied to the program,
then the child suspends its execution using pause, to allow the user to send signals
to the child. Otherwise, if a command-line argument is supplied, then the child exits
immediately, using the integer supplied on the command line as the exit status. The
parent process executes a loop that monitors the child using waitpid, and uses the W*()
macros described above to analyze the wait status value.
The following shell session demonstrates the use of the program:
68
WS 2010/2011
System Security Lab
1
2
3
4
5
6
7
8
9
10
11
$ . / a . out &
C h i l d PID i s 32360
[ 1 ] 32359
$ k i l l −STOP 32360
s t op p ed by s i g n a l 19
$ k i l l −CONT 32360
continued
$ k i l l −TERM 32360
k i l l e d by s i g n a l 15
[ 1 ] + Done
$
. / a . out
1 #include <s y s / w a i t . h>
2 #include < s t d l i b . h>
3 #include <u n i s t d . h>
4 #include <s t d i o . h>
5
6 int main ( int argc , char ∗ argv [ ] )
7 {
8
p i d t cpid , w ;
9
int s t a t u s ;
10
11
cpid = fork () ;
12
i f ( c p i d == −1) {
13
perror (” fork ”) ;
14
e x i t (EXIT FAILURE) ;
15
}
16
17
i f ( c p i d == 0 ) {
/∗ Code e x e c u t e d by c h i l d ∗/
18
p r i n t f ( ” C h i l d PID i s %l d \n” , ( long ) g e t p i d ( ) ) ;
19
i f ( a r g c == 1 )
20
pause ( ) ;
/∗ Wait f o r s i g n a l s ∗/
21
e x i t ( a t o i ( argv [ 1 ] ) ) ;
22
} else {
/∗ Code e x e c u t e d by p a r e n t ∗/
23
do {
24
w = w a i t p i d ( cpid , &s t a t u s , WUNTRACED | WCONTINUED) ;
25
i f (w == −1) {
26
perror ( ” waitpid ” ) ;
27
e x i t (EXIT FAILURE) ;
28
}
29
30
i f (WIFEXITED( s t a t u s ) ) {
31
p r i n t f ( ” e x i t e d , s t a t u s=%d\n” , WEXITSTATUS( s t a t u s ) ) ;
69
WS 2010/2011
System Security Lab
32
33
34
35
36
37
38
39
40
41
42 }
} e l s e i f (WIFSIGNALED( s t a t u s ) ) {
p r i n t f ( ” k i l l e d by s i g n a l %d\n” , WTERMSIG( s t a t u s ) ) ;
} e l s e i f (WIFSTOPPED( s t a t u s ) ) {
p r i n t f ( ” s t o p p e d by s i g n a l %d\n” , WSTOPSIG( s t a t u s ) ) ;
} e l s e i f (WIFCONTINUED( s t a t u s ) ) {
p r i n t f ( ” c o n t i n u e d \n” ) ;
}
} while ( ! WIFEXITED( s t a t u s ) && ! WIFSIGNALED( s t a t u s ) ) ;
e x i t (EXIT SUCCESS) ;
}
A.2.4. getpid, getppid - get process identification
description: getpid returns the process ID of the calling process. (This is often used
by routines that generate unique temporary filenames.)
getppid returns the process ID of the parent of the calling process.
errors: These functions are always successful.
confirming to: POSIX.1-2001, 4.3BSD, SVr4
70
B. Appendix: SELinux Introduction
Contents
B.1.
B.2.
B.3.
B.4.
B.5.
B.6.
Introduction . .
SELinux Terms .
How it Works . .
The Policy . . . .
Basic Commands
Usage Examples
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
71
73
78
87
99
100
Abstract: This introduction was designed to help doing research work
on SELinux. Otherwise it would take weeks to search and read the
necessary documentation, if you haven’t worked with SELinux before.
This document is far from complete and only touches some subject
areas of SELinux. It will try to explain the most important aspects
needed to know when working the first time with SELinux. Although
some examples might be a bit superficial, they are still correct.
Some examples in this document are taken from the book SELinux by
Example [bye], which is, in my opinion, the best printed book available
on SELinux. Although it is not bleeding edge, it covers many aspects
of SELinux. It covers even a bit of the architecture, which the other
books only touch marginally.
There is no part about installing a new SELinux system or converting a
traditional system to SELinux in this document. Although this might
be important, I think it doesn’t help much in understanding SELinux.
If you need help on setting up an SELinux system, refer to the documentation of your linux distribution. The Gentoo SELinux Handbook
gives a nice tutorial on how to convert a system. [gen]
Also not covered here, but definitely an interesting topic is the interaction of SELinux and Xorg.
B.1. Introduction
In 2000 the NSA released SELinux to the open source community. At this time it was
a bunch of kernel patches that implemented the FLASK 1 architecture. FLASK [hpf] is
an operating system architecture that was originally implemented in the Fluke operating
1
Flux Advanced Security Kernel
71
WS 2010/2011
System Security Lab
system and demonstrates mandatory access control. Fluke is a research operating system
developed by the Flux Research Group at Utah University.
To make SELinux part of the official Linux kernel some effort had to be made first.
The chief maintainer of the linux kernel, Linus Torvalds, told that it would not become
part of the main kernel until some security framework had been integrated. This was
the birth of the LSM interface.
LSM is a security framework that is part of the Linux kernel since the 2.6 series. It is
integrated into important kernel functions to control access to objects like files, network
interfaces and more. SELinux was ported to the LSM interface and became part of the
Linux kernel.
The first linux distribution that came up with SELinux support was Fedora Core, that
was sponsored by Red Hat. Today it is more or less supported by other distributions,
amongst others are of course Fedora and Red Hat, short after those came Gentoo, many
others followed, e.g. Debian.
B.1.1. Motivation
So why do we need SELinux? Is the classic discretionary access control system not
sufficient? Let’s take a look at a linux system:
1
2
3
4
5
6
7
Listing B.1: suid root programs
$ f i n d / b i n −perm +4000 −u i d 0 −e x e c l s − l {} \ ;
−rwsr−xr−x 1 r o o t r o o t 22064 2008−09−25 1 8 : 0 6 / b i n / fusermount
−rwsr−xr−x 1 r o o t r o o t 31012 2008−11−13 0 7 : 5 4 / b i n / su
−rwsr−xr−x 1 r o o t r o o t 92584 2008−09−25 1 5 : 0 8 / b i n /mount
−rwsr−xr−x 1 r o o t r o o t 30856 2007−12−10 1 8 : 3 3 / b i n / p i n g
−rwsr−xr−x 1 r o o t r o o t 26684 2007−12−10 1 8 : 3 3 / b i n / p i n g 6
−rwsr−xr−x 1 r o o t r o o t 71556 2008−09−25 1 5 : 0 8 / b i n /umount
This lists all the files in /bin/ that are owned by user root and have the setuid flag
set. The setuid flag tells the system that, whoever executes the file runs this file with the
permissions of the owner. That means in our case, if you use mount to e.g. mount an
usb stick, you run this command as user root. The problem with this situation might be
obvious: if someone manages to find a bug in one of these setuid-programs, he might be
able to gain root access to the system and may execute privileged commands. Sometimes
we can not simply disable all “setuid root” programs, as this would for example make
ordinary users not being able to mount their USB-stick.
So what can SELinux do about this? – Short answer - the principle of least privilege.
You can control what kind of actions ping or mount is allowed to perform on an object.
You can for instance say the process that results from executing the file /bin/ping can
open raw sockets to perform it’s main task. It also should have access to the DNS system
to resolve hostnames. Every other action should be denied, e.g. read or write access to
files. We will see how this works in detail later on.
But what if you have an application that has to be run as root and has to write to
files, like a syslog daemon? This application can of course write to every file on a system,
72
WS 2010/2011
System Security Lab
even on ones it should not. On traditional linux systems this is correct. On SELinux
you can run at-risk programs in their own domains. Then you can allow access for this
domain only to special resources.
So one of the main problems in traditional linux is the role of the root user, who
can normally do everything on a linux system. But there are other problems as well.
Discretionary access control in linux terms means that the owner of a resource has the
exclusive power over it. On the one hand this is ok, because you, as the owner of your
document, can choose who should have access to it. On the other hand this can also
lead to problems, as not all users are aware of the problems that weak file permissions
may bring.
B.2. SELinux Terms
To understand SELinux we have to explain some important commonly used terms first.
• access control – The meaning of this term is very often not understood correctly,
so I will try to describe, how the term access control is defined in association with
computers.
An access control mechanism monitors the access from a process to a resource and
regulates it based on predefined rules (This concept is also known as reference monitor
in computer security.) . When we talk about a resource, we normally mean a file, but
a resource can also be a network socket, a network host, another process or even
the accessing process itself. Access control is related to how a process can access a
resource, nothing else. The RBAC mechanism of SELinux that will be described
below, is not an access control mechanism, since it does not control the access on a
resource. Instead it only further constrains an existing access control mechanism.
• subject – A subject is the process that wants to access an object.
• object – When talking about an object we mean a resource like a file or a network
interface. But also another process may be an object, or even the subject itself
may be the object (self). Each object belongs to an object class.
• object class – Each object belongs to an object class. There are 4 kinds of object
classes in SELinux:
– file related objects - e.g. dir, file, lnk file, sock file
– network and socket objects - e.g. socket, netif(network interface) or more
specific types like tcp socket
– IPC
2
related objects - e.g. msg, shm
– miscellaneous - e.g. capability, passwd
2
inter-process communication
73
WS 2010/2011
System Security Lab
A list of available object classes can be found in the documentation of the reference policy by Tresys. [obj] Although object classes can be defined, as a list of
permissions, with the class statement, this makes only sense if the newly defined
class is supported by the kernel.
• Security Context – Each subject and object in SELinux has a security context. It
basically consists of 3 attributes: a user, a role and a type. If an MLS/MCS (multilevel-security/multi-category-security) policy is used, there is also an attribute for
the range/category.
Listing B.2: some default security contexts
1 SELinux ˜ # l s −Z l /
2 t o t a l 48
3 drwxr−xr−x+ 2 r o o t r o o t s y s t e m u : o b j e c t r : b i n t y
4096 Nov 10 1 4 : 0 4 b i n
4 drwxr−xr−x+ 3 r o o t r o o t s y s t e m u : o b j e c t r : b o o t t y
4096 Nov 26 0 4 : 2 9 boot
5 drwxr−xr−x+ 10 r o o t r o o t s y s t e m u : o b j e c t r : d e v i c e t
y
13040 Nov 26 0 5 : 3 8 dev
6 drwxr−xr−x+ 59 r o o t r o o t s y s t e m u : o b j e c t r : e t c t y
4096 Nov 26 0 5 : 3 7 e t c
7 drwxr−xr−x+ 3 r o o t r o o t s y s t e m u : o b j e c t r : h o m e r o o t t y
4096 Oct 28 2 3 : 1 5 home
8 drwxr−xr−x+ 8 r o o t r o o t s y s t e m u : o b j e c t r : l i b t y
4096 Nov 10 1 0 : 0 8 l i b
9 drwx−−−−−−+ 2 r o o t r o o t s y s t e m u : o b j e c t r : l o s t f o u n d t y
4096 Oct 28 2 2 : 4 4 l o s t+found
10 drwxr−xr−x+ 4 r o o t r o o t s y s t e m u : o b j e c t r : mnt t y
4096 Jun 11 1 9 : 4 6 mnt
11 drwxr−xr−x+ 3 r o o t r o o t s y s t e m u : o b j e c t r : u s r t y
4096 Nov 14 1 2 : 0 4 opt
12 dr−xr−xr−x+ 51 r o o t r o o t s y s t e m u : o b j e c t r : p r o c t y
0 Nov 26 0 5 : 3 7 p r o c
13 drwx−−−−−−+ 17 r o o t r o o t r o o t : o b j e c t r : s y s a d m h o m e d i r t y
4096 Nov 27 0 9 : 0 0 r o o t
14 drwxr−xr−x+ 2 r o o t r o o t s y s t e m u : o b j e c t r : b i n t y
4096 Nov 26 0 5 : 3 4 s b i n
15 drwxr−xr−x+ 7 r o o t r o o t s y s t e m u : o b j e c t r : s e c u r i t y t y
0 Nov 26 0 5 : 3 7 s e l i n u x
16 drwxr−xr−x+ 11 r o o t r o o t s y s t e m u : o b j e c t r : s y s f s t y
0 Nov 26 0 5 : 3 7 s y s
17 drwxrwxrwt+ 4 r o o t r o o t s y s t e m u : o b j e c t r : t m p f s t y
80 Nov 27 0 3 : 1 0 tmp
18 drwxr−xr−x+ 14 r o o t r o o t s y s t e m u : o b j e c t r : u s r t y
74
WS 2010/2011
System Security Lab
4096 Oct 29 2 1 : 1 5 u s r
19 drwxr−xr−x+ 13 r o o t r o o t s y s t e m u : o b j e c t r : v a r t y
4096 Oct 26 1 8 : 1 5 var
In listing B.2 we already get a little impression of the importance of the 3 portions
of a security context, at least for objects.
• Labeling – Files and directories on a filesystem are labeled with a security context.
• SELinux User – The SELinux user has nothing to do with the standard system
user. Actually there are several system users sharing a single SELinux user on an
SELinux system. The task of the SELinux user is to decide which roles a system
user is allowed to take.
SELinux users are typically in the form name u. The u suffix is no must, but
is conventionally used for SELinux users. Some typical users are root(which is,
exceptionally, not suffixed with u), system u which is used for all kinds of system
processes, e.g. init.
• Role – The role is used to determine which domains a process can enter. It is
absolutely unimportant for objects and only exists to make the security context
complete.
SELinux roles are, like SELinux users, suffixed. Yes, right, with r of course. Here,
the suffix is for traditional purpose and optional, too. Some standard roles, that
exist on most SELinux systems are user r, which is normally used for common
users. The staff r role is similar to the user r role, with the difference, that a
member of the staff r is allowed to change to the sysadm r role. The sysadm r
role is the role, that gives back most of the powers to root, that other roles, like
staff r forbid. Objects always take the special role object r, which is hardcoded. object r must never be defined or used in any way, this could be a
security issue, since a process with this role could potentially enter any domain.
• Type – Each object and subject in SELinux has a type. In the policy it is used
to determine which subjects can access the object. The type is the most important
portion of a security context in SELinux and you’ll find many different types.
As you might already have guessed, SELinux types are typically in the form type t.
• Domain – When talking about the type of a process, we call it domain. Technically
speaking there is no difference between domain and type. Access to a domain, as
everything in SELinux, has to be allowed explicitly. A process can only enter a
specific domain on execution (execve()) .
• Permissions – The permissions define in which way a subject is allowed to access
an object. There are several types of permissions in SELinux that we know from
traditional linux, like read and write, but also some finer grained ones like append
or getattr. This doesn’t suffice for all objects of course, so there are object class
75
WS 2010/2011
System Security Lab
specific permissions, like create or bind for sockets, or add name to create or
move a file to a directory. A list of available permissions can be found in the
documentation of the reference policy by Tresys. [obj]
• Access Vector – An access vector is a set of permissions that a subject is allowed
to perform on an object.
• Alias – An alias can be defined for types. This makes sense for compatibility reasons if the policy changes. Remember Netscape? It was somehow the predecessor
of Mozilla. To make the types mozilla t and netscape t mean the same, we can
define the latter as an alias.
1
2
3
4
5
#method 1
type m o z i l l a t ;
typealias mozilla t alias netscape t ;
#method 2 ( same a s method 1 )
type m o z i l l a t a l i a s n e t s c a p e t ;
• Attribute – Attributes can be used to group types.
1
2
3
4
5
6
7
8
9
10
11
12
13
# d e c l a r e the a t t r i b u t e c o n f i g f i l e
attribute c o n f ig f i l e ;
# a s s i g n t y p e s t o a t t r i b u t e ( method 1 )
type e t c t ;
type shadow t ;
typeattribute etc t c o n f i g f i l e ;
t y p e a t t r i b u t e shadow t c o n f i g f i l e ;
# a s s i g n t y p e s t o a t t r i b u t e ( method 2 )
type e t c t , c o n f i g f i l e ;
type shadow t , c o n f i g f i l e ;
#u s e t h e a t t r i b u t e i n an a l l o w r u l e
a l l o w sysadm t c o n f i g f i l e : f i l e r e a d ;
In the example above we use the attribute to make an allow rule. Without the
attribute, we would have had to write the rule for both types. An attribute is
internally expanded to the list of types that have this attribute.
• Policy – We will use the term policy to describe a set of rules that define if and
how a subject can access an object.
• Relabeling – An SELinux policy can allow trusted processes to change the label
of an object. Examples are, if you login, the program login changes the label of the
controlling tty. The permissions that are related to type changes are relabelto
and relabelfrom.
76
WS 2010/2011
System Security Lab
• Type Changes – You can specify rules in the policy, that tell SELinux-aware
applications, how they should relabel a file. Those rules are only proposals, but an
application should attend this. If it doesn’t, it will probably happen, that access
problems occur.
t y p e c h a n g e sysadm t t t y d e v i c e t : c h r f i l e y
sysadm tty device t ;
This rule tells an SELinux-aware process in the sysadm t domain, that a file of
object class chr file should get the type sysadm tty device t when relabeling
it.
Note, that type changes are made by an application, whereas the default labeling
is made by the kernel. So the application still needs the appropriate permissions
for labeling.
• Type Enforcement – If you watch the three definitions of SELinux user, Role
and Type carefully, you maybe have already seen the importance of each. The
most important one is the type. It is used to define what permissions a subject of
a certain source type is allowed on an object of another certain target type. This
technology is called Type EnforcementTM (TE). Type Enforcement is a registered
trademark of Secure Computing. An interesting thing to mention is probably the
Statement of Assurance [tea] from Secure Computing regarding SELinux.
• Role-Based Access Control – To determine which permissions a system user
has on a certain object, he has to have access to a certain domain that is allowed to
access the specified object. To group users who should have common access rights,
a role is defined. Each user who can change to this role can then transition to the
needed domain, if allowed. It is easier to maintain a role than to give each user the
same rights. It is important to notice, that this Role Based Access Control (RBAC)
is not really an access control mechanism, since it doesn’t allow or deny access.
It only restricts the possibility of a valid security context. RBAC, as known in
its original meaning from computer sciences, means assigning permissions directly
to roles. In SELinux we have an additional abstraction layer between roles and
permissions, the type.
• User-Based Access Control – UBAC is a really new mechanism in SELinux,
since the reference policy version 2.20081210. It is based on constraints, that apply
to the user portion of both security contexts involved in an access decision, the
one of the accessing process and the one of the object. To allow access to UBAC
constrained objects, both user portions must be equal. UBAC is no replacement
for RBAC, but can additionally be enabled. If you read anything like “UBAC is
a replacement for RBAC”, don’t get confused. They don’t mean RBAC in the
meaning of Role-Based Access Control we defined above.
77
WS 2010/2011
System Security Lab
B.3. How it Works
B.3.1. Linux Security Modules
The SELinux we are talking about is implemented as an Linux Security Modules(LSM)
module. [lsm] Before SELinux had been implemented as an LSM, it was a set of kernel
patches. Roughly speaking the LSM architecture is a set of functions that hook into the
kernel code. Those hooks are called in the kernel before critical operations are made,
such as file or network access or operations on processes or IPC objects. Those functions
are called whenever a permission check is to be made. Unlike the classic DAC checks,
the LSM hooks are applied on every access. So on a traditional linux system you can
change the permissions of a file while a process has opened it and the process won’t
notice this, as long as the file remains opened. If you do this on a system with an active
LSM module, the file might not be accessible by the process anymore, depending on the
rules. In Figure B.1 you can see that the LSM hooks are called after the DAC checks.
Figure B.1.: LSM Hook Architecture
LSM hooks are normally restrictive, that means, they can deny access that has been
allowed by the kernel, but cannot allow access that has been forbidden by the kernel. So
you can never give more privileges to a process with SELinux than it would have without
it. There are also permissive LSM hooks, they are needed for POSIX capabilities, which
are also implemented as an LSM module since the 2.6 kernel series.
Besides SELinux there are some other LSM modules, e.g. AppArmor or LIDS, to
mention some well-known ones.
B.3.2. The SELinux Architecture
As already mentioned, SELinux is based on the FLASK architecture. The whole construct is split into a policy-enforcing part and a decision-making part. So we have a strict
2
image in Figure B.1 taken from http://www.usenix.org/event/sec02/full_papers/wright/wright_
html/node3.html
78
WS 2010/2011
System Security Lab
separation between policy enforcement and policy decision-making here. The policy enforcement part is the object manager that forbids or allows access. In fact it is more
precise to say the object managers, because we have actually more than one, at least
in SELinux. In SELinux the object managers are the LSM hooks, that are scattered
throughout the kernel code. The policy decision-making part consists of the security
server which makes the decision if an action is allowed or not. For better performance
there is the Access Vector Cache(AVC), that caches decisions made by the security
server. If the object manager gets a request, it gets the security contexts of the subject
Figure B.2.: SELinux Architecture
and the object. It then converts the security contexts into SIDs (security identifier) and
sends those two SIDs together with the object class to the AVC to ask for a decision. If
the AVC doesn’t have a decision cached, the AVC asks the security server. The security
server checks the binary policy that is loaded into the kernel and makes a decision. This
decision will be made in two steps.
First the security server generates a mask of the permissions allowed by rules. Then it
will remove allowed permissions, that are disallowed by a constraint. The decision, in the
form of an access vector, is then sent back to the AVC, which stores it for future requests
and sends it back to the object manager. Based on the reply, the object manager allows
79
WS 2010/2011
System Security Lab
or denies access.
SIDs are only used internally. In userspace, only security contexts are used. The
security server maintains a table that maps SIDs to security contexts.
Since it is not unlikely, that you enhance or change the policy, it would really be
unacceptable if you have to restart the whole system for each change you make. So, of
course, you can load a new policy into the running kernel. If the policy gets changed
in any way, of course the security server is noticed, since it makes the decisions. It will
then update its SID mappings and with it reset the AVC.
B.3.3. SELinux Files and Filesystems
On SELinux there are two important locations. One is the configuration directory
/etc/selinux, the other is the selinux filesystem mounted at /selinux.
/selinux
This is a pseudo filesystem like /proc or /sys and contains information about the current
state of the SELinux system. There are several “files” that can be used to get or set
states and values of the system. Here are some examples:
• /selinux/enforce – contains the enforcing state
• /selinux/booleans/ – contains a file for each Boolean on the system
• /selinux/class/ – contains subdirectories for each object class (file, dir, socket, . . . )
and the available permissions
/etc/selinux
This directory contains SELinux specific configuration and the binary policy. The file
/etc/selinux/config contains the state of the SELinux system on boot. It contains the
policy type and the enforcement mode.
There is also a directory for each policy, e.g. for the strict policy /etc/selinux/strict/,
that contains subdirectories, that in turn contain the binary policy, the active policy
modules and information about SELinux users and file contexts.
B.3.4. File Labeling
Each object and subject in SELinux has to be labeled correctly. A process (subject)
simply inherits the security context of its parent, but what about files? In SELinux
there are 4 mechanisms for labeling a file-related object.
• labeling based on extended attributes (xattrs)
• task-based labeling
• transition-based labeling
80
WS 2010/2011
System Security Lab
• generalized labeling
If a filesystem supports extended attributes, the security context is saved there. Examples
for those filesystems are ext2/ext3, xfs and reiserfs. If a file-related object on such
a filesystem gets labeled, it normally inherits the user portion of the security context
from the creating process. The role portion is always object r. The type portion is
inherited from the directory containing the file or, if there exists a type transition rule
for the domain of the process and the type of the directory containing the file, the type
specified by this rule is used.
The task-based labeling is for instance used if you use pipes, the security context is
inherited from the creating process.
Transition-based labeling is similar to the task-based labeling, but it uses type transition
rules for the labeling, like the xattrs-based labeling. It is for example used on tmpfs,
shm, or devpts filesystems.
Generalized labeling is used for pseudo filesystems like proc, sysfs or selinuxfs and for
filesystems that don’t support extended attributes like fat or iso9660.
1
2
3
4
fs use xattr
fs t ;
fs use task
fs t ;
fs use trans
tmpfs t ;
genfscon
proc kmsg t
Listing B.3: filesystem labeling statements
ext3
system u : o b j e c t r : y
pipefs
tmpfs
proc
/kmsg
If you want to change the default label for unlabeled files, the command mount supports the options context=, fscontext= and defcontext= on SELinux.
Other objects like network interfaces or ports are also labeled, but the rules are similar
to those of file-related object labeling.
B.3.5. Enforcing, Permissive or Disabled?
You can, if enabled in the kernel, run SELinux in two modes, permissive and enforcing.
The default mode can be set in /etc/selinux/config and can be overridden by setting the
kernel boot option enforcing to 0 or 1. You can also get and set this state with the
command getenforce and setenforce.
• enforcing – The policy is enforced, access is allowed based on the policy.
• permissive – The policy is not enforced, but log messages are generated as in
enforcing mode.
• disabled – This is not a real mode like the previous two, it is just listed here to
mention, that SELinux can be disabled by setting the kernel boot option selinux
to 0. If configured in the kernel this can also be done at runtime.
81
WS 2010/2011
System Security Lab
B.3.6. The Boot Process on SELinux
The boot process on SELinux is quite interesting, since it is some kind of chicken and egg
issue. On an SELinux system each process has to be labeled with the correct domain.
This also applies to init, the first process started on a linux system. To label a process
correctly, the policy has to be asked.
The question is, how can a process be labeled before the policy is loaded? – Here is a
list of the boot process on an SELinux system:
1. The bootloader loads the linux kernel.
2. The kernel loads init and assigns the predefined initial SELinux ID to it.
3. init mounts /proc and looks for the selinuxfs filesystem type.
4. If SELinux is disabled the system boots like a traditional linux system.
5. If it is enabled, /selinux is mounted.
6. Now init checks which policy version is supported by looking at /selinux/policyvers.
7. init now checks /etc/selinux/config for the type of policy that should be active and
loads the policy from /etc/selinux/$POLICY TYPE/policy.$POLICY VERSION.
If the policy version is not supported by the kernel, an older version is loaded.
8. If there are Booleans, that don’t have their default value, they are set and the
policy is modified in the memory.
9. The kernel does not enforce any policy until the initial policy is loaded. After it
has been loaded, the enforcing mode(enforcing, permissive) from the config or the
kernel commandline is “active”.
10. init now re-executes itself and transitions to its correct domain based on the policy.
11. The boot process continues as it would without SELinux.
B.3.7. Domains, Types and Transition
Now let’s see what happens if we use a simple command like /bin/ls.
At first the classic DAC system checks (Fig. B.1) , if we are allowed to execute the file
/bin/ls. At least that is the case if /bin/ls is a binary. If it is an interpreted script(perl,
bash, python, . . . ) we will also need read permission. If we are not allowed to execute
the file the procedure ends here. We just can’t execute the file. If the DAC permits
access, the next part is to ask the MAC system.
The MAC system checks, if /bin/ls is labeled with a type, for which a rule exists
that allows the domain of our shell process to execute it. If this is the case, /bin/ls gets
executed and inherits the security context from our shell. If there is no allow rule we
can’t execute the command and a log message is generated, if no appropriate dontaudit
rule was defined.
82
WS 2010/2011
System Security Lab
Since /bin/ls is a command, that isn’t really a potential security risk, as it is usually
not setuid root, let’s see what happens if we execute /bin/passwd. This is a bit more
tricky, since a bug in the program could have disastrous impact on the security of a
system.
Let’s have a look at the following situation:
Listing B.4: even root in the sysadm r role can’t directly read /etc/shadow
SELinux ˜ # i d −un
root
SELinux ˜ # i d −Z
r o o t : sysadm r : sysadm t
SELinux ˜ # c a t / e t c / shadow
cat : / e t c / shadow : P e r m i s s i o n d e n i e d
SELinux ˜ # l s −l Z / b i n / passwd / e t c / shadow
−rws−−x−−x+ 1 r o o t r o o t s y s t e m u : o b j e c t r : p a s s w d e x e c t 32844y
Oct 28 1 5 : 5 5 / b i n / passwd
9 −rw−−w−−−−+ 1 r o o t r o o t s y s t e m u : o b j e c t r : shadow t
694y
Dec 11 1 4 : 4 3 / e t c / shadow
1
2
3
4
5
6
7
8
In listing B.4 we see that even the almighty root user can’t read the file /etc/shadow.
Even more interesting is, that he’s in the sysadm r role, which is normally the most powerful role on SELinux systems. So why can the program /bin/passwd access /etc/shadow ?
Since Type Enforcement is the mechanism in SELinux that defines what access is allowed, we’ll take a closer look at this and scan through the source of our policy. Obviously
there does not exist a TE rule that allows the sysadm t domain to access objects of the
type shadow t. (This is for a good reason, of course. Let it be an attacker who got control of
a process running in domain sysadm t or a tired out sysadmin.)
Since SELinux denies every access by default, obviously there have to be some rules
that allow this access. You will find an extended version of this rule:
a l l o w p a s s w d t shadow t : f i l e { c r e a t e g e t a t t r open r e a d y
write };
This rule allows passwd t to access /etc/shadow, but not sysadm t. So, why can
/bin/passwd read /etc/shadow anyway, even though you are running it from the sysadm t
domain?
If a program is executed and a process is generated, this process inherits the security
context of the calling process. So if your current bash session has the security context
user u:user r:user t, it runs in the user t domain. If you execute a command, it will
also run in the user t domain. But if you need to define special rules for a program like
passwd, you somehow have to make those rules unique to this one program.
Let’s see in detail what exactly happens when you call /bin/passwd. Here, too, the
DAC will be applied first, of course. The difference lies within the MAC part. The
first thing is to check whether you are allowed to execute the file /bin/passwd. If you
83
WS 2010/2011
System Security Lab
are allowed to execute the file, it is executed. If your shell process runs in the domain
user t, an appropriate allow rule could look like this:
allow user t passwd exec t : f i l e { getattr execute };
Now comes the special part. The keyword here is domain transition. Domain Transition,
or type transition, is when a process changes from its old domain to a new domain.
If you start a program (e.g. /bin/passwd or /bin/ls), the process that is being
created will inherit the security context of your shell. That’s fine for /bin/ls, but not
enough for /bin/passwd, since we want special security. So we also have to create some
special rules, that is, we need to run passwd in a special domain to apply custom rules
to it.
To let passwd run in a unique domain (passwd t) we need another domain that
helps us with the transition to this domain, since we cannot enter passwd t directly.
What we do is, we label the file /bin/passwd with the type passwd exec t. Then we
give the domain passwd t the special permission entrypoint on objects with the type
passwd exec t of class file.
allow passwd t passwd exec t : f i l e entrypoint ;
This rule defines which executable files are allowed to enter the domain passwd t. Something is still missing. Imagine this rule creates a door. But since were on SELinux we
also have a bouncer in front of that door. To get past a bouncer you need special permission, like an entrance card or being female with long blonde hair or just being stronger
than the bouncer. Since your shell process is genderless and is not stronger than the
enforcement server of the system, it needs a VIP ticket. The ticket for your shell process
looks like this:
allow u s e r t passwd t : p r o c e s s t r a n s i t i o n ;
This rule allows a process in domain user t to transition to domain passwd t.
Let’s sum up. We have /etc/shadow of type shadow t, that can only be read by a
process in domain passwd t, which again can only be entered by executing a file of type
passwd exec t.
We have still one last, but important problem left. All rules necessary to transition
and to execute are ready, but how does /bin/passwd actually transition to the correct
domain if it is executed? If passwd were an SELinux-aware program, it could do this by
itself now. Since it isn’t and we want to cover the case for every command, we need a
fourth rule to make the system manage the transition automatically.
t y p e t r a n s i t i o n u s e r t passwd exec t : p r o c e s s passwd t ;
This only makes a process created from a file of type passwd exec t transition to
passwd t automatically if it is created by a process in the domain user t. The previous allow rules are still needed.
So why do we need this amount of effort? If /bin/passwd is the only file of type
passwd exec t on a system, it is obviously the only way to access /etc/shadow. So no
84
WS 2010/2011
System Security Lab
other process will ever be in the position to access it. If you find a bug in /bin/passwd,
you may of course be able to do damage to /etc/shadow, but this lies beyond the powers
of SELinux and is a problem that can only be fixed by a passwd developer.
B.3.8. Roles
When we talked about domain transition in the last part, we left out one thing completely. The RBAC part of SELinux. Although roles are not the primary access control
mechanism, they can be used to further limit the use of domains. Since roles are assigned to SELinux users, a role defines which domains can coexist together with which
user-portion.
So for the /bin/passwd program to work, we actually need a fifth rule. A rule that
makes the security context user u:user r:passwd t valid:
r o l e u s e r r types passwd t ;
For roles there also exist role transitions, but they are not as frequently used as domain
transitions. A role transition is for example needed when a daemon is started by a system
administrator.
r o l e t r a n s i t i o n sysadm r d a e m o n e x e c t s y s t e m r ;
This rule states that if a process with the role sysadm r executes a file with the type
daemon exec t, the role should be changed to system r, so that the daemon with this
type always runs with the same role.
These role transitions must be allowed, of course. There is another allow statement
in SELinux that applies to roles.
a l l o w sysadm r s y s t e m r ;
Although this role allow statement is similar to the type allow rule, note that they are
two different things.
B.3.9. Optional Policies
Since the development of the reference policy you don’t have to compile the whole
policy source, but can split it up into modules. This provides flexibility but also requires
attention, if one module depends on another module. If there is such a dependency, the
needed module must be loaded to load the module that needs it.
This is ok, if the existence of the needed module is mandatory. If your module does
not necessarily depend on another module, but only supports it, you have the option to
declare a portion of the rules in an optional-block.
1
2
3
optional {
apache read log ( fail2ban t )
}
85
WS 2010/2011
System Security Lab
This is a slightly modified example from the policy module of fail2ban (a script that
analyzes logfiles and acts based on the entries) . If all the types, roles, permissions, etc., that
are used in the optional block are defined somewhere in the loaded policy, the policy
statements in the optional-block are loaded, too. Now, every time a module gets loaded
or unloaded, this optional policy is checked and the statements are enabled or disabled
accordingly.
B.3.10. Booleans
If a policy rule does not meet your needs, or you prefer a different behaviour, luckily
you can change the policy and load it into the running kernel. Even though this is
better than rebooting the system for every change, it might sometimes be helpful if you
wouldn’t have to mess around with writing policy, analyzing logfiles, mediate on the
need for a special rule and such.
For some rules exist booleans. Booleans in SELinux are variables you can set to change
the behaviour of the policy on-the-fly. They make it possible to change the behaviour of
the policy without reloading it. You can get a list of available booleans with getsebool
-a.
Listing B.5: definition and usage of a boolean variable
1
2
3
4
5
6
7
bool user ping f a l s e ;
# ...
i f ( user ping ) {
#a l l o w p i n g f o r r e g u l a r u s e r s
} else {
#o p t i o n a l l y do something e l s e
}
In the policy a boolean is defined with the bool statement, then follows the name of the
boolean and at last the default value, which must be true or false.
To use the boolean in the policy we use the if -statement, which evaluates the expression in brackets after the if and applies rules based on this. Not every kind of rule is
allowed in this conditional statement, e.g. role allow rules. Also nesting of if-statements
is not allowed, but there are several boolean operators one can use, that are well-known
from some programming languages.
B.3.11. Dominance
A role can be defined to dominate other roles. This can be achieved with the dominance
statement.
dominance { r o l e u b e r r { r o l e sysadm r ; r o l e secadm r } ; }
If a role dominates other roles, it inherits all their type associations. In the example
above, uber r will gain all access that the other two roles had before the dominance
statement. Every type that is associated with, e.g. sysadm r, after the dominance
86
WS 2010/2011
System Security Lab
statement doesn’t affect the uber r role. A dominance can also be used in the constrain
statement to express a relation between two roles. There are 4 dominance relationship
operators.
• dom – r1 was defined to dominate r2
• domby – r2 was defined to dominate r1
• eq – the same as ==
• incomp – both roles don’t dominate each other
Dominance is also important for MLS, but a bit different of course.
B.3.12. Constraints
Normally all access in SELinux must be allowed. This is true and will stay true, but
there are mechanisms that can be used to disallow an allowed permission. More precisely
spoken, it will constrain the allowance. In SELinux this can be done with the constrain
statement.
c o n s t r a i n p r o c e s s t r a n s i t i o n ( u1 == u2 ) ;
This rule will constrain the transition permission for the objectclass process. It will
only allow transition on a process if the user portions of both security contexts are
equal. The keywords u1 and u2 indicate, respectively, the user portion of the security
context of the subject and the object. There are also the keywords r1, r2, t1 and t2,
which apply to the role and type portions of the subject and object. Instead of the ==
operator there can also be the != operator or one of the dominance operators, if we
compare roles. The left side of the comparison always has to be a keyword and the right
side can be a keyword or an identifier.
Another constrain mechanism is the validatetrans statement. It can be used to
further control the ability to relabel an object. It is only mentioned here for completeness
and won’t be discussed further since it is currently not used in the reference policy.
B.4. The Policy
Let’s have a look at the SELinux policy now. There are many kinds of access on a system,
but normally a program needs only few of them. The normal behaviour of SELinux is
to deny every access and a good rule should only allow the kind of access for a process
that it really needs.
B.4.1. The Reference Policy
There are several programs that run on every Linux system, so it wouldn’t make sense
to reinvent the wheel every time we install an SELinux system. Fortunately there are
87
WS 2010/2011
System Security Lab
basic rules for commonly used programs, such as mount, ifconfig, etc. These standard
rules make the base policy.
In the beginning there was the example policy by the NSA. It was a set of rules for
programs that exist on nearly every linux system. Today the reference policy [refb] has
replaced the example policy. It is based on the example policy and is maintained by
Tresys Technologies.
Some of the main development goals of the reference policy were:
• one policy source for all policy variants (strict, targeted, MLS)
• modularity
• integration of documentation into the policy source
• make it easier to maintain the policy (m4 macros)
B.4.2. Compiling the Policy
If you have ever compiled a linux kernel by yourself, you will probably know, that you
can compile most things either directly into the kernel or you can build them as separate
modules. Building a policy is somehow like building a kernel.
First of all you will probably download the reference policy source, which already
contains rules for most things. The reference policy is split up into several policy source
modules. There are source modules for many tasks, e.g. applications like Mozilla or
daemons like distcc, but also for roles like sysadm r. To make the needed rules usable
by the kernel, they have to be compiled into binary form. This is done by the policy
compiler checkpolicy/checkmodule. The created modules have the extension .pp. You
will most certainly never have to use the policy compiler directly, but you will use a
makefile instead, that takes care of everything.
You can build either a monolithic policy, which will be one big module. Or you can
build a modular policy, which will consist of a base module and optionally some loadable
modules. Building a modular policy has the advantage, that you don’t need to rebuild
the complete policy for every little change you make. You can load modules for the
programs, as you need them.
If compiling a modular policy, the base module will contain the most important source
modules. Most important is normally defined as those rules needed to boot the system
correctly. This depends on you linux distribution and configuration, of course.
To finally activate or deactivate a module from userspace, you use the semodule
command.
B.4.3. Type Enforcement Rules
To actually write policy, we need to take a look at the syntax and different parts of a
policy.
88
WS 2010/2011
System Security Lab
Figure B.3.: from policy source to in-kernel policy
We have Type Enforcement, so obviously we need to define types. In line 4 in listing
B.6 for example, the type user t is declared (this is an example, the type user t is
probably already defined on each system).
Listing B.6: some type enforcement rules
1
2
3
4
5
6
7
8
9
10
11
12
require {
type shadow t ;
}
type u s e r t ;
require {
type e t c t ;
type b i n t ;
}
# <r u l e type> <s o u r c e type> <t a r g e t type >:< o b j e c t c l a s s > <y
s e t o f p e r m i s s i o n s >;
allow u s e r t e t c t : f i l e read ;
allow u s e r t b i n t : f i l e { execute g e t a t t r read } ;
d o n t a u d i t u s e r t shadow t : f i l e g e t a t t r ;
89
WS 2010/2011
System Security Lab
13
n e v e r a l l o w u s e r t shadow t : f i l e r e a d ;
Note, that everything, that is used in a policy module has to be declared somewhere,
this includes types, booleans, attribute, permissions, . . . . This is either be done using
the proper declaration statement, like the type statement in listing B.6 or, if the used
type is declared somewhere else in the loaded policy, that is in another policy module,
by using the require statement. It doesn’t need to be specified where exactly the
required statement can be found, only that it is already defined. There can be more
than one require block. If you need a require block in an interface file, you should use
the predefined macro gen require().
An actual type enforcement rule, or access vector rule, is made up of five parts.
• rule type – this can be one of
allow which indicates an allow rule
dontaudit which does not allow something, but only supresses the log message
auditallow which allows and additionally generates a log message
neverallow is used to prevent careless policy writing, if a neverallow rule is
defined for a type and an allow rule, this will give an error when compiling the
policy.
• source type – is usually the domain of a process that wants to access something
• target type – is the type of the object the source wants to access
• object class – the class of the target, e.g. file or socket
• permissions – a set of permissions the source is allowed on the target
If you look at listing B.6 you can see some access vector rules. The rule in line 10 allows
a process in the domain user t to read files of type etc t. Line 11 contains an allow rule
that allows more than one permission. The dontaudit rule says that no log message
should be generated if a process in domain user t tries to get the attributes of a file of
type shadow t. If you, for example, use the command ls -lZ /etc/shadow, getattr
is needed to show the owner, date and other object information. The neverallow rule
makes it impossible to ever define an allow rule that would allow read access for user t
to shadow t.
There are many other things to know when talking about Type Enforcement rules,
but we won’t go into more detail here. Just one last interesting thing. The special
type self. If you find a rule, e.g. allow type t self :process signal ;, this means, that a
process in domain type t is allowed to send itself a signal (except SIGKILL and some
other critical signals).
B.4.4. Strict and Targeted Policy
The basic concept of SELinux is to deny every access and only allow access for explicitly
defined actions. You will have this behaviour if you use the strict policy type.
90
WS 2010/2011
System Security Lab
For desktop systems this doesn’t make much sense, since you will install, upgrade
and deinstall many programs in the lifetime of this system that may need different
policy rules from one version to another. To make life a bit easier with SELinux but
still secure, the targeted policy was invented. In the targeted policy there is a special
domain that all processes run in unless specific rules have been made. Processes that
run in this unconfined domain work as expected in most cases. Applications that need
special attention, mostly network daemons, but also client applications, will be confined
as in the strict policy. So from the technical point-of-view, SELinux still denies every
access.
You get both types of policy from the reference policy.
B.4.5. Multi-Level-Security
SELinux also implements multi-level-security (MLS), which can optionally be enabled
when compiling the policy. MLS is an extended implementation of the Bell-LaPadula(BLP)
model. If enabled, MLS constraints checks must be passed together with the access vector rules to permit access.
Listing B.7: MLS rules
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# declare s e n s i t i v i t i e s
s e n s i t i v i t y s0 ;
s e n s i t i v i t y s1 ;
# d e c l a r e an a l i a s e d s e n s i t i v i t y
s e n s i t i v i t y s2 a l i a s high ;
# s p e c i f y t h e h i e r a r c h y o f our s e n s i t i v i t i e s from ” low ” ( s 0 y
) to ” high ” ( s2 )
dominance { s 0 s 1 s 2 }
# define
category
category
category
c a t e g o r i e s with a l i a s e s ( o p t i o n a l )
c0 a l i a s r e d ;
c1 a l i a s g r e e n ;
c2 a l i a s b l u e ;
# define allowed s e c u r i t y l e v e l s
l e v e l s 0 : c0 . c2 ;
l e v e l s 1 : c0 . c1 ;
l e v e l s 2 : c0 , c2 ;
In listing B.7 we define sensitivities, categories and allowed security levels. The category and sensitivity statements just define and alias categories and sensitivities. The
dominance statement defines the hierarchical relationship between our sensitivities. The
level statement defines which combinations are allowed. Notice the “,” and “.” between
the categories in the level statements. “.” marks a range (in the order we defined the
categories), “,” lists categories.
91
WS 2010/2011
System Security Lab
Taken the definitions in listing B.7, we now have a look at security contexts. When
using an MLS-enabled policy, the security context is extended with two additional fields,
the low (current) and high (clearance) security level, which, in turn, consist of a sensitivity and a set of categories. The high level of a valid security context must always
dominate the low level. Sensitivities are hierarchical and can be compared using equivalence relationships(<, =, >). Security levels ar non-hierarchical and can be compared
using a dominance relationship.
The low level indicates the current security level of a process or the sensitivity of the
data an object contains. The high level indicates the clearance of the user portion of
the security context (so it determines the highest possible security level allowed for the
current level of any security context).
Listing B.8: security contexts in an MLS policy
1
2
3
4
5
6
# valid contexts
u s e r u : u s e r r : u s e r t : s0−s 2 : c0
u s e r u : u s e r r : u s e r t : s 0 : c0−s 2 : c2
# invalid contexts
u s e r u : u s e r r : u s e r t : s 0 : c0−s 0 : c2 # t h e h i g h l e v e l doesn ’ t y
dominate t h e low l e v e l
To make use of the security levels in the policy, you would use the mlsconstrain and
mlsvalidatetrans statements, which are based on the constrain and validatetrans
statements. The difference is that the MLS variants can only be used with an MLSpolicy and the normal variants in both policies. The mlsconstrain statement has the
additional keywords l1, h1 and l2, h2 which apply to the current security level of the
subject and current security level of the object, respectively. Another difference is that
dominance operators can be used in conjunction with security levels (sl1 and sl2). They
are a bit different from the dominance operators for roles.
• dom – sl1 dominates sl2, if the sensitivity of sl1 is higher or equal to that of sl2
and the categories of sl1 are a superset of those of sl2
• domby – sl1 dominates sl2, if the sensitivity of sl1 is lower or equal to that of sl2
and the categories of sl1 are a subset of those of sl2
• eq – sl1 equals sl2, if the sensitivities are equal and the set of categories are equal
• incomp – if sl1 and sl2 can’t be compared, that is, neither is a subset of the other
To simulate the no-write-down behaviour of Bell-LaPadula, we could use the following
rule:
m l s c o n s t r a i n f i l e w r i t e ( l 1 domby l 2 )
That means a process is not allowed to write to a file, if it’s current security level is
dominated by the security level of the file, so we can only write information to higher,
92
WS 2010/2011
System Security Lab
but not to lower classified documents. To be correct, we must theoretically also constrain
other permissions like append, because they also allow writing in a special meaning.
The mlsvalidatetrans statement is similar to its non-MLS variant. In contrast to
that, the MLS-variant is more common. The differences are the respective keywords for
the security levels, similar to the case of the mlsconstrain statement.
B.4.6. Multi-Category-Security
The Multi-Category-Security (MCS) implementation in SELinux can be seen as a replacement for MLS, as MLS only makes sense in the military sector, but usually not for
a modern operating system that is used on desktop systems.
The very important difference between MLS and MCS is that MLS is still MAC,
whereas MCS is DAC. And that is quite interesting from the users point-of-view. With
MLS we have an SELinux enhancement that is MAC. With MCS we have an SELinux
enhancement that is DAC. So the ordinary user gets the possibility to control his files
with it.
For MLS the security context had to be modified, that is, the two security levels were
added. MCS uses this security context with the difference, that the sensitivity levels are
ignored and everything is labeled with the same sensitivity(s0). So MCS uses the MLS
mechanisms, but the concept is not MLS.
To enable a subject to access an object, the user, who is the owner of this object(file),
labels it with a category. The accessing process must be in this certain category to access
the object. To have access to a category, the high range of the subject contains a list of
allowed categories. The low range of the subject determines the default categories, that
a newly created file gains.
Since MCS is DAC and therewith granting permission lies within the discretion of the
owner of a resource, MCS access control checks are made, after the DAC checks and
the access vector rules are applied. Categories are commonly aliased, so the ordinary
user doesn’t have to deal with cryptic categories like c0, c1 and so on. To make use of
these category translations, a translation daemon (mcstransd) is needed, that is asked
whenever a category is accessed.
The categories for a system user are assigned by defining a login for this user. To
change the categories of a file and of an SELinux user, the chcat command is used.
Listing B.9: chcat command
1
2
3
4
5
6
7
8
# add c a t e g o r i e s t o a f i l e , i f no t r a n s l a t i o n daemon i s y
running
c h c a t −− +s 0 : c3 ,+ s 0 : c4 t e s t f i l e . t x t
# add c a t e g o r i e s t o a f i l e
c h c a t −− +Category1 ,+ Category2 t e s t f i l e . t x t
# remove c a t e g o r y from a f i l e
c h c a t −− −Category2 t e s t f i l e . t x t
# add l o g i n f o r s y s t e m u s e r d e f a u l t
semanage l o g i n −a d e f a u l t
93
WS 2010/2011
System Security Lab
9
10
# g i v e a u s e r a c c e s s t o Category1
c h c a t − l −− +Category1 d e f a u l t
B.4.7. Policy Files
When you need to write a new policy or look at the modules of the reference policy,
there are 3 types of files for each module. The SElinux reference policy makes heavy use
of the macro language m4. So it might be useful to read a bit about m4 when working
more extensively with SELinux.
File Context Files (.fc)
Those files define default contexts for files that the module uses. If you use a command
like restorecon or a distribution specific script that relabels the complete filesystem,
this default context is applied to the files. Also, when you copy a file this security context
will be applied to the copy.
Listing B.10: Appendix/aide.fc
1 / usr / sbin / aide
−−
: ai de e xe c t , mls systemhigh )
2
3 / var / l i b / a i d e ( / . ∗ )
: aide db t , mls systemhigh )
4
5 / var / l o g / a i d e ( / . ∗ ) ?
: a i d e l o g t , mls systemhigh )
6 / var / l o g / a i d e \ . l o g
−−
: a i d e l o g t , mls systemhigh )
gen context ( system u : o b j e c t r y
Listing B.10 shows the file context definitions for the Intrusion Detection Environment
AIDE. Entries in .fc files consist of three columns.
1. The first column contains a regular expression that defines the file(s). This regular
expression is anchored at both ends, that means it matches full pathnames, not
only parts of it.
2. The second column can be used to limit the filetype. It can be left empty to not
define the filetype any further. Or it can be in the form -X, where X is the filetype
you can also see with ls -l.
3. The third column makes the security context. gen context is a macro defined
in the reference policy. Here you can see that the macro takes two arguments,
the first one is the security context. The second one is optional and indicates the
MLS/MCS range/category. You sometimes also find just the security context, but
using the macro is the way to go for newer policies.
94
WS 2010/2011
System Security Lab
Use <<none>> to explicitly not label the specified files. This can be used for files
that have to be labeled at runtime, e.g. files in /var/.
Type Enforcement Files (.te)
These files make the heart of a module. They contain the Type Enforcement rules.
When writing policy modules, you can use standard TE rules or m4 macros. If you look
at listing B.11, you notice that lines that contain a standard rule end with a “;”, whereas
lines with m4 code don’t.
Listing B.11: Appendix/aide.te
1
2 policy module ( aide , 1 . 5 . 0 )
3
4 ########################################
5#
6 # Declarations
7#
8
9 type a i d e t ;
10 type a i d e e x e c t ;
11 a p p l i c a t i o n d o m a i n ( a i d e t , a i d e e x e c t )
12
13 # l o g f i l e s
14 type a i d e l o g t ;
15 l o g g i n g l o g f i l e ( a i d e l o g t )
16
17 # a i d e d a t a b a s e
18 type a i d e d b t ;
19 f i l e s t y p e ( a i d e d b t )
20
21 ########################################
22 #
23 # a i d e l o c a l p o l i c y
24 #
25
26 a l l o w a i d e t s e l f : c a p a b i l i t y { d a c o v e r r i d e fowner } ;
27
28 # d a t a b a s e a c t i o n s
29 m a n a g e f i l e s p a t t e r n ( a i d e t , a i d e d b t , a i d e d b t )
30
31 # l o g s
32 m a n a g e f i l e s p a t t e r n ( a i d e t , a i d e l o g t , a i d e l o g t )
33 l o g g i n g l o g f i l e t r a n s ( a i d e t , a i d e l o g t , f i l e )
95
WS 2010/2011
System Security Lab
34
35
36
37
38
39
40
41
f i l e s r e a d a l l f i l e s ( aide t )
logging send audit msgs ( aide t )
seutil use newrole fds ( aide t )
userdom use user terminals ( aide t )
The first line of a .te file contains the policy module macro. It defines the module name
and version. The rest of the file make the rules discussed in Chapter B.4.3.
Interface Files (.if)
In an interface file you can define macros in m4 language that can be used by other
modules. A reason to use macros is to abstract a bunch of rules that is normally needed
to accomplish a task within a module to a macro name. The advantage of using macros
is that if you change your module, someone else who uses it doesn’t need to take care of
those changes.
Listing B.12: Appendix/aide.if
1 ## <summary>Aide f i l e s y s t e m i n t e g r i t y c h e c k e r </summary>
2
3 ########################################
4 ## <summary>
5 ##
Execute a i d e i n t h e a i d e domain
6 ## </summary>
7 ## <param name=”domain”>
8 ##
<summary>
9 ##
Domain a l l o w e d a c c e s s .
10 ##
</summary>
11 ## </param>
12 #
13 i n t e r f a c e ( ‘ a i d e d o m t r a n s ’ , ‘
14
gen require ( ‘
15
type a i d e t , a i d e e x e c t ;
16
’)
17
18
c o r e c m d s e a r c h b i n ( $1 )
19
d o m t r a n s p a t t e r n ( $1 , a i d e e x e c t , a i d e t )
20 ’ )
21
22 ########################################
23 ## <summary>
24 ##
Execute a i d e programs i n t h e AIDE domain .
96
WS 2010/2011
System Security Lab
25 ## </summary>
27 ##
<summary>
28 ##
29 ##
</summary>
30 ## </param>
31 ## <param name=” r o l e ”>
32 ##
<summary>
33 ##
The r o l e t o a l l o w t h e AIDE domain .
34 ##
</summary>
35 ## </param>
36 #
37 i n t e r f a c e ( ‘ a i d e r u n ’ , ‘
38
gen require ( ‘
39
type a i d e t ;
40
’)
41
42
a i d e d o m t r a n s ( $1 )
43
r o l e $2 t y p e s a i d e t ;
44 ’ )
45
46 ########################################
47 ## <summary>
48 ##
All of the r u l e s r e q u i r e d to administrate
49 ##
an a i d e environment
50 ## </summary>
52 ##
<summary>
53 ##
54 ##
</summary>
55 ## </param>
56 ## <r o l e c a p />
57 #
58 i n t e r f a c e ( ‘ aide admin ’ , ‘
59
gen require ( ‘
60
type a i d e t , a i d e d b t , a i d e l o g t ;
61
’)
62
63
a l l o w $1 a i d e t : p r o c e s s { p t r a c e s i g n a l p e r m s } ;
64
p s p r o c e s s p a t t e r n ( $1 , a i d e t )
65
66
f i l e s l i s t e t c ( $1 )
67
a d m i n p a t t e r n ( $1 , a i d e d b t )
68
97
WS 2010/2011
System Security Lab
69
70
71 ’ )
l o g g i n g l i s t l o g s ( $1 )
a d m i n p a t t e r n ( $1 , a i d e l o g t )
In listing B.12 you can see that there are many comments in the interface file. These
comments are in a special format, which is used to automatically generate interface
documentation as you can see on the Tresys website [refa].
B.4.8. Audit Log
When writing a policy you need to know what rules to implement. Although you should
normally know what the rule should allow or not, you probably won’t manage to get all
necessary rules at once. To make your life easier, you will use tools like audit2allow
that help you analyze the logfiles and create corresponding rules. There is the -w option
of audit2allow which helps at least filtering AVC rules out of the log jungle. Although
those tools are quite helpful, they can also be dangerous since they only show you the
generated rules. Also audit2allow doesn’t play well together with constraints. Since a
rule could match on more than one program, you may want to inspect the situation a
bit further and see if you need to define new domains to separate a process from others.
So we should discuss the AVC log entries a bit, because this is needed for auditing.
Listing B.13: auditing log entry
avc : d e n i e d { w r i t e } f o r p i d =19774 comm=”vim” name=”.y
v i m i n f o . tmp” dev=hda1 i n o =257658 s c o n t e x t=r o o t : s t a f f r : y
s t a f f t t c o n t e x t=r o o t : o b j e c t r : s y s a d m h o m e d i r t t c l a s s=y
file
In listing B.13 you see an AVC denial. This logfile entry consists of several parts:
• avc: – this shows that the entry is SELinux relevant, it has been caused by the
AVC
• denied – an action has been denied, sometimes here may also be a “granted”, which
shows that an action has been explicitly allowed
• write – the type of access that was denied
• for pid=19774 – shows the PID of the process whose action was denied
• comm=”vim” – the command “vim” tried to access an object
• name=”.viminfo.tmp” – the command tried to access the object “.viminfo.tmp”
• dev=hda1 – the partition on which the object is stored
• ino=257658 – the inode number of the file
• scontext=root:staff r:staff t – the security context of the subject (source context)
98
WS 2010/2011
System Security Lab
• tcontext=root:object r:sysadm home dir t – the security context of the object (target context)
• tclass=file – the objects class
Listing B.14: TE rule created by audit2allow from the log entry in listing B.13
1 #============= s t a f f t ==============
2 allow s t a f f t sysadm home dir t : f i l e write ;
B.5. Basic Commands
There are even more utilities available in the libselinux and policycoreutils packages than
mentioned here, but this list should be enough to accomplish most tasks. If you need
further information on a command you should read the corresponding manpage [man]
or use the --help option of the command.
• sestatus – This command gives you information whether selinux is enabled or not,
in which mode and what policy is loaded.
• seinfo – seinfo gives information about the currently loaded policy.
• setenforce/getenforce – getenforce tells you if the system is currently in enforcing or permissive mode. With setenforce you can enable or disable enforcing
mode.
• newrole – With newrole you can change your current security context. You
will probably need this command to change your current role, e.g. newrole -r
sysadm r.
• audit2allow – This tool analyzes a given logfile for deny messages from the AVC
and creates TE rules. Some important options are:
– -a – uses the audit log as input (normally used)
– -d – uses dmesg as input (sometimes needed when analyzing messages from
the boot process, before auditd is loaded)
– -i logfile – could be used on /var/log/messages for example to have similar
results as -d
– -l – you will always want to use this, only considers log messages after last
policy reload (e.g. semodule -R)
– -R – generates reference policy rules (uses macros if possible instead of plain
rules)
– -m modulename – specify a modulename (used to generate the policy module
statement at the beginning of a .te file)
99
WS 2010/2011
System Security Lab
• sesearch – A tool to search policies in various formats. You can search for specific
types of rules (allow, neverallow, type rules), for a specified type. So you can
search for nearly everything a policy defines.
• semodule – One of the most important tools when writing your own policy modules. Here are the most important options:
– -R – reloads the policy
– -i module.pp – install a new policy module
– -u module.pp – upgrade an existing policy module
– -r module – remove a module
– -l – lists the currently loaded modules
• semanage – This utility enables you to manage many every-day tasks. It is used
to create new SELinux users or to manage what linux users are allowed to login as
a specify SELinux user. It is also used to manage network ports (e.g. allow apache
to listen on port 81). With newer reference policies you can also set a per-domain
permissive mode with semanage.
It can do even more things. As always you can find out about this in the manpage. [man]
• setsebool/getsebool – Those tools are used to view or set the status of a SELinux
boolean value.
• chcon – This command sets the security context of a file. It can either be used to
set the complete security context or portions of it(user, type, . . . ).
• restorecon – This command restores the default security context for a file. It is
often used to set security contexts when writing new policy modules.
• common linux commands – Most commands like ls, ps or id are normally
patched on SELinux systems to show security contexts. They have the extra
option -Z.
Not a command, but also important to know is the libselinux library, which provides
interfaces for most tasks you need done when programming an SELinux-aware application. The usage of this library is heavily recommended to circumvent problems that may
occur if something within SELinux changes. Most of the above mentioned applications
already use this library.
B.6. Usage Examples
Now that we have defined most of the important commands and terms let’s have a look
at how things are done on SELinux by some examples.
100
WS 2010/2011
System Security Lab
B.6.1. Adding a User
Adding a user on a classic linux system is quite an easy task. Using a program like
useradd or even doing it manually doesn’t require more than a minute. On an SELinux
system there may be a bit more work to do. If you just want to add a standard user, you
probably won’t have to care about anything else. If you want the user to have special
permissions, you will probably have to configure a new SELinux user and give it access
to another role.
Suppose you want to add a new user called newuser. The user should have access
to the roles staff r and user r(Note, that access to those two roles does normally not
make sense, since they are nearly the same.).
Listing B.15: adding a new user to your system
1 root@SELinux ˜ # u s e r a d d −m newuser
2 root@SELinux ˜ # semanage u s e r −−r o l e s ’ u s e r r s t a f f r ’ −−addy
newuser u
3 root@SELinux ˜ # semanage l o g i n −−add −−s e u s e r newuser u y
newuser
4 root@SELinux ˜ # passwd newuser
5
New UNIX password :
6
BAD PASSWORD: i t i s WAY t o o s h o r t
7
Retype new UNIX password :
8
passwd : password updated s u c c e s s f u l l y
9 root@SELinux ˜ # chcon −R −u newuser u /home/ newuser /
With useradd we add the user newuser to the linux system.
The semanage user command adds an SELinux user to the system and assigns the
roles user r and staff r to this user.
The semanage login command connects the SELinux user newuser u to the linux
user newuser.
passwd sets the password for the user as usual.
Last, but not least, we change the user portion of the security context for the user’s
homedirectory. This may be necessary when having UBAC enabled.
B.6.2. Using Booleans
Listing B.16: listing booleans with getsebool
1
2
3
4
5
6
7
root@SELinux ˜ # g e t s e b o o l −a
...
u s e n f s h o m e d i r s −−> o f f
u s e s a m b a h o m e d i r s −−> o f f
u s e r d i r e c t m o u s e −−> o f f
u s e r d m e s g −−> o f f
u s e r p i n g −−> o f f
101
WS 2010/2011
System Security Lab
8 u s e r r w n o e x a t t r f i l e −−> o f f
9 ...
10
root@SELinux ˜ # s e t s e b o o l −P u s e r d m e s g=on
11
root@SELinux ˜ # g e t s e b o o l u s e r d m e s g
12 u s e r d m e s g −−> on
In Listing B.16 we see the (shortened) output of getsebool and setsebool. Here we
set the boolean user dmesg. This boolean, if enabled, allows a common user to use the
dmesg command. We also use the -P option to make the setting permanent, so it will
survive a reboot of the system.
B.6.3. Inspecting the logfiles
The logfiles that are important for SELinux administrators may vary on different linux
distributions. Normally you run the auditd [aud] daemon on SELinux systems, which
then logs to the file configured in /etc/audit/auditd.conf. On a gentoo system this is
normally /var/log/audit/audit.log.
If auditd is not running, e.g. during the boot process before auditd gets started, or
if you just don’t use it, all the SELinux relevant log messages will be handled by the
syslog daemon. On a gentoo system with syslog-ng this is normally /var/log/messages.
Whatever logfile you inspect, the most interesting entries will probably be the ones
made by the AVC. If you would have to comb through the audit.log or syslog, you won’t
get much work done, since there will be much more entries than you need. Normally
you only need to check the logfiles if something doesn’t work as expected and you
want to change the policy. To determine what didn’t work, we will use the command
audit2allow.
Listing B.17: listing AVC log entries with audit2allow
1
root@SELinux ˜ # semodule −R
2
root@SELinux ˜ # a u d i t 2 a l l o w −l a
3 #============= u s e r t ==============
4 allow u s e r t proc kmsg t : f i l e g e t a t t r ;
5
root@SELinux ˜ # a u d i t 2 a l l o w −laR
6
7 require {
8
type u s e r t ;
9 }
10
11 #============= u s e r t ==============
12 k e r n e l g e t a t t r m e s s a g e i f ( u s e r t )
13
root@SELinux ˜ # a u d i t 2 a l l o w −l a e
14 #============= u s e r t ==============
15 # a u d i t ( 1 2 3 0 7 8 7 7 8 9 . 2 3 6 : 4 1 ) :
16 # s c o n t e x t =” u s e r u : u s e r r : u s e r t ” t c o n t e x t =”s y s t e m u : y
o b j e c t r : proc kmsg t ”
102
WS 2010/2011
System Security Lab
17 #
18 #
19 #
20
21
22
23
c l a s s =” f i l e ” perms=” g e t a t t r ”
comm=” l s ” exe =”” path=””
message=”type=AVC msg=a u d i t ( 1 2 3 0 7 8 7 7 8 9 . 2 3 6 : 4 1 ) : avc : y
denied { g e t a t t r } f o r
#
p i d =4961 comm=” l s ” path=”/ p r o c /kmsg” dev=p r o c i n o y
=4026531948
#
s c o n t e x t=u s e r u : u s e r r : u s e r t t c o n t e x t=s y s t e m u : o b j e c t r : y
proc kmsg t
#
t c l a s s= f i l e ”
allow u s e r t proc kmsg t : f i l e g e t a t t r ;
In Listing B.17 we see different calls of the audit2allow command. Before using audit2allow we reload the policy with semodule -R to make audit2allow with option -l
only care about denials from now on. The first time we use audit2allow with the options
-l and -a. -a tells audit2allow to use the auditlog as input. -l is to only consider entries
since the last policy reload. We see a rule that, if used, would allow the user t domain
to get the attributes of /proc/kmsg.
The next use of audit2allow has the additional option -R. This option generates “reference policy style” output. That means it will search through interface files and see
if it finds a macro that does exactly the same as an allow rule. It also generates the
needed require commands. (Note: there is a small flaw in some older versions
which prints the require statement twice, sometimes even 2 slightly different
require-blocks.)
To see why this rule was really generated we use the -e option in the third use.
audit2allow prints the corresponding log message optically prepared. This can be very
useful to see if you really want to use this rule or need to achieve your goal differently.
B.6.4. Writing a new Policy Module
Most likely you won’t edit the base policy unless you’re a maintainer of a linux distribution. But maybe you want the policy behave different. In this case you should probably
rebuild your base policy without the part that is responsible for this certain behaviour
and compile it as a module. At least that was one of the main reasons for inventing the
reference policy.
If you need to write a completely new module, you will also want to make use of the
audit2allow tool.
Listing B.18: creating a new policy module
root@SELinux ˜/ userkmsg # a u d i t 2 a l l o w −laRm userkmsg −o y
userkmsg . t e
2
root@SELinux ˜/ userkmsg # b z c a t / u s r / s h a r e / doc / s e l i n u x −base y
−p o l i c y −20081210/ M a k e f i l e . example . bz2 > M a k e f i l e
3
root@SELinux ˜/ userkmsg # l s
4 M a k e f i l e userkmsg . t e
1
103
WS 2010/2011
System Security Lab
5
6
7
8
9
10
11
12
13
14
15
16
17
18
root@SELinux ˜/ userkmsg # #check userkmsg . t e i f i t r e a l l y y
d o e s what you want
root@SELinux ˜/ userkmsg # make
Compiling s t r i c t userkmsg module
/ u s r / b i n / checkmodule : l o a d i n g p o l i c y c o n f i g u r a t i o n from tmp/y
userkmsg . tmp
/ u s r / b i n / checkmodule :
p o l i c y c o n f i g u r a t i o n loaded
/ u s r / b i n / checkmodule : w r i t i n g b i n a r y r e p r e s e n t a t i o n ( v e r s i o n y
8 ) t o tmp/ userkmsg . mod
C r e a t i n g s t r i c t userkmsg . pp p o l i c y package
rm tmp/ userkmsg . mod . f c tmp/ userkmsg . mod
root@SELinux ˜/ userkmsg # l s
M a k e f i l e tmp userkmsg . f c userkmsg . i f userkmsg . pp y
userkmsg . t e
root@SELinux ˜/ userkmsg # semodule − i userkmsg . pp
root@SELinux ˜/ userkmsg # semodule − l | g r e p userkmsg
userkmsg
1.0
root@SELinux ˜/ userkmsg #
After the .te file has been generated by audit2allow, be sure to check it manually if it
really does what you want. An example Makefile is, at least on Gentoo Linux, installed
together with the base policy and creates the .if and .fc files automatically.
104
References SELinux Introduction
[aud] Homepage of the auditd daemon.
http://people.redhat.com/sgrubb/audit/.
[bye] Selinux by example, book by three authors that are quite involved in the development of selinux, not free.
http://www.selinuxbyexample.com/.
[gen] Gentoo selinux handbook.
http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.
xml.
[hpf] homepage of flask.
http://www.cs.utah.edu/flux/fluke/html/flask.html.
[lsm] Lsm design.
http://www.usenix.org/event/sec02/wright.html.
[man] Linux man pages.
http://linuxmanpages.com/.
[obj] list of object classes and permissions.
http://oss.tresys.com/projects/refpolicy/wiki/ObjectClassesPerms.
[refa] interface documentation of the reference policy.
http://oss.tresys.com/docs/refpolicy/api/.
[refb] reference policy from tresys.
http://oss.tresys.com/projects/refpolicy.
[tea]
statement of assurance regarding type enforcement from secure computing.
http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf.
105
Abbreviations
OS Operating System
VM Virtual Machine
DSL DamnSmallLinux
NAT Network Address Translation
HIF Host Interface Networking
VMM Virtual Machine Monitor
API Application Programming Interface
EOF end of file
ACL Access Control Lists
AD Active Directory
SID Security Identifier
UID User ID
DACL Discretionary Access Control List
SACL System Access Control List
ACE Access Control Entries
CBC Cipher Block Chaining
UAC User Account Control
MLS Multilevel Security
DOS Denial of Service
GRUB General Unified Boot Loader
BCD Boot Configuration Data
MBR Master Boot Record
GID Group ID
107
WS 2010/2011
System Security Lab
CHS Cylinder Head Sector
I/O Input / Output
PCB Process Control Block
IPC Inter-Process Communication
PID Process ID
LIFO Last In First Out
LSB Least Significant Byte
ASLR Address Space Layout Randomization
MAC Mandatory Access Control
TE Type Enforcement
108

System Security II (141341) - Ruhr

Transcription

Similar documents

48 hours, 2 people, all of nRW, 48 euros

Find out more.

The SELinux Notebook, 4th Edition Â©2014

JUN 2006 issue of TOE - Channel Islands PC Users Group

Memory analysis of the KBeast Linux rootkit

Malware memory analysis of the Jynx2 Linux rootkit (Part 1)

Liferay in Action

JWC`s 10th ANNIVERSARY - Joint Warfare Centre

CA SiteMinder Web Agent Installation Guide for IIS