DOCSLIB.ORG

Safety Measures in Linux

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

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 (Linux security modules) – 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 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 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 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 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 (Mandatory Access Control) 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 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 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) 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.
Recommended publications
  • Intermediate X86 Part 2

    Intermediate X86 Part 2

    Intermediate x86 Part 2 Xeno Kovah – 2010 xkovah at gmail All materials are licensed under a Creative Commons “Share Alike” license. • http://creativecommons.org/licenses/by-sa/3.0/ 2 Paging • Previously we discussed how segmentation translates a logical address (segment selector + offset) into a 32 bit linear address. • When paging is disabled, linear addresses map 1:1 to physical addresses. • When paging is enabled, a linear address must be translated to determine the physical address it corresponds to. • It’s called “paging” because physical memory is divided into fixed size chunks called pages. • The analogy is to books in a library. When you need to find some information first you go to the library where you look up the relevant book, then you select the book and look up a specific page, from there you maybe look for a specific specific sentence …or “word”? ;) • The internets ruined the analogy! 3 Notes and Terminology • All of the figures or references to the manual in this section refer to the Nov 2008 manual (available in the class materials). This is because I think the manuals <= 2008 organized and presented much clearer than >= 2009 manuals. • When I refer to a “frame” it means “a page- sized chunk of physical memory” • When paging is enabled, a “linear address” is the same thing as a “virtual memory ” “ ” address or virtual address 4 The terrifying truth revealed! And now you knowAHHHHHHHH!!!…the rest of the story.(Nah, Good it’s not so bad day. :)) 5 Virtual Memory • When paging is enabled, the 32 bit linear address space can be mapped to a physical address space less than 32 bits.
  • Administrative Role-Based Access Control on Top of Security Enhanced Linux

    Administrative Role-Based Access Control on Top of Security Enhanced Linux

    Administrative Role-Based Access Control on Top of Security Enhanced Linux Ayla Solomon Submitted in Partial Fulfillment of the Prerequisite for Honors in Computer Science June 2009 Copyright Ayla Solomon, 2009 Abstract In a time when the Internet is increasingly dangerous and software is increasingly com- plex, properly securing one’s system has become a widespread concern, especially for system administrators. There are a number of ways to secure a Linux system; these methods vary in effectiveness and usability. Regular Linux discretionary access control is suitable for most mundane tasks and is easy to use, but it fails to confine insecure programs that run with administrative powers and is difficult to scale. Security Enhanced Linux (SELinux) is an extension to the Linux kernel that provides fine-grained controls for preventing malicious agents from exploiting software vulnerabilities. It can be very effective, but its policy lan- guage is extremely low-level and its paradigm difficult to understand and use. This makes it difficult to map a high-level idea of a security policy to what needs to be done in SELinux, which rules out its use to a vast majority of people with Linux systems, including system administrators, though many attempts have been made to make it more usable. I have designed and partially implemented a system on top of SELinux to implement administrative role-based access control (ARBAC), which is not available on any Linux system. ARBAC is an intuitive, flexible, and scalable security paradigm well suited for user confinement, especially for very large systems with many users. ARBAC’s main advan- tages are not only in its intuitive structure but also its built-in administrator confinement mechanism: its very structure promotes separation of privilege amongst administrators.
  • Multiprocessing Contents

    Multiprocessing Contents

    Multiprocessing Contents 1 Multiprocessing 1 1.1 Pre-history .............................................. 1 1.2 Key topics ............................................... 1 1.2.1 Processor symmetry ...................................... 1 1.2.2 Instruction and data streams ................................. 1 1.2.3 Processor coupling ...................................... 2 1.2.4 Multiprocessor Communication Architecture ......................... 2 1.3 Flynn’s taxonomy ........................................... 2 1.3.1 SISD multiprocessing ..................................... 2 1.3.2 SIMD multiprocessing .................................... 2 1.3.3 MISD multiprocessing .................................... 3 1.3.4 MIMD multiprocessing .................................... 3 1.4 See also ................................................ 3 1.5 References ............................................... 3 2 Computer multitasking 5 2.1 Multiprogramming .......................................... 5 2.2 Cooperative multitasking ....................................... 6 2.3 Preemptive multitasking ....................................... 6 2.4 Real time ............................................... 7 2.5 Multithreading ............................................ 7 2.6 Memory protection .......................................... 7 2.7 Memory swapping .......................................... 7 2.8 Programming ............................................. 7 2.9 See also ................................................ 8 2.10 References .............................................
  • X86 Memory Protection and Translation

    X86 Memory Protection and Translation

    2/5/20 COMP 790: OS Implementation COMP 790: OS Implementation Logical Diagram Binary Memory x86 Memory Protection and Threads Formats Allocators Translation User System Calls Kernel Don Porter RCU File System Networking Sync Memory Device CPU Today’s Management Drivers Scheduler Lecture Hardware Interrupts Disk Net Consistency 1 Today’s Lecture: Focus on Hardware ABI 2 1 2 COMP 790: OS Implementation COMP 790: OS Implementation Lecture Goal Undergrad Review • Understand the hardware tools available on a • What is: modern x86 processor for manipulating and – Virtual memory? protecting memory – Segmentation? • Lab 2: You will program this hardware – Paging? • Apologies: Material can be a bit dry, but important – Plus, slides will be good reference • But, cool tech tricks: – How does thread-local storage (TLS) work? – An actual (and tough) Microsoft interview question 3 4 3 4 COMP 790: OS Implementation COMP 790: OS Implementation Memory Mapping Two System Goals 1) Provide an abstraction of contiguous, isolated virtual Process 1 Process 2 memory to a program Virtual Memory Virtual Memory 2) Prevent illegal operations // Program expects (*x) – Prevent access to other application or OS memory 0x1000 Only one physical 0x1000 address 0x1000!! // to always be at – Detect failures early (e.g., segfault on address 0) // address 0x1000 – More recently, prevent exploits that try to execute int *x = 0x1000; program data 0x1000 Physical Memory 5 6 5 6 1 2/5/20 COMP 790: OS Implementation COMP 790: OS Implementation Outline x86 Processor Modes • x86
  • Operating Systems & Virtualisation Security Knowledge Area

    Operating Systems & Virtualisation Security Knowledge Area

    Operating Systems & Virtualisation Security Knowledge Area Issue 1.0 Herbert Bos Vrije Universiteit Amsterdam EDITOR Andrew Martin Oxford University REVIEWERS Chris Dalton Hewlett Packard David Lie University of Toronto Gernot Heiser University of New South Wales Mathias Payer École Polytechnique Fédérale de Lausanne The Cyber Security Body Of Knowledge www.cybok.org COPYRIGHT © Crown Copyright, The National Cyber Security Centre 2019. This information is licensed under the Open Government Licence v3.0. To view this licence, visit: http://www.nationalarchives.gov.uk/doc/open-government-licence/ When you use this information under the Open Government Licence, you should include the following attribution: CyBOK © Crown Copyright, The National Cyber Security Centre 2018, li- censed under the Open Government Licence: http://www.nationalarchives.gov.uk/doc/open- government-licence/. The CyBOK project would like to understand how the CyBOK is being used and its uptake. The project would like organisations using, or intending to use, CyBOK for the purposes of education, training, course development, professional development etc. to contact it at con- [email protected] to let the project know how they are using CyBOK. Issue 1.0 is a stable public release of the Operating Systems & Virtualisation Security Knowl- edge Area. However, it should be noted that a fully-collated CyBOK document which includes all of the Knowledge Areas is anticipated to be released by the end of July 2019. This will likely include updated page layout and formatting of the individual Knowledge Areas KA Operating Systems & Virtualisation Security j October 2019 Page 1 The Cyber Security Body Of Knowledge www.cybok.org INTRODUCTION In this Knowledge Area, we introduce the principles, primitives and practices for ensuring se- curity at the operating system and hypervisor levels.
  • Chapter 3 Protected-Mode Memory Management

    Chapter 3 Protected-Mode Memory Management

    CHAPTER 3 PROTECTED-MODE MEMORY MANAGEMENT This chapter describes the Intel 64 and IA-32 architecture’s protected-mode memory management facilities, including the physical memory requirements, segmentation mechanism, and paging mechanism. See also: Chapter 5, “Protection” (for a description of the processor’s protection mechanism) and Chapter 20, “8086 Emulation” (for a description of memory addressing protection in real-address and virtual-8086 modes). 3.1 MEMORY MANAGEMENT OVERVIEW The memory management facilities of the IA-32 architecture are divided into two parts: segmentation and paging. Segmentation provides a mechanism of isolating individual code, data, and stack modules so that multiple programs (or tasks) can run on the same processor without interfering with one another. Paging provides a mech- anism for implementing a conventional demand-paged, virtual-memory system where sections of a program’s execution environment are mapped into physical memory as needed. Paging can also be used to provide isolation between multiple tasks. When operating in protected mode, some form of segmentation must be used. There is no mode bit to disable segmentation. The use of paging, however, is optional. These two mechanisms (segmentation and paging) can be configured to support simple single-program (or single- task) systems, multitasking systems, or multiple-processor systems that used shared memory. As shown in Figure 3-1, segmentation provides a mechanism for dividing the processor’s addressable memory space (called the linear address space) into smaller protected address spaces called segments. Segments can be used to hold the code, data, and stack for a program or to hold system data structures (such as a TSS or LDT).
  • X86 Memory Protection and Translation

    X86 Memory Protection and Translation

    x86 Memory Protection and Translation Don Porter CSE 506 Lecture Goal ò Understand the hardware tools available on a modern x86 processor for manipulating and protecting memory ò Lab 2: You will program this hardware ò Apologies: Material can be a bit dry, but important ò Plus, slides will be good reference ò But, cool tech tricks: ò How does thread-local storage (TLS) work? ò An actual (and tough) Microsoft interview question Undergrad Review ò What is: ò Virtual memory? ò Segmentation? ò Paging? Two System Goals 1) Provide an abstraction of contiguous, isolated virtual memory to a program 2) Prevent illegal operations ò Prevent access to other application or OS memory ò Detect failures early (e.g., segfault on address 0) ò More recently, prevent exploits that try to execute program data Outline ò x86 processor modes ò x86 segmentation ò x86 page tables ò Software vs. Hardware mechanisms ò Advanced Features ò Interesting applications/problems x86 Processor Modes ò Real mode – walks and talks like a really old x86 chip ò State at boot ò 20-bit address space, direct physical memory access ò Segmentation available (no paging) ò Protected mode – Standard 32-bit x86 mode ò Segmentation and paging ò Privilege levels (separate user and kernel) x86 Processor Modes ò Long mode – 64-bit mode (aka amd64, x86_64, etc.) ò Very similar to 32-bit mode (protected mode), but bigger ò Restrict segmentation use ò Garbage collect deprecated instructions ò Chips can still run in protected mode with old instructions Translation Overview 0xdeadbeef Segmentation 0x0eadbeef Paging 0x6eadbeef Virtual Address Linear Address Physical Address Protected/Long mode only ò Segmentation cannot be disabled! ò But can be a no-op (aka flat mode) x86 Segmentation ò A segment has: ò Base address (linear address) ò Length ò Type (code, data, etc).
  • Computer Architectures an Overview

    Computer Architectures an Overview

    Computer Architectures An Overview PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 25 Feb 2012 22:35:32 UTC Contents Articles Microarchitecture 1 x86 7 PowerPC 23 IBM POWER 33 MIPS architecture 39 SPARC 57 ARM architecture 65 DEC Alpha 80 AlphaStation 92 AlphaServer 95 Very long instruction word 103 Instruction-level parallelism 107 Explicitly parallel instruction computing 108 References Article Sources and Contributors 111 Image Sources, Licenses and Contributors 113 Article Licenses License 114 Microarchitecture 1 Microarchitecture In computer engineering, microarchitecture (sometimes abbreviated to µarch or uarch), also called computer organization, is the way a given instruction set architecture (ISA) is implemented on a processor. A given ISA may be implemented with different microarchitectures.[1] Implementations might vary due to different goals of a given design or due to shifts in technology.[2] Computer architecture is the combination of microarchitecture and instruction set design. Relation to instruction set architecture The ISA is roughly the same as the programming model of a processor as seen by an assembly language programmer or compiler writer. The ISA includes the execution model, processor registers, address and data formats among other things. The Intel Core microarchitecture microarchitecture includes the constituent parts of the processor and how these interconnect and interoperate to implement the ISA. The microarchitecture of a machine is usually represented as (more or less detailed) diagrams that describe the interconnections of the various microarchitectural elements of the machine, which may be everything from single gates and registers, to complete arithmetic logic units (ALU)s and even larger elements.
  • Linux OS-Level Security Nikitas Angelinas

    Linux OS-Level Security Nikitas Angelinas

    Linux OS-Level Security Nikitas Angelinas MSST 2015 Agenda ● SELinux ● SELinux issues ● Audit subsystem ● Audit issues ● Further OS hardening 2 SELinux ● Security-Enhanced Linux ● Is NOT a Linux distribution ● A kernel feature ● A Linux Security Module (LSM) ● security fields in kernel data structures — processes, files, directories, sockets, IPC, and other OS objects ● hooks on all paths from userspace — return a binary predicate: allowed or not allowed (e.g. EACCES) 3 SELinux ● SELinux is a labeling system ● Every process has a label ● Every OS object has a label ● Policy rules control access between processes and objects, based on their labels ● Policy rules are enforced by the kernel ● The objective is to contain misbehaving/compromised userspace applications 4 SELinux policy management application interface userspace open(2) kernel error checks selinuxfs DAC checks cache Allowed? miss? Security Server LSM hook Access Vector Cache (Policy Rules and Access Decision Logic) Yes/No return SELinux 5 SELinux ● Mandatory Access Control ● vs. Discretionary Access Control (file ownership, permissions) ● Labels are of the form user:role:type:level ● e.g. process: /usr/sbin/sshd → system_u:object_r:sshd_exec_t:s0 ● e.g. file: /root/ssh/* → root:object_r:ssh_home_t ● SELinux implements LSM hooks and offers: ● Role-based Access Control ● Type Enforcement ● Multi-Level Security 6 SELinux labels and rules ● ls -Z /usr/sbin/sshd -rwxr-xr-x. root root system_u:object_r:sshd_exec_t:s0 /usr/sbin/sshd ● ls -Z /root/.ssh/id_rsa -rw-------. root root root:object_r:ssh_home_t /root/.ssh/id_rsa ● ls -Z /etc/ssh/sshd_config -rw-------. root root system_u:object_r:etc_t /etc/ssh/sshd_config ● ls -Z /var/run/sshd.pid -rw-------.
  • Security Architecture

    Security Architecture

    COVER STORY RSBAC Architecture of Rule Set Based Access Control (RSBAC) Security Architecture inux security holes typically occur Integrating multiple security models simultaneously in the kernel and in Server programs and S bit tools. LThe best approach would be to detailed logs of any access:The free Rule Set Based Access Control avoid mistakes and update programs immediately if a bug occurs. This is not (RSBAC) security System offers customized protection for a wide range always possible, the next best thing is to of requirements. BY AMON OTT restrict potential damage, and this is where access control systems such as RSBAC come into play [1]. If an attacker exploits the security holes in servers or s bit tools, access to the system should be restricted to a minimum. In this case, even a successful compromise will cause only limited damage, and protective mechanisms can be implemented directly in the operating system kernel. The standard Linux kernel prevents access to various resources such as files, directories or system configurations, but unfortunately the standard mechanisms are fraught with weaknesses: •Poor granularity Ro • Discretionary access control nald Raefle , visipix.com • An all-powerful root user Linux access controls only offer the standard privileges read, write and execute; additionally they only allow distinct privileges to be defined for the owner of a file, the members of a group and all others. Restrictions typically do account used to run that process. kernel a while back, allow a program not apply to the root user. The Thus, an attacker, if fortunate, can launched by root to drop some granularity of these privileges is thus manipulate any files belonging to the privileges, but this is left up to the insufficient for many tasks.
  • I. RSBAC Theory

    I. RSBAC Theory

    The RSBAC library The RSBAC library Copyright © 2003 Amon Ott, Stanislav Ievlev and Henk Klöpping The RSBAC introduction Amon Ott Stanislav Ievlev Heinrich W. Klöpping The RSBAC introduction by Amon Ott, Stanislav Ievlev, and Heinrich W. Klöpping Audience: This book is intended for use by experienced and skilled Unix professionals who wish to install, configure and use RSBAC. Approach: This book resulted from a project founded on June 28th, 2002 by Amon Ott, Stanislav Ievlev and Henk Klöpping. It provides an introduction to Rule Set Based Access control (RSBAC). If you are new to RSBAC, this book is the place to start reading. It provides an overview of what RSBAC is and how it can be employed. It is aimed at both potential users of RSBAC and programmers that would like to enhance the software by writing their own modules - or even changing the software itself. This book also introduces its companions: The RSBAC cookbook, The RSBAC reference manual, The RSBAC programmers cookbook and The RSBAC programmers reference manual. To learn where the latest version of this book can be downloaded or read please refer to Section 6.2. Sources: Our sources of information were (Open Source) material on the Internet, several books, practical experience of the authors , research and programming work done by the authors and others. We try to give credit where due, but are fallible. We apologize. Caution While every precaution was made in the preparation of this book, we can assume no responsibility for errors or omissions. When you feel we have not given you proper credit or feel we may have violated your rights or when you have suggestions how we may improve our work please notify us immediately so we can take corrective actions.
  • Case Study: Building a Secure Operating System for Linux

    Case Study: Building a Secure Operating System for Linux

    121 C H A P T E R 9 Case Study: Building a Secure Operating System for Linux The Linux operating system is a complete reimplementation of the POSIX interface initiated by Linus Torvalds [187]. Linux gained popularity throughout the 1990s, resulting in the promotion of Linux as a viable alternative to Windows, particularly for server systems (e.g., web servers). As Linux achieved acceptance, variety of efforts began to address the security problems of traditional UNIX systems (see Chapter 4). In this chapter, we describe the resulting approach for enforcing mandatory access control, the Linux Security Modules (LSM) framework. The LSM framework defines a reference monitor interface for Linux behind which a variety of reference monitor imple- mentations are possible. We also examine one of the LSM reference monitors, Security-enhanced Linux (SELinux), and evaluate how it uses the LSM framework to implement the reference monitor guarantees of Chapter 2. 9.1 LINUX SECURITY MODULES The Linux Security Modules (LSM) framework is a reference monitor system for the Linux ker- nel [342]. The LSM framework consists of two parts, a reference monitor interface integrated into the mainline Linux kernel (since version 2.6) and a reference monitor module, called an LSM, that implements reference monitor function (i.e., authorization module and policy store, see Chapter 2 for the reference monitor concept definition) behind that interface. Several independent modules have been developed for the LSM framework [228, 183, 127, 229] to implement different forms of reference monitor function (e.g., different policy modules). We examine the LSM reference monitor interface in this section, and one of its LSMs, Security-Enhanced Linux (SELinux) [229] in the subsequent section.