SELinux Overview ● Permissions historically – Why is unix or ACL permissions not good enough? ● DAC vs. MAC ● SELinux ID, objects, roles and types ● Policy types ● SELinux administration

FOSDEM Bryan Østergaard 2 SELinux Overview ● Why is unix permissions not good enough? – Not finegrained enough – Permissions are primarily file based – Permissions are controlled by users instead of the administrator – Hard to set up access for multiple groups or users to the same file

FOSDEM Bryan Østergaard 3 SELinux Overview ● DAC vs. MAC – Unix permissions are discrete – Administrators need mandatory access ● Why? – Does MAC replace dac?

FOSDEM Bryan Østergaard 4 SELinux Overview ● SELinux ID – SELinux IDs are permanent + personal – Unix IDs are shared using SU and SUDO – It's not possible to change SELinux ID

FOSDEM Bryan Østergaard 5 SELinux Overview ● SELinux roles – Roles are used for role based access control – SELinux users can have multiple roles ● For example staff_r, sysadm_r or dnsadmin_r – System administrators usually have access to staff_r and sysadm_r – Applications have seperate roles, for example httpd_r – Roles can inherit policy from other roles through Role Dominance

FOSDEM Bryan Østergaard 6 SELinux Overview ● SELinux types – SELinux is based on Type Enforcement ● Extremely finegrained and allows almost every type of access control to be implemented ● Examples of types is shadow_t (used for /etc/shadow) or varlog_t (used for /var/log/*)

FOSDEM Bryan Østergaard 7 SELinux Overview ● SELinux objects – Access control are checked for all types of objects – Lots of different types of objects, for example ● Files ● Processes ● Pipes ● Network ports ● Mutexes ● Sockets

FOSDEM Bryan Østergaard 8 SELinux Overview ● Policy types – Policy types ● Strict ● Targeted ● Multi Level Security

FOSDEM Bryan Østergaard 9 SELinux Overview ● Access Vector Control (AVC) messages – All access control goes through the AVC cache – AVC is (basically) a big list of SELinux contexts (user:role:type) – AVC messages are logged for denials and in some cases even when access is allowed (new policy loaded for example) ● AVC messages are used to log unexpected events – Doesn't mean you're under attack

FOSDEM Bryan Østergaard 10 SELinux Overview ● Example AVC message audit( :252): avc: denied { read } for pid=23871 comm="firefox-bin" name="resolv.conf" dev=sda2 ino= scontext=user_u:user_r:user_t tcontext=system_u:object_r:net_conf_t tclass=file

FOSDEM Bryan Østergaard 11 SELinux Overview ● Reference policy – Modular – Can be compiled as targeted, strict and MLS – Can be reconfigured run-time via booleans (partly) – Administrators can be allowed access to update parts of the policy

FOSDEM Bryan Østergaard 12 SELinux Overview ● SELinux policy language – By default everything is denied – Access is allowed through Allow rules – Policy also controls AVC logging – It's possible to define constraints that limits what's allowed by Allow rules ● A constraint might limit access to sysadm_r role to only be allowed from staff_r role

FOSDEM Bryan Østergaard 13 SELinux Overview ● Simple policy example – As an example we want to allow sysadmin_r write access tol /etc/shadow (bad idea but a simple example) ● We need an Allow statement that – Gives sysadm_r – Write access – To shadow_t (default type for /etc/shadow) ● allow sysadm_r shadow_t:file write;

FOSDEM Bryan Østergaard 14 SELinux Overview ● SELinux administration – SELinux is complex and requires new tools – Administration is a focus area – GUI tools to help troubleshoot denials ● SEtroubleshooter – GUI tools to help write policies ● SLIDE – GUI tools for analysing policies ● Apol