S a f e t y m e a s u r e s i n L i n u x

Safety measures in Linux

Krzysztof Lichota [email protected] A g e n d a

● Standard Unix security measures: permissions, capabilities, ACLs, chroot ● Linux kernel enhancements – LSM () – SELinux – AppArmor – grsecurity project – ExecShield – OpenWall ● Other features Standard Unix security measures S t a n d a r d U n i x s e c u r i t y m o d e l

● Root (uid==0) can do everything ● Files have owner, group, access permissions for user, group and others ● It is possible to pass privileges to executed application using SUID bit ● Hardcoded into Linux kernel P O S I X c a p a b i l i t i e s

● Extension to standard Unix model ● Defined in POSIX draft 1003.1e ● In Linux kernel since version 2.2 ● Defines set of capabilities which can be gained or dropped for greater resolution of privileges, for example: – CAP_NET_RAW – raw network packet sending (ping does not need to be run as root) – CAP_SYS_NICE – change processes priority – CAP_SYS_RAWIO – I/O to ports (X-server) P O S I X c a p a b i l i t i e s ( 2 )

● Implemented in kernel by adding calls: if (capable(CAP_XXX)) ... ● If capability is not present, standard check for effective user id == 0 is performed ● Example: sched_setscheduler() P O S I X A C L s

● Extends file access permissions to use Lists ● ACLs can define permissions for specific users, groups of users in flexible manner ● ACLs are implemented using Extended Attributes (have to be supported by FS) ● Not very popular in todays systems P O S I X A C L s

● Implementation embedded in filesystem code ● Filesystem must define “permission” callback in struct inode_operations ● Uses posix_acl_permission() family calls ● Example: ext3_check_acl() c h r o o t

● Traditional way of limiting access to files ● Process is run with “/” moved to some subdirectory, so it cannot access files outside of chroot ● In Linux since ages ● Not perfect - there are some ways to get out of chroot F S f l a g s

● Mount flags passed upon mount ● Implementation embedded in filesystem code ● Flags: – ro – read-only – noexec – no executable bits – nosuid – no SUID bits – nodev – no device files Linux kernel security enhancements L i n u x S e c u r i t y M o d u l e s

● Introduced in kernel 2.6 ● Common set of hooks for security modules in Linux kernel ● Exports set of operations which can be intercepted and controlled by various security modules ● Security modules can be “stacked” ● Used by several security improvements, including built-in capabilities and SELinux L i n u x S e c u r i t y M o d u l e s ( 2 )

● Security module defines its own structure with security callback - struct security_operations ● Module registers it in stack using mod_reg_security() ● Permissions are checked in proper places in kernel using calls to security_FEATURE_NAME() ● Example: security_settime S E L i n u x

● SELinux = Security Enhanced Linux ● Security enhancement to Linux kernel developed by NSA ● Now part of Linux 2.6 kernel, patches available for 2.4 kernels ● Adds MAC () to Linux kernel ● Uses LSM framework in Linux kernel S E L i n u x ( 2 )

● Processes/users get “security context” which defines what they can do, with which files, processes, etc. ● It is possible to specify what can be done with file (e.g. append-only) and by whom ● Daemons get security context with minimal privileges to do the job ● Gaining privileges is also restricted by policy ● Files are labelled with security context using extended attributes S E L i n u x ( 3 )

● Privileges are defined by security policies, not by user id, file access bits, SUID, etc. It is possible to run as root and not be possible to do anything harmful! ● User cannot change privileges of the entity unless he has administrative privileges ● Security privileges for files are based on inodes, not on paths ● Spoils performance (up to 7%) A p p A r m o r

● MAC implementation created by Novell ● Also uses LSM framework ● Uses paths instead of file labels – labelling was seen by administrators as very burdensome and hard to maintain ● Does not require extended attributes support in filesystem ● Makes creating policies for programs much easier by providing tools to trace program usage A p p A r m o r

● Has lover overhead than SELinux (0%- 2%) ● Currently available as patches, not included in main kernel line ● Slowly gets into popular distributions: OpenSuse, Ubuntu, Mandriva R S B A C

● RSBAC = Rule Set Based Access Control ● Framework which allows implementing specific access control models ● Currently implemented, for example: – Role based module – ACL module – MAC module – On access antivirus scanning (Dazuko) – Jail module – File flags (no delete, execute only, append) R S B A C ( 2 )

● Other interesting features: – In-kernel user management (no /etc/passwd) – Symlink redirection based on role – Secure deletion – Hiding processes – Freezing changes to access controls until reboot – Disabling standard DAC Linux controls ● Available as patches, does not use LSM framework g r s e c u r i t y

● Set of various patches for Linux kernel improving security ● Also available for 2.4 kernels (still used on many production systems) ● Role Based Access Control support ● Chroot improvements ● PaX – address space modification protection ● Auditing of important system calls g r s e c u r i t y ( 2 )

● /proc improvements preventing data leaking which can be used for attack ● carrying IP of remote user through operations for identification ● Symlink/hardlink restrictions to prevent races ● IPC restrictions and logging P a X

● Set of various patches for address space execution and modification protection – prevent attacks by running code supplied by attacker (on heap, on stack, by jump) ● Noexec – prevent writable-and- executable mappings in address space, implemented using Mprotect and Pageexec or Segmexec ● Mprotect – change mmap() family of calls to prevent creating writable+executable mappings in any way P a X ( 2 )

● Creating readable and non-executable pages is a problem on architecture as read permission implies execute permission ● In newer CPUs NX bit for this purpose has been introduced ● Pageexec – uses NX bit or TLB split between instructions and data to distinguish between read and execute by protecting pages and intercepting fault P a X ( 3 )

● Segmexec – uses x86 segmentation logic to simulate readable, non-executable pages by splitting linear address space into 2 halves and modifying CS register (used for code addressing) to use different half than data accesses (executable areas must be mirrored in both halves) P a X ( 4 )

● ASLR (address space layout randomization) – prevents attacks by jump/modification to known location by randomizing addresses of memory regions, implemented by modifying ELF loader in kernel, consists of heap randomization, stack randomization, kernel stack randomization, executable randomization and mmap randomization E x e c S h i e l d

● Patches from RedHat to implement non- executable memory areas ● Non-executable stack and heap is forced by limiting size of code segment ● Can also use NX bit if supported by CPU ● Also adds address space randomization O p e n W a l l p a t c h e s

● Another set of patches improving some security issues for kernels 2.2 and 2.4: – Non-executable stack – Restricted access to 8086 emulation mode – Restricted zero page mappings – prevents triggering information leaks from kernel in some situations – Restricted links and FIFOs in /tmp – Restricted /proc – ... O t h e r s e c u r i t y k e r n e l p a t c h e s

● Non-executable kernel pages ● No direct access to userspace memory from kernel ● Executable cryptographic signature verification ● Filesystem operations auditing O t h e r L i n u x k e r n e l f e a t u r e s

● Linux kernel includes other features useful for security: – Generating true random numbers (important problem on embedded, isolated systems) – Built-in generic encryption libraries used by kernel modules – Block device and swap encryption – Timekeeping also using external sources (for example important for Kerberos) ● Immutable, secure delete and append- only bits in ext3 F i n a l n o t e s

● Hardened distros: – Hardened Gentoo – Engarde Secure Linux – ... S u m m a r y

● Security is complex subject and consists of many different techniques in Linux: – Access controls – Privacy/confidentiality issues (encryption, signing) – Information leaking prevention – Prevention of exploiting bugs – Kernel protection – Auditing and logging B i b l i o g r a p h y

● http://www.gentoo.org/proj/en/hardened/primer.xml ● http://www.ibm.com/developerworks/linux/library/l-sppriv.html ● man 7 capabilities ● http://www.securityfocus.com/infocus/1400 ● http://www.suse.de/~agruen/acl/linux-acls/online/ ● http://www.rsbac.org/documentation/rsbac_handbook/security_models ● http://www.usenix.org/event/sec02/full_papers/wright/wright_html/index.html B i b l i o g r a p h y ( 2 )

● http://gentoo-wiki.com/Access_Control_Comparison_Table ● http://www.nsa.gov/selinux/ ● http://www.crypt.gen.nz/selinux/faq.html ● http://en.opensuse.org/AppArmor ● http://developer.novell.com/wiki/index.php/Apparmor_FAQ ● http://www.rsbac.org/ ● http://www.rsbac.org/documentation/rsbac_handbook/introduction/features ● http://www.rsbac.org/doc/media/piwo-MPurzynski.pdf B i b l i o g r a p h y ( 3 )

● http://www.grsecurity.net/ ● http://en.wikipedia.org/wiki/PaX ● http://pax.grsecurity.net/docs/ ● http://www.redhat.com/f/pdf/rhel/WHP0006US_Execshield.pdf ● http://openwall.com/linux/README.shtml ● man chattr