1. Linux Security Module (LSM) Framework
By Hasari Tosun
11/30/2006

2. 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

3. 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 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
Increased software threats is increased network connectivity and, in particular, the Internet itself. Connectivity provides a vector whereby attacks successfully launched against one networked host can be launched against others. The Internet, which interconnects the majority of networks in existence, is the ultimate attack vector
Not all threats arise from software or the Internet. So-called insider threats, which come from local-area networks or proprietary wide-area networks, can present even more serious risks. Insiders often attack systems by means other than software vulnerabilities. For instance, employees in two work groups may collude to falsify database records to steal from their employer

4. 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.
Increased software threats is increased network connectivity and, in particular, the Internet itself. Connectivity provides a vector whereby attacks successfully launched against one networked host can be launched against others. The Internet, which interconnects the majority of networks in existence, is the ultimate attack vector
Not all threats arise from software or the Internet. So-called insider threats, which come from local-area networks or proprietary wide-area networks, can present even more serious risks. Insiders often attack systems by means other than software vulnerabilities. For instance, employees in two work groups may collude to falsify database records to steal from their employer

5. Why secured Operating System?

6. 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.

7. DAC Only two major categories of users: admin and other.
Too much privilege.
Unbounded privilege escalation

8. 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

9. 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()

10. 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

11. 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.

12. 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.

13. LSM Architecture Operation context DAC LSM Policy files
User space
Kernel space
context
Primary
Security
Module
DAC
LSM
0/ERR
0/ERR
Policy files
(policy database)
Execute
operation

14. LSM UML Diagram Before critical Action
Security_ops->action(defined in security.h)

15. LSM Architecture So, Five components added to kernel or modified:
An interface of security functions.
Inserts calls to security functions at various points within the kernel code.
Adding security fields to kernel object.
Providing functions to allow kernel modules to register and unregister themselves as security modules.
Move capabilities logic into an optional security module.

16. 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.

17. 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

18. 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

19. 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_DEBUG "%s could not verify security_operations structure.\n", __FUNCTION__);
return -EINVAL; }
if (security_ops != &dummy_security_ops) return -EAGAIN;
security_ops = ops;
return 0;

20. LSM Architecture: 5) process capabilities
The name "capabilities" comes from the now defunct POSIX draft e.
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.

21. 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)

22. 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.

23. 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.

24. SELinux Architecture Operation context LSM DAC Policy files
Execute
operation
0/ERR
SELinux
Module
selinuxfs
Security
Server
Policy files
(policy database)

25. 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

26. SELinux Concepts
Type: This refers to the privileges assigned to the object
Policy rules: allow sysadm_t shadow_t:file getattr;

27. SELinux: Code walk-through
Brief code walk-through for SELinux

28. 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.

29. 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.

30. sandbox: Code walk-through
Source code is defined in sandbox.c file.
Can be downloaded from: sandbox.c

31. 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.

32. sandbox: DEMO
DEMO (Flash)
DEMO (AVI)

33. 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 rule-based security module is needed
A more flexible module-stacking feature must be provided to allow any number of security modules.

34. References

35. Questions?