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

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.

5. Why secured Operating System? http://www.cert.org/stats/cert_stats.html

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.process data structureresource uid,giduser and group real identifiers fuid, egidUser and group effective identifiers fsuid,fsgidUser and group effective identifiers for file access groupsSupplemental group identifiers suid,sgiduser 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 DAC Policy files (policy database) LSM context Execute operation 0/ERR Primary Security Module 0/ERR User space Kernel space

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

16. LSM Architecture: 1)Function interface security.h file has security_operations structure which defines security functions as function pointers.security_operations It defines a global variable: extern struct security_operations security_ops;security_operations security_ops security.h defines a set of static functions that corresponds to a each security call.static functions 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 Createfork.c –namei.c: Virtual File System Createnamei.c LSM inserts calls to security functions at critical points in the kernel code to manage the security fields. For example: –inode.c: security_inode_allocinode.c –inode.c: security_inode_freeinode.c –fork.c: security_task_allocfork.c –fork.c: security_task_freefork.c

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_structTask (Process) linux_binprmProgram Super_blockFile System inodePipe, File, or Socket sk_buffNetwork buffer net_deviceNetwork device Kern_ipc_permSemaphore, 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.security.c 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_securitymod_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; }

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

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 Policy files (policy database) SELinux Module Operation DAC LSM context Execute operation 0/ERR Security Server selinuxfs

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 SELinuxSELinux

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 =. 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. sandbox.c Can be downloaded from: sandbox.csandbox.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 http://www.cs.montana.edu/~tosun/ cs518/

35. Questions?