Transcript Implementing SELinux as a Linux Security Module

Implementing SELinux as a
Linux Security Module
By
Stephen Smalley
Chris Vance & Wayne Salamon
Presentation by:
KASHIF HASAN
[email protected]
Background
Security-Enhanced Linux(SELinux) 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( Mother of core SELinux architecture)
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.
Why 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.
• 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
SELinux Security Policies
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
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.
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
libselinux
Allow
access?
Yes or
No?
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
libselinux
Cache Miss?
User-Space
Security Server
Load
Policy
User
Management
Policy
Yes or
No?
Policy
Management
Server
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
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;
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; }}
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;
– allows the sysadm_t domain to run the insmod program.
• allow sysadm_t insmod_t :process transition;
– 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;
– allows the insmod_t domain to inherit and use file
descriptors from the sysadm_t domain.
• allow insmod_t self :capability sys_module;
– 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.
LSM Hooks
• Hooks are divided into following categories
–
–
–
–
–
–
Task Hooks
Program Loading Hooks
IPC Hooks
File System Hooks
Network Hooks
Other Hooks
Task Hooks
• Manage process security information
• Control process operations
– Inter-process operations (e.g. kill)
– Privileged operations (e.g. setuid)
– Resource management (e.g. setrlimit, nice)
– Also mediates the ability to query another task’s state (e.g.
getpgid, getscheduler)
• Hooks have full task life-cycle coverage
– create() if task can spawn children
– kill() is consulted to verify that the task can signal its parent
– alloc_security() for a new security field
– free_security() releases the security field
– etc.
Program Loading Hooks
• Called at critical points during the processing of an execve
operation
• Security field in linux_binprm structure
• Hooks are to
– Initialize security information
– Perform access control prior to program loading
– Update security information after program has been loaded
• During a execve process
– alloc_security() to allocate security field
– set_security() to save security information to security field
– compute_creds() to calculate the task’s new credentials
– free_security() to free the field
IPC Hooks
• Security fields added to
– Common IPC data substructure kern_ipc_perm
– msg_msg structures for individual messages
• Hook in ipcperms for permission check
• Additional hooks in individual IPC operations for
fine grained control
– Message queues
– Shared memory segments
– Semaphores
IPC Hooks
• For example
– shmctl(), semctl() and msgctl() are mediated by
shm_shmctl(), sem_semctl(), and msg_queue_msgctl()
LSM hooks
– Attempt to change a semaphore count is protected by
sem_semop()
– Attaching to a shared memoty segment is protected by
shm_shmat()
File System Hooks
• Three sets of hooks
– Super block hooks
– Inode hooks
– File hooks
• Security fields into associated structures
– super_block
– inode
– file
File System Hooks
— Super Block Hooks
• Secutiry field in super_block structure
• Control operations such as mounting,
unmounting or obtaining file system statistics
• For example
– sb_statfs() hook checks permission when a task
attempts to obtain a file system’s statistics
– sb_mount() for mounting a file system
– sb_umount() for unmounting a file system
File System Hooks — Inode Hooks
• Inserted into different inode operations
–
–
–
–
create
link/unlink
mkdir
etc.
• For example
– inode_permission() is called to respect kernel DAC
infrastructure
– inode_symlink() to check if creation of symlink is permitted
– inode_mkdir() to check for permission of directory creation
File System Hooks — File Hooks
• Perform additional checking on file operations,
and operations such as fnctl, ioctl and mmap
• For example
– file_permission() can be used to revalidate read and
write permissions at each access
– file_mmap() to check for permission to do mmap()
– file_lock() for permission to lock a file
Network Hooks
• Hooks are inserted into socket-related functions
– bind, connect, listen, accept, etc.
• For example, mediating socket operations
–
–
–
–
–
socket_bind()
socket_connect()
socket_listen()
socket_sendmsg()
socket_recvmsg()
• unix_stream_connect() for stream connections
Other Hooks
• Module hooks
– Mediating kernel operations on modules
– Not found in 2.6.16 source?
• System Hooks
– Used to control system operations
•
•
•
•
Whether to allow ptrace
Read/write/search operations on sysctl variables
Changing system time
etc.
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
new role
restorecon
semanage
semodule
sestatus
setbool
etc...
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
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
References
• Implementing SELinux as a Linux Security Module
• SELinux installation help
• Stephen Smalley, “Configuring the SELinux Policy”, 2002
• Stephen Smalley and Timothy Fraser, “A Security Policy
Configuration for the Security-Enhanced 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
More Information
• SELinux Homepage: www.nsa.gov/selinux
• SELinux Mailing list:
http://www.nsa.gov/selinux/info/list.cfm?MenuID=4
1.1.1.9
• Redhat SELinux Mailing List:
http://www.redhat.com/mailman/listinfo/fedoraselinux-list
• Fedora SELinux Wiki:
http://fedoraproject.org/wiki/SELinux
Thank You…..
You can find a copy of this presentation at:
http://www.cs.kent.edu/~rothstei/summer_12/
notes/