SELinux

1. Linux has Discretionary Access Control as a default permissions model
2. Examples: File permissions (chmod)
3. Examples: Process ownership
4. The user (subject) has discretion to set or not security policies.

1. Mandatory Access Control enforces a central policy on a system
2. MAC enforcement requires all policies to be specified by an administrator. Users cannot change these policies

1. privilege of least authority
   1. The principle of least authority says you should only give the minimum privilege needed
2. fine-grained access control permission to kernel objects
   1. Read/write permissions are coarse

1. Disables root user priviledges
2. Several administrative roles with limited extra privileges
3. Example: Changing passwords does not require root access to setting up firewalls

1. Multi-level security: Declassified, Secret, Top-Secret, etc.
   1. In MLS, only a trusted declassifier can lower the secrecy of a file
   2. Users with appropriate privilege can read classified files, but cannot output their contents to lower secrecy levels

1. Conditional access control
2. Example: Don’t let this file go out on the internet
   1. Create secret file role
      1. No network access, can’t write any files except other secret files
      2. Process cannot change roles, only exit
      3. Process can read secret files
   2. I challenge you to express this policy in Unix permissions!

   Roles vs. Specific Users

3. Policies are hard to write
4. Roles allow policies to be generalized
   1. Users everywhere want similar restrictions on their browser
5. Roles eliminate the need to re-tailor the policy file for every user
   1. Anyone can transition to the browser role

1. Very much like the fine-grained ACLs we saw last time
2. Rather than everything being a file, objects are given a more specific type
   1. Type includes a set of possible actions on the object
      1. E.g., Socket: create, listen, send, recv, close
   2. Type includes ACLs based on roles

1. Device types:
   1. agp_devicet - AGP device (/dev/agpgart)
   2. console_devicet - Console device (/dev/console)
   3. mouse_devicet - Mouse (/dev/mouse)
2. File types:
   1. fs_t - Defaults file type
   2. etc_aliasest - /etc/aliases and related files
   3. bin_t - Files in /bin More type examples
3. Networking:
   1. netif_eth0t – Interface eth0
   2. port_t – TCP/IP port
   3. tcp_sockett – TCP socket
4. /proc types
   1. proc_t - /proc and related files
   2. sysctl_t - /proc/sys and related files
   3. sysctl_fst - /proc/sys/fs and related files

1. ping_exect type associated with ping binary
2. Policies for ping_exect:
   1. Restrict who can transition into ping_t domain
      1. Admins for sure, and init scripts
      2. Regular users: admin can configure
   2. ping_t domain (executing process) allowed to:
      1. Use shared libraries
      2. Use the network
      3. Call ypbind (for hostname lookup in YP/NIS)

01 type ping_t, domain, privlog; 02 type ping_exect, file_type, sysadmfile, exec_type; 19 03 role sysadm_r types ping_t; 20 auditallow ping_t any_sockett:rawip_socket 04 role system_r types ping_t; sendto; 05 21 06 # Transition into this domain when you run this 22 # Let ping receive ICMP replies. program. 23 allow ping_t { self icmp_sockett }:rawip_socket 07 domain_autotrans(sysadm_t, ping_exect, ping_t) recvfrom;

1. domain_autotrans(initrc_t, ping_exect, ping_t) 24

09 25 # Use capabilities. 10 uses_shlib(ping_t) 26 allow ping_t self:capability { net_raw setuid }; 11 can_network(ping_t) 27 12 general_domainaccess(ping_t) 28 # Access the terminal. 13 allow ping_t { etc_t resolv_conft }:file { getattr 29 allow ping_t admin_ttytype:chr_file read }; rw_fileperms; 14 allow ping_t self:unix_streamsocket 30 ifdef(`gnome-pty-helper.te', `allow ping_t create_socketperms; sysadm_gpht:fd use;') 15 31 allow ping_t privfd:fd use; 16 # Let ping create raw ICMP packets. 32 17 allow ping_t self:rawip_socket {create ioctl read 33 dontaudit ping_t fs_t:filesystem getattr; write bind getopt setopt}; 34 18 allow ping_t any_sockett:rawip_socket sendto; 35 # it tries to access /var/run 36 dontaudit ping_t var_t:dir search;

1. Culturally, top Linux developers care about writing a good kernel
   1. Not as much about security
   2. Different specializations
2. Their goal: Modularize security as much as humanly possible
   1. Security folks write modules that you can load if you care about security; kernel developers don’t have to worry about understanding security

1. Linux Security Modules API:
   1. Linux developers put dozens of access control hooks all over the kernel
      1. See include/linux/security.h
   2. LSM writer can implement access control functions called by these hooks that enforce arbitrary policies
   3. Linux also adds opaque “security” pointer that LSM can use to store security info they need in processes, inodes, sockets, etc.

1. A task has an associated security pointer
   1. Stores current role
2. An inode also has a security pointer
   1. Stores type and policy rules
3. Initialization hooks for both called when created SELinux example, cont.
4. A task reads the inode
   1. VFS function calls LSM hook, with inode and task pointer
   2. LSM reads policy rules from inode
5. Suppose the file requires a role transition for read
   1. LSM hook modifies task’s security data to change its role
   2. Then read allowed to proceed Problem: Persistence
6. All of these security hooks are great for in memory data structures
   1. E.g., VFS inodes
7. How do you ensure the policy associated with a given file persists across reboots? Extended Attributes
8. In addition to 9+ standard Unix attributes, associate a small key/value store with an on-disk inode
   1. User can tag a file with arbitrary metadata
   2. Key must be a string, prefixed with a domain
      1. User, trusted, system, security
   3. Users must use ‘user’ domain
   4. LSM uses ‘security’ domain
9. Only a few file systems support extended attributes
   1. E.g., ext2/3/4; not NFS, FAT32

1. All ACLs, type information, etc. are stored in extended attributes for persistence
2. Each file must be labeled for MAC enforcement
   1. Labeling is the generic problem of assigning a type or security context to each object/file in the system
   2. Can be complicated
3. SELinux provides some tools to help, based on standard system file names and educated guesses

1. SELinux augments Linux with a much more restrictive security model
   1. MAC vs. DAC
2. Understand Roles and Types
3. Basic ideas of LSM
   1. Labeling and extended attributes