Transcript Security Enhanced Linux - Montana State University

Linux Security Module
(LSM) Framework
By Hasari Tosun
11/30/2006
Overview
Goal: To create a security module for Linux kernel
Motivation: 1) Learn Linux kernel, 2) learn kernel-level
security
• Why secured Operating System?
• Brief summary of traditional Linux access control
(Discretionary Access Control)
• Principle of least privilege
• Linux Security Modules (LSM) Framework
• Brief introduction to Security Enhanced Linux (SELinux)
Module
• Project: Simple Sandbox Security Module (sandbox)
• Demo
Why secured Operating System?
• Software threats and Internet:
– Network connectivity: Network
connectivity, in particular, the
Internet increased software threats.
– Active content: have capability of
triggering actions automatically
(PDF, MS Office, many others)
– Mobile code: designed to be
transported across a network for
execution on remote hosts
(JavaScript, ActiveX etc)
•
•
•
On March 3rd, 2003,
a vulnerability in
Sendmail affected
many organizations
worldwide. The
problem was that an
e-mail message with
a carefully-crafted
"from," "to," or "cc"
field could give the
sender complete
(root) control over
any machine
running Sendmail.
Buffer overflow
Sendmail is installed
as root
Why secured Operating System?
• Insider Threats: Comes from local
area network which represents even
more serious risk (Gartner research
has estimated that 70% of security
incident costs are due to insider
breaches)
• Complex Software: Complex
software may have defects that can be
exploited by attackers.
Why secured Operating System?
http://www.cert.org/stats/cert_stats.html
Incidents Reported
160000
140000
120000
100000
Incidents Reported
80000
60000
40000
20000
Year
20
02
20
00
19
98
19
96
19
94
19
92
0
19
90
Incidents
•
Discretionary access control
(DAC)
• Prior to Linux kernel 2.6, DAC was the
only security framework for Linux.
• In a DAC model, security decisions are
based solely on user identity and
ownership of the objects.
• No protection against malicious or flawed
software.
• Each user has complete discretion over
his/her own objects.
DAC
• Only two major categories of users: admin and
other.
• Too much privilege.
• Unbounded privilege escalation
DAC: Details
•
•
Each process is
associated with some
credentials, which binds
the process to a specific
user or a specific group.
The use of credentials
requires support both in
the process data structure
and in the resource being
protected.
uid,gid
user and group real
identifiers
fuid, egid
User and group
effective
identifiers
fsuid,fsgid
User and group
effective
identifiers for file
access
groups
Supplemental
group identifiers
suid,sgid
user and group
saved identifiers
DAC: Details
•
•
•
•
uid=0 is root, gid=0 is root group.
If uid=0, kernel bypasses the permission
checks.
When a process is created, it always
inherit the credentials of its parent.
Effective credentials can be modified
using system calls; setuid(), setresuid(),
setfsuid() and setreuid()
Principle of least privilege
Grant just the minimum
possible privileges to
permit a legitimate
action:
• Minimized privileged
modules: Give a privilege
to only the parts of the
program needing it.
• Minimize privileges
granted
• Minimize privileges’ time
Programming Tips:
• Break the program
into separate parts
so that only small
and independent
parts require special
privileges.
• If different parts
must run
concurrently, use
processes; Threads
share their security
privileges
Linux Security Modules
(LSM) Framework
• At the Linux Kernel 2.5 Summit (2001), several different
security projects were proposed for the kernel.
• These different approaches were often incompatible.
• Under guidance of Linus, a group was formed to create
Linux Security Modules framework with following
principles:
– The Linux kernel still does its normal security checks.
– When kernel needs to decide if access should be
granted, it also asks a security module whether or not
the action is okay.
– An administrator should pick the security module he
wants.
LSM Architecture
• The LSM framework was designed so that
almost all of its hooks would be restrictive
• An authoritative hook makes the absolute final
decision: if the hook says a request should be
granted, then it's granted no matter what.
• A restrictive hook can only add additional
restrictions; it can't grant new permissions.
• Authoritative model is more flexible. But it
requires many radical changes to the Linux
kernel.
LSM Architecture
User
space
Operation
Kernel
space
context
DAC
Primary
Security
Module
LSM
0/ERR
0/ERR
Execute
operation
Policy files
(policy database)
LSM UML Diagram
Before critical Action
Security_ops>action(defined in
security.h)
LSM Architecture
•
So, Five components added to kernel or
modified:
1. An interface of security functions.
2. Inserts calls to security functions at
various points within the kernel code.
3. Adding security fields to kernel object.
4. Providing functions to allow kernel modules
to register and unregister themselves as
security modules.
5. Move capabilities logic into an optional
security module.
LSM Architecture:
1)Function interface
• security.h file has security_operations structure
which defines security functions as function
pointers.
• It defines a global variable:
extern struct security_operations security_ops;
• security.h defines a set of static functions that
corresponds to a each security call.
• For each static function x, it executes
security_ops->x(). Thus, kernel calls x and x calls
registered function pointer.
LSM Architecture: 2) kernel
security calls
• LSM inserts calls to security functions at critical points in
the kernel code to perform access control. For example:
– fork.c: Task Create
– namei.c: Virtual File System Create
• LSM inserts calls to security functions at critical points in
the kernel code to manage the security fields. For example:
– inode.c: security_inode_alloc
– inode.c: security_inode_free
– fork.c: security_task_alloc
– fork.c: security_task_free
LSM Architecture: 3) security
fields in kernel objects
• security fields (void *
security) added to various
kernel objects.
• The setting of security
fields is handled by
security modules.
• These fields are used by
security modules for
labeling.
task_struct
Task (Process)
linux_binprm
Program
Super_block
File System
inode
Pipe, File, or
Socket
sk_buff
Network buffer
net_device
Network device
Kern_ipc_perm
Semaphore,
Shared Memory
Segment,
or Message
Queue
LSM Architecture: 4) Module
Registration
• The primary security module must
register itself using register_security
function in security.c file.
• It only register one module as
primary module.
• The decision of module stacking is
left to primary module:
– If the secondary module fails to
register using register_security, it
needs to call mod_reg_security
– This function call the primary
function to decide about stacking.
int register_security(struct
security_operations *ops)
{
if (verify(ops)) {
printk(KERN_DEBU
G "%s could not verify
security_operations
structure.\n",
__FUNCTION__);
return -EINVAL;
}
if (security_ops !=
&dummy_security_ops)
return -EAGAIN;
security_ops = ops;
return 0;
}
LSM Architecture: 5)
process capabilities
• The name "capabilities" comes from the now
defunct POSIX draft 1003.1e.
• These capabilities are a partitioning of the all
powerful root privilege.
• A process has three sets of bitmaps called the
inheritable(I), permitted(P), and effective(E)
capabilities.
• Each capability is implemented as a bit in each of
these bitmaps which is either set or unset.
• The kernel will check the appropriate bit in the
effective set of the process for privileged
operation.
process capabilities
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
CAP_AUDIT_WRITE
Allow to generate audit messages by writing in netlink sockets
CAP_AUDIT_CONTROL
Allow to control kernel auditing activities by means of netlink
sockets
CAP_CHOWN
Ignore restrictions on file user and group ownership changes
CAP_DAC_OVERRIDE
Ignore file access permissions
CAP_DAC_READ_SEARCH Ignore file/directory read and search permissions
CAP_FOWNER
Generally ignore permission checks on file ownership
CAP_FSETID
Ignore restrictions on setting the setuid and setgid flags for files
CAP_KILL
Bypass permission checks when generating signals
CAP_SETGID
Ignore restrictions on group's process credentials manipulations
CAP_SETPCAP
Allow capability manipulations on other processes
CAP_SETUID
Ignore restrictions on user's process credentials manipulations
CAP_SYS_ADMIN
Allow general system administration
CAP_SYS_BOOT
Allow use of reboot( )
CAP_SYS_CHROOT
Allow use of chroot( )
CAP_SYS_PTRACE
Allow use of ptrace( ) on every process
CAP_SYS_RESOURCE
Allow resource limits to be increased
CAP_SYS_TIME
Allow manipulation of system clock and real-time clock
•
The full list is given in text book (p. 813)
•
Security Enhanced Linux (SELinux)
Module
• Developed by National Security Agency
(NSA)
• The most comprehensive implementation
of LSM.
• Most of SElinux became part of LSM
framework.
• SELinux is primary security module in
Fedora distribution.
SELinux: Object Labeling
• Important objects in the OS are
labelled; Processes, files, inodes,
superblocks etc.
• Files persistently labelled via
extended attributes.
• Labels are called security
contexts.
SELinux Architecture
Operation
SELinux
Module
context
LSM
DAC
0/ERR
0/ERR
Execute
operation
Security
Server
Policy files
(policy database)
selinuxfs
SELinux Concepts
• Identity: each user
and process has a
unique identity on the
system.
• Roles – Used to
specify acceptable
actions from a user.
Each role has a set of
privileges assigned to
it
SELinux Concepts
• Type: This refers to the
privileges assigned to the
object
• Policy rules: allow
sysadm_t shadow_t:file
getattr;
SELinux: Code walkthrough
• Brief code walk-through for SELinux
Simple Sandbox Security
Module (sandbox)
• Although a few security modules exists
that are very comprehensive, including
SELinux, they are hard to manage.
• It is difficult for a system administrator to
write a correct security policy.
• So, I wrote a simple sandbox security
module that jail programs to a certain
directory during inode_create operation.
sandbox
• Security rule: defined in /etc/sandbox in
format of <programx>=<directoryx>.
Thus, program x can only issue
inode_create in directoryx.
• Rules are read during initialization of the
module.
• If new rules are added, the module needs to
be restarted.
sandbox: Code walk-through
• Source code is defined in sandbox.c file.
• Can be downloaded from: sandbox.c
sandbox
• In order for it to run:
– Capabilities module needs to be set to m
(loadable module, not built-in module) during
build process.
– Without capabilities module running, sandbox
module can stack against SELinux module.
sandbox: DEMO
•DEMO (Flash)
•DEMO (AVI)
Recap & Future directions
• Traditional Linux access control is uid and guid
• A multi-leveled security framework for modern operating
system is a must.
• LSM provides a powerful interface to create security
modules for the kernel.
• Sandbox module demonstrates how easy is to create a
security module.
• Current security modules such as SELinux use labeling
which is difficult for policy writer. Thus, a simple rulebased security module is needed
• A more flexible module-stacking feature must be provided
to allow any number of security modules.
References
• http://www.cs.montana.edu/~tosun/
cs518/
Questions?