Safety measures in Linux

Size: px

Start display at page:

Download "Safety measures in Linux"

Rosalind Eaton
10 years ago
Views:

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

2 A g e n d a Standard Unix security measures: permissions, capabilities, ACLs, chroot Linux kernel enhancements LSM (Linux security modules) SELinux AppArmor grsecurity project ExecShield OpenWall Other features

enhancements LSM (Linux security modules) SELinux

3 Standard Unix security measures

4 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

for user, group and others It is possible to pass privileges to

5 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 e 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)

2 Defines set of capabilities which can be gained or dropped for greater resolution of privileges,

6 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()

7 P O S I X A C L s Extends file access permissions to use Access Control 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

groups of users in flexible manner ACLs are implemented using

8 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()

9 c h r o o t Traditional way of limiting process 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

so it cannot access files outside of chroot In Linux

10 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

11 Linux kernel security enhancements

12 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

operations which can be intercepted and controlled by various security modules

13 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

registers it in stack using mod_reg_security() Permissions are checked in

14 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 (Mandatory Access Control) to Linux kernel Uses LSM framework in Linux kernel

15 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

append-only) and by whom Daemons get security context with minimal privileges to do the job

16 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%)

It is possible to run as root and not be possible to do anything harmful!

17 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

and hard to maintain Does not require extended attributes support in filesystem

18 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

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

example: Role based module ACL module MAC module On access antivirus

20 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

Hiding processes Freezing changes to access controls until reboot

21 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

22 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

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

24 P a X ( 2 ) Creating readable and non-executable pages is a problem on x86 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 page fault

25 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 virtual memory areas must be mirrored in both halves)

26 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

27 E x e c S h i e l d Patches from RedHat to implement nonexecutable 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

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

29 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

30 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 appendonly bits in ext3

31 F i n a l n o t e s Hardened distros: Hardened Gentoo Engarde Secure Linux...

32 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

33 B i b l i o g r a p h y man 7 capabilities

34 B i b l i o g r a p h y ( 2 )

35 B i b l i o g r a p h y ( 3 ) man chattr

Unix Security Technologies: Host Security Tools. Peter Markowsky <peterm[at]ccs.neu.edu>

Unix Security Technologies: Host Security Tools Peter Markowsky Syllabus An Answer to last week s assignment Four tools SSP W^X PaX Systrace Last time You were assigned to get a