SELinux type enforcement -Demonstration -General description David Morgan Demonstration
Trying to access a resource (permissions vs SELinux) permissions system cares which user account SELinux cares which program user can access more files than a particular program should my progx doesn't need access to all the same files as my progy, just because they're both mine! gaining illicit control, which access do you want attacker to get? Why should I use SELinux? In short because SELinux can help protect you from bugs in applications. Most people treat applications as user surrogates (e.g., "I go to google.com" not "I tell my browser to go to google.com and it does so on my behalf"). However applications, especially the desktop applications we all use, come in at millions of lines of code. Without knowing what those millions of lines of code do there is no way to know if an application will really do what you tell it or if it becomes malicious because of vulnerabilities. With SELinux you can treat the applications you run differently from yourself thereby limiting what an exploited application can do. http://selinuxproject.org/page/faq SELinux policy creation: language, tools, procedure traditional from: SELinux: NSA s Open Source Security Enhanced Linux
Who gets to write the rules? Access control types: discretionary vs manadatory users may control access decisions for some objects but policy is by central authority (sysadmin), never a user policy is the mandate in mandatory mandatory and discretionary can be combined multics ACLs (discretionary) + MLS (mandatory) linux permissions (discretionary) + SELinux type enforcement (mandatory) co-existing, independent systems operate as perms && selinux ie perms first What s are there? where are SELinux s? filenames those are s themselves (on data) permission strings those are s (on files) SELinux contexts another set of lables (also on files) ( context == ) context/ 4 components secon shows them individually we care only about the type or type ( net_conf_t in this case)
SELinux -- where are the files s? disk: inode table data pointer data data pointer - or - data pointer lbl pointer data data inode field structure 16 th field give you the file's permissions here pointer to additional data of variable length here ( extended attributes ) e.g., ACL, SELinux s
Apache filesystem map (default) / etc var ServerRoot httpd www DocumentRoot conf httpd.conf logs access_log error_log your webpage files (index.html et.al.) html cgi-bin error your executables manual noindex.html index.html Labels on files and processes a a process of this type, can access a file ed with that type objects (files) apparent correspondence/match (at least by string tokens) httpd looks somehow related to the /var/www and /etc/httpd directories subjects (processes)
Processes ed too. What s s where? processes (subjects) get their own s user space kernel space (OS) compiled in-kernel blob of all the policy rules (selinux engine ) compiled in-kernel blob of all the firewall rules (iptables engine ) process descriptor array 1 filesystem objects and their s 2 policy store (rules in ascii) 3 kernel-loadable blob file mv (unlike cp) is not an inode operation ( mv /etc/hello.txt / ) disk: inode table pointer pointer bin etc home hello.txt hosts passwd pointer Hello!
demo 2 files web-readable create web pages on client (one in-place in apache territory, one elsewhere then moved into apache territory) browse them from server demo now enforce SELinux policy the one created in place remains web readable the one moved into place does not (though neither file permissions nor apache configuration has changed)
demo why? s must match! s on the 2 objects s on the subject now we ve changed it to match demo web-readablility restored
General description Confinement in cyber security Systems should do 1) what they are designed to do 2) and nothing else. cyber confinement examples memory storage the easy part memory management process isolation chroot at filesystem/directory granularity SELinux at individual file granularity
Confinement in SELinux [SELinux] compensates for the inevitable buffer overflows and other weaknesses in applications by isolating them and preventing flaws in one application from spreading to others. The scenarios that cause the most cyber-damage these days-- when someone gets a toe-hold on a computer through a vulnerability in a local networked application and parlays that toe-hold into pervasive control over the computer system--are prevented on a properly administered SELinux system. book press release Beating the 0-day vulnerability threat book cover banner Trying to access a resource permissions system cares which user account SELinux cares which program user can access more files than a particular program should my progx doesn't need access to all the same files as my progy, just because they're both mine! gaining illicit control, which access do you want attacker to get? Why should I use SELinux? In short because SELinux can help protect you from bugs in applications. Most people treat applications as user surrogates (e.g., "I go to google.com" not "I tell my browser to go to google.com and it does so on my behalf"). However applications, especially the desktop applications we all use, come in at millions of lines of code. Without knowing what those millions of lines of code do there is no way to know if an application will really do what you tell it or if it becomes malicious because of vulnerabilities. With SELinux you can treat the applications you run differently from yourself thereby limiting what an exploited application can do. http://selinuxproject.org/page/faq
Central concept of access control active subjects reference passive objects - reference means propose access government example - subjects are employees - objects are documents cyber example - subjects are processes - objects may be filesystem objects (unix) or memory segments (multics) each access mediated by some arbitration mechanism - approved or disapproved We call it a file system but in unix,, everything is a file object types subject to management (beyond just files)
reference monitor another, similar possibility centerpiece of security kernels in trusted OS's (runs low-level in/at the heart of a trusted OS kernel) sits between subjects and objects uses an authorization database as input supplies audit (event) rmation as output reference monitor authorization database subject reference monitor object audit
ref monitor enforces policy the database holds rules covering each interaction type for every subject/object combination e.g. a population of 3 subjects and 5 objects with 2 operations would need 30 rules each rule allows or disallows the rule collection is called the policy Well then, policy is prerequisite the policy is the law absent the law you can't enforce the law so the database must get pre-populated by the system admin ref monitor is the cop, but sysadmin is the legislature everything flows from policy
Rules can be fashioned from s multics did it with s on memory segments selinux does it with s on processes and filesystem objects so do traditional permissions Access control policy list of ordered triples < subject, object, mode > express what is disallowed
Who gets to write the rules? Access control types: discretionary vs manadatory users may control access decisions for some objects but policy is by central authority (sysadmin), never a user policy is the mandate in mandatory mandatory and discretionary can be combined multics ACLs (discretionary) + MLS (mandatory) linux permissions (discretionary) + SELinux type enforcement (mandatory) co-existing, independent systems operate as perms && selinux ie perms first What s are there? where are SELinux s? filenames those are s themselves (on data) permission strings those are s (on files) SELinux contexts another set of lables (also on files) ( context == ) context/ 4 components secon shows them individually we care only about the type or type ( net_conf_t in this case)
Labeling for access control MSDOS/FAT had none linux/ext2 perms/user/group on a file, as against user identity in a process by a particular (well-known) interaction methodology SELinux type on a file, as against type ( domain ) in a process by some particular interaction methodology/rules inode field structure 16 th field give you the file's permissions here pointer to additional data of variable length here ( extended attributes ) e.g., ACL, SELinux s
Labels on files and processes a a process of this type, can access a file ed with that type objects (files) apparent correspondence/match (at least by string tokens) httpd looks somehow related to the /var/www and /etc/httpd directories subjects (processes) Directories sit in their own files files names are in there finding /etc/hello.txt directory files (for / and /etc ) disk: inode table pointer pointer bin etc home hosts passwd hello.txt pointer Hello!
mv (unlike cp) is not an inode operation ( mv /etc/hello.txt / ) disk: inode table pointer pointer bin etc home hello.txt hosts passwd pointer Hello! SELinux -- where are the files s? disk: inode table data pointer data data pointer - or - data pointer lbl pointer data data
Policy creation: language, tools, procedure traditional from: SELinux: NSA s Open Source Security Enhanced Linux Processes ed too. What s s where? processes (subjects) get their own s user space kernel space (OS) compiled in-kernel blob of all the policy rules (selinux engine ) compiled in-kernel blob of all the firewall rules (iptables engine ) process descriptor array 1 filesystem objects and their s 2 policy store (rules in ascii) 3 kernel-loadable blob file
SELinux -- where are the files s? disk: inode table data pointer data data pointer - or - data pointer lbl pointer data data