Transcript Seoul_Uni

Security-Enhanced Linux
References
1.
2.
3.
Implementation of Security-Enhanced
Linux by Yue Cui, Xiang Sha, Li Song
Security Enhanced Linux by David
Quigley (Fedora)
Security-Enhanced Linux by Joseph A
LaConte
Background
Security-Enhanced Linux is a NSA (National
Security Agency) backed research project.
Goals:



Promote Security Research
Address OS Security
Demonstrate MAC (Mandatory Access Controls) through
Type Enforcement® technology in a mainstream os
Note: SELinux project is not intended as a complete
security solution for Linux
SELinux Background
1985: LOCK system(early Type Enforcement)
– Secure Ada project through Honeywell
1990:
DTMach / DTOS
DTMach – Mach-based prototype
DTOS (Distributed Trusted Operating System)
1995:
Utah Fluke / Flask
Fluke* - University of Utah's research operating system
1999: 2.2 Linux Kernel (patch)
2001: 2.4 Linux Kernel (patch)
2002: LSM
2003: 2.6 Linux Kernel (mainline)
2006: Full network labeling
Why Linux?
Linux is an open source project with many
developers; therefore:



Provides an opportunity for more
research.
Allows application/testing in a
mainstream os.
Improves security in an existing os.
SELinux
Security-Enhanced Linux (SELinux)


Uses the Linux Security Modules (LSM)
framework to implement flexible Mandatory
Access Control (MAC) in the Linux kernel.
Restricts privileges of user programs and
system servers using security labels and an
administratively-defined policy.
MAC versus DAC
Discretionary Access Control (DAC) is the standard
security model for Linux. In this model, access
privileges are based on the user identity and object
ownership.
Mandatory Access Control (MAC) limits privileges for
subjects (processes) and objects (file, socket,
device, etc).
Please note: SELinux does not change any existing security in the Linux
environment; rather, SELinux extends the security model to include
Mandatory Access Control (i.e. both MAC and DAC are enforced in the
SELinux environment).
SELinux vs. traditional Linux


SELinux enforces MAC policies that
confine user programs and system
servers to the minimum amount of
privilege they require to do their jobs
The ability of these user programs and
system daemons to cause harm when
compromised(via buffer overflow for
example) is reduced or eliminated.
SELinux vs. traditional Linux


The confinement mechanism operates
independently of the traditional Linux
access control mechanisms
It has no concept of a “root” super-user,
and does not share the well-known
shortcomings of the traditional Linux
security mechanisms(such as a
dependence on setuid/setgid binaries)
SELinux vs. traditional Linux

The security of traditional Linux



Depends on the correctness of the kernel, all the
privileged applications, and each of their
configurations
A problem in any one of these areas may allow
the compromise of the entire system
The security of SELinux


Depends on the correctness of the kernel and its
security policy configuration
While problems may allow the limited compromise
of individual user programs and system daemons,
they do not pose a threat to the security of other
user programs and system daemons or to the
security of the system as a whole
Security-Enhanced Linux
Security Policies are implemented
using:

Type Enforcement® (TE)
(introduced in 1985 by Boebert and Kain)


Role-based access control (RBAC)
Multi-level Security
Security Model in SELinux

Type Enforcement (TE) model


Provides fine-grained control over
processes and objects in the system
Role-Based Access Control (RBAC)
model

Provides a higher level of abstraction
to simplify user management
TE model

Traditional TE model




Binds a security attribute called a domain
to each process and a type to each object
Treats all processes in the same domain
identically and all objects that have the
same type identically
A pair of access matrices specify how
domains can access types and how
domains can interact with other domains
Each user is authorized to operate in
certain domains
TE model

SELinux TE model





Uses a single type attribute in the security
context for both processes and objects
A domain is simply a type that can be associated
with a process.
Uses the security class information provided by
the Flask architecture
Security classes can distinguish objects of the
same type.
Does not directly associate users with domains;
uses RBAC model to provide an additional layer
of abstraction between users and domains
Type Enforcement

Object(s): items in a system that are acted upon (files, IPC,
sockets, etc….)

Subject(s): process that are requesting access to an object

All Objects and Subjects contain a security context

Security Context(s) are composed of four parts

All Security Context components are checked against the policy
to see if access is allowed.

Type is the base component while role and user are used to
further restrict type enforcement
Security Contexts
system_u:object_r:passwd_exec_t:s0:c0.c2-s2:c0.c1
user:role:type:sensitivity[:category,…][-sensitivity[:category,…]]
TE Access Control
allow user_t bin_t : file {read execute write getattr setattr}




Source type(s): The domain type of the process accessing the
object
Target type(s): The type of the object being accessed by the
process
Object class(es): The class of object to permit access to
Permission(s): The kind of access permitted for the indicated
object class
Domain Transitions

Analogous to SetUID programs

Joe running as user_t (untrusted user) needs to change his
password. How does Joe change his password?

allow user_t passwd_exec_t : file {getattr execute}

allow passwd_t passwd_exec_t : file entrypoint

allow user_t passwd_t : process transition

What does this solve? Restricts trusted domain passwd_t
and allows user_t to transition to it.

Implicit domain transitions provided via type_transition.
Users & Roles






First and second component of a security context
SELinux usernames and DAC usernames are not
synonymous
Semanage is used to maintain mappings of DAC to
SELinux usernames.
Roles are collections of types geared towards a purpose
Roles can be used to further restrict actions on the system
SELinux usernames are granted roles in the system
Role-Based Access Control
Each user gets a set of roles
Each role is assigned a set of TE domains.
Note: users are not identified by Linux uids; instead a
user identity attribute is used in the security context.
RBAC model

Traditional RBAC model


authorizes users to act in certain roles and
assigns a set of permissions to each role
SELinux RBAC model


authorizes each user for a set of roles,
each role for a set of TE domains
maintains a role attribute in the security
context of each process
Policies
Configuration consists of:





Flask definitions
TE and RBAC
declarations and rules
User declarations
Constraint definitions
Security context
specifications.
Policies
TE Statements







Attribute Declarations
Type Declarations
TE Transition Rules
TE Change Rules
TE Access Vector
Rules
TE Access Vector
Assertions
Type Member Rules
RBAC Statements



Role Declarations and
Dominance
Role Allow Rules
Role Transition Rules
Policies
Syntax for TE and RBAC declarations*
Syntax for type declarations*
* Smally, Stephen January 2003.
Policies
Bleher, Thomas November 30, 2004
Limitations
Performance Overhead – approximately 7%.
Complexity – requires in-depth knowledge of the
operating system, the security policies, and the
operating environment.
Maintenance – policy fine-tuning, changes required for
changes to the system.
Benefit of SELinux

The SELinux’s new features are
designed to


Enforce the separation of information
based on confidentiality and integrity
requirements
Prevent processes from
reading data and programs,
 tampering with data and programs,
 executing untrustworthy programs, or
 interfering with other processes in violation of
the system security policy

MLS

MLS portion of Security Context is composed of 4
parts





Low/High
Sensitivity/Category
Includes syntax to define dominance of security
levels
Subjects with range of levels considered trusted
subjects
Implements a variation of Bell-La Padula
Linux Security Modules (LSM)





Kernel framework for security modules
Provides a set of hooks to implement further
security checks
Usually placed after existing DAC checks and
before resource access
Implications? SELinux check is not called if the
DAC fails
Makes auditing difficult at times.
SELinux LSM Module
Policy Management
Interface
User
Space
Kernel
Space
Selinux Filesystem
Various
Kernel
Object
Managers
LSM Hooks
Access
Vector
Cache
Cache Miss
Yes or No?
Security Server
(Policy Rules and
Access Decision Logic)
SELinux LSM Module
Figure taken from SELinux
by Example
Userspace Object Managers
User-Space
Object Manager
Access
Vector
Cache
Allow
access?
Yes or No?
libselinux
Policy Management
Interface
User Space
Kernel Space
Selinux Filesystem
Access
Vector
Cache
Figure taken from SELinux by
Example
Cache Miss
Yes or No?
Security Server
(Policy Rules and
Access Decision Logic)
Policy Server
User-Space
Object Manager
Access
Vector
Cache
Cache Miss?
User-Space
Security Server
Load
Policy
User
Management
Policy
Yes or No?
Policy
Management
Server
libselinux
Policy Server
User Space
Kernel Space
Selinux Filesystem
Access
Vector
Cache
Figure taken from SELinux by
Example
Cache Miss
Yes or No?
Security Server
(Policy Rules and
Access Decision Logic)
Interface
Policy Language
Policy
Source
Modules
policy.conf
Checkpolicy
Classes and Permissions
Binary Policy
File
Make, Scripts,
M4, and so on
Type Enforcement
Statements
(Types, TE Rules,
Roles, Users)
load_policy
Kernel Space
Selinux Filesystem
Constraints
Resource labeling
Specifications
Access
Vector
Cache
Security Server
Cache
(Policy Rules and
Miss
Yes or No? Access Decision Logic)
SELinux LSM Module
Figure taken from SELinux by
Example
Object Classes

Represents resources of a certain kind

Policy must include declarations for all object
classes

Classes

File related (blk_file, chr_file, dir, fd …)

Network related (socket, packet_socket, rawip_socket, …)

IPC related (ipc, msg, msgq, sem, shm)

Misc Classes (capability, process, security, system)
Permissions




Specific to a particular Object Class
Includes traditional Linux permissions
Extends existing permissions to be finer
grained
Includes SELinux specific permissions for
labeling
Type Enforcement

Several major keywords

type

attribute

typeattribute

typealias

allow

dontaudit

auditallow

neverallow
Type Enforcement
attribute file_type;
attribute httpdcontent;
#These two statements...
type httpd_user_content_t;
typeattribute httpd_user_content_t file_type, httpdcontent;
#are equivalent to this one
type httpd_user_content_t, file_type, httpdcontent;
#These two statements...
type mozilla_t, domain;
typealias mozilla_t alias netscape_t;
#are equivalent to this one
type mozilla_t alias netscape_t, domain;
Type Enforcement
rule_name src_type_set target_type_set : class_set perm_set;
#valid
allow user_t bin_t : file { read getattr } ;
allow user_t bin_t : dir { read getattr search } ;
#invalid since file does not have a search permission
allow user_t bin_t { file dir } {read getattr search } ;
#don’t audit when this access is denied
dontaudit httpd_t etc_t : dir search ;
#audit when this access is allowed
#by default allowed access is not audited
auditallow domain shadow_t : file write ;
#This statement may never be allowed by any rule
neverallow user_t shadow_t : file write
allow user_t bin_t : { file dir } * ;
allow user_t bin_t : file ~{ write setattr ioctl };
Type Enforcement

Type Transitions
 type_transition
 type_change
#These two statements...
type_transition user_t passwd_exec_t : process passwd_t;
type_transition sysadm_t passwd_exec_t : process passwd_t;
#are equivalent to this one
type_transition { user_t sysadm_t } : process passwd_t;
#This domain transition rule…
type_transition init_t apache_exec_t : process apache_t ;
#would require at least the follow 3 allow rules to succeed
allow init_t apache_exec_t : file execute ;
allow init_t apache_t : process transition;
allow apache_t apache_exec_t : file entrypoint ;
RBAC

Adds 2 components to security context



user
role
Adds 3 policy language keywords



allow (different than AVC allow)
role_transition (similar to
type_transition)
dominance
RBAC Example
#valid security context
joe:user_r:passwd_t
#role user_r assigned to user joe
user joe roles { user_r };
#equivalent to this one
role user_r types { user_t passwd_t };
allow staff_r sysadm_r;
role_transition sysadm_r http_exec_t system_r;
#super_r inherits all types from sysadm_r and secadm_r
dominance { role super_r { role sysadm_r; role secadm_r; }}
Multilevel Security


Policy Declares Levels and categories
applies constraints on objects and
permissions with MLS dominance keywords




==, !=, eq, dom, domby, incomp
mlsconstrain file {create relabelto } { l2 eq
h2 }
mlsvalidatetrans transitions between
levels
Still requires a lot of work
Conditional Policies



Allows enabling/disabling portions of policy
Booleans define in policy
Logical operations allowed








&&
||
^
!
==
!=
Does not support nested conditionals
Booleans modified through special applications or
SELinuxfs
Configuration for running insmod


Figure 4 shows a portion of the policy
configuration that allows the
administrator domain (sysadm_t) to run
the insmod program to insert kernel
modules.
The insmod program is labeled with the
insmod_exec_t type and runs in the
insmod_t domain.
Figure 4: Configuration for running insmod
Configuration for running insmod

allow sysadm_t insmod_exec_t :file
x_file_perms;


allow sysadm_t insmod_t :process transition;


allows the sysadm_t domain to run the insmod
program.
allows the sysadm_t domain to transition to the
insmod_t domain.
allow insmod_t insmod_exec_t :process
{entrypoint, execute }

allows the insmod_t domain to be entered by the
insmod program and to execute code from this
program.
Configuration for running insmod

allow insmod_t sysadm_t :fd inherit_fd_perms;


allow insmod_t self :capability sys_module;


allows the insmod_t domain to inherit and use
file descriptors from the sysadm_t domain.
allows the insmod_t domain to use the
CAP_SYS_MODULE capability.
allow insmod_t sysadm_t :process sigchild;

allows the insmod_t domain to send the
SIGCHLD signal to sysadm_t when it exits.
Reference Policy


Maintained by NSA and FC Mailing Lists
Compiles into three versions


Strict, Targeted, MLS
Stats








Version .18
Object Classes 55
Common Permissions 3, Permission 205
Types 1589
allow 372755, auditallow 12, dontaudit 238663
type_transition 2657, type_change 68
roles 6, RBAC allow 6, role_transition 97, users 3
bools 70
Components





checkpolicy
libselinux
libsemanage
libsepol
policycoreutils
libselinux



Used by SELinux aware applications
Houses user space AVC
Contains functions to



calculate AVCs
get/set/create contexts
query policy engine
libsemanage


Used to query and configure state of a
running system
Provides functions to query/modify







login names
users
network ports/interfaces
file contexts
level translations
roles
etc.
SELinuxfs




Interface between userspace and kernel
Used by libselinux and libsemanage to
communicate requests with the kernel
Provides a quick and easy interface for
humans
Usually not used directly from programs
policycoreutils

SELinux Management and policy analysis tools










audit2allow
audit2why
load_policy
newrole
restorecon
semanage
semodule
sestatus
setbool
etc...
Distributions






Fedora Core 3 and later
Debian
Gentoo
SuSe
SE-BSD
SE-MACH
Installation

Where to get the copy?

Free download from
http://www.nsa.gov/selinux/

Components of SELinux Distribution


Patches to the Linux kernel (based on
kernel 2.4.18)
Patches to a number of standard tools
and utilities, support files, and
documentation
Installation

Need to have an existing Redhat Linux



Redhat 7.2 or later will be better
SELinux does not provide a modified
xdm/gdm/kdm to set the security
context for the user session
Environment we use:

Redhat 7.3
Installation


Download the installation package
(lsm-2.4-selinux-2002053110.tgz)
Unzip the file, we got two folders
# /lsm2.4 and /selinux

The quick installation steps are as
followings
Installation

Edit policy/users for your users


Be sure to authorize at least one user for the
system administrator role (sysadm_r)
Edit the default_context and cron_context
files in utils/appconfig for your users


security context has the syntax user:role:domain or
user:role:type
e.g. root:sysadm_r:sysadm_t or root:user_r:user_t
Installation

Edit policy/file_contexts/
{types.fc,program/*.fc} for your site


Check the pathnames against your file system
layout
Ensure that your current configuration is not
set up to run an X Display Manager (xdm,
gdm, kdm)


he default runlevel specified in
/etc/inittab should be runlevel 3 (Full multiuser
mode)
Installation

Perform the quick install



make quickinstall
When the kernel configuration menu is
displayed, configure the kernel for your
hardware as appropriate
Configure your boot manager to boot
the SELinux kernel

e.g. if you use the LILO boot manager,
configure /etc/lilo.conf, and run /sbin/lilo
Installation


Boot the SELinux kernel and login in the
sysadm_r role and sysadm_t domain(e.g.
using “root”)
Run setfiles again to ensure that files
created by the old kernel during the
shutdown are properly labeled



cd policy
make relabel
Add /usr/local/selinux/bin and
/usr/local/selinux/sbin to your path for the
modified utilities
Installation


After installation, we can try the following
commands to see if it is installed correctly
‘ ps -e --context ‘



The second column should show the security
context of each process
Has the syntax user:role:domain or user:role:type
‘ ls -- context / ‘

The fourth column should show the security context
of each file or directory in /
Installation

ps -e --context
PID SID
CONTEXT
COMMAND
1
7
system_u:system_r:init_t
init [3]
2
7
system_r:system_r:init_t
[keventd]
... …
…
…
855 245
system_u:system_r:local_login_t login --root
856 244
system_u:system_r:getty_t
/sbin/mingetty tty2
857 244
system_u:system_r:getty_t
/sbin/mingetty tty3
858 244
system_u:system_r:getty_t
/sbin/mingetty tty4
859 244
system_u:system_r:getty_t
/sbin/mingetty tty5
860 244
system_u:system_r:getty_t
/sbin/mingetty tty6
863 246
root:sysadm_r:sysadm_t
-bash
910 246
root:sysadm_r:sysadm_t
ps -e --context
Installation
ls
-context
/
drwxr-xr-x root root
system_u:object_r:bin_t

drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
dr-xr-xr-x
drwxr-x--drwxr-xr-x
drwxrwxrwx
drwxr-xr-x
drwxr-xr-x
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
system_u:object_r:boot_t
system_u:object_r:device_t
system_u:object_r:etc_t
system_u:object_r:user_home_t
system_u:object_r:file_t
system_u:object_r:lib_t
system_u:object_r:lost_found_t
system_u:object_r:file_t
system_u:object_r:file_t
system_u:object_r:file_t
system_u:object_r:proc_t
system_u:object_r:sysadm_home_t
system_u:object_r:sbin_t
system_u:object_r:tmp_t
system_u:object_r:usr_t
system_u:object_r:var_t
bin
boot
dev
etc
home
initrd
lib
lost+found
misc
mnt
opt
proc
root
sbin
tmp
usr
var
Customizing the policy

What we can do






Adding users
Adding permissions
Adding programs to an existing domain
Creating a new domain
Creating a new type
Creating a new role
Customizing the policy

Adding users


If we want to add a user steve to the
system who should be authorized for both
the user_r and sysadm_r roles
Add an entry to the policy/users files:
user steve roles { user_r sysadm_r }

Run make load to reload the policy
Customizing the policy

Adding programs to an existing domain

Locate an appropriate domain by

examining the existing programs domains under
policy/domains/program

examining how existing programs are associated
with the executable types for those domains in
policy/file_contexts/program

Relabel the program by
# make relabel
Customizing the policy

Creating a new role



Create a new domain to be used as the
initial login domain for the role
Define role declaration in policy/rbac
Reload the policy
# make load

Add an entry for the role in
/etc/security/default_type
References

SELinux installation help

Stephen Smalley, “Configuring the SELinux
Policy”, 2002

Stephen Smalley and Timothy Fraser, “A
Security Policy Configuration for the SecurityEnhanced Linux”, 2001

http://www.nsa.gov/selinux
References
National Security Agency. Security Enhanced Linux, December
8, 2004. http://www.nsa.gov/selinux/index.cfm
Thompson, Kerry. The UnOfficial SELinux FAQ, June 15, 2004.
http://www.crypt.gen.nz/selinux/faq.html
Wade, Karsten. Fedora Core 3 SELinux FAQ, November 9, 2004.
http://fedora.redhat.com/docs/selinux-faq-fc3/index.html
Smally, Stephen. Configuring the SELinux Policy, February 2002,
revised January 2003. NAI Labs.
<URL:http://www.nsa.gov/selinux/papers/policy2-abs.cfm>
Secure Computing Corporation. The Origin of Sidewinder® G2
Firewall, December 8, 2004.
http://www.securecomputing.com/index.cfm?skey=1024
References
OSDGroup LLC. Module 13 – SELinux Overview, December 8,
2004.
http://www.bradfordlearning.com/en/courseware/sample_ch
apters/se_linux_sample_chapter.pdf
SourceFORGE.net. SELinux Background, December 8, 2004.
http://selinux.sourceforge.net/background.php3
Hallyn, Serge Edward. Domain and Type Enforcement in Linux.
The College of William and Mary in Virginia.
<URL:http://www.cs.wm.edu/~kearns/dissertations.d/serge.
pdf>
Bleher, Thomas. Source file: domains/program/apache.te
(patch), November 30, 2004.
<URL:http://www.cip.ifi.lmu.de/~bleher/cgibin/archzoom.cgi/[email protected]/policy--suse--0-patch-12?log>
More Information

SELinux Homepage: www.nsa.gov/selinux

SELinux Mailing list:
http://www.nsa.gov/selinux/info/list.cfm?Men
uID=41.1.1.9

Redhat SELinux Mailing List:
http://www.redhat.com/mailman/listinfo/fedo
ra-selinux-list

Fedora SELinux Wiki:
http://fedoraproject.org/wiki/SELinux