A Novel Scheduling Framework Leveraging Hardware Cache Partitioning for Cache-Side-Channel Elimination in Clouds

Total Page:16

File Type:pdf, Size:1020Kb

A Novel Scheduling Framework Leveraging Hardware Cache Partitioning for Cache-Side-Channel Elimination in Clouds A Novel Scheduling Framework Leveraging Hardware Cache Partitioning for Cache-Side-Channel Elimination in Clouds Read Sprabery Konstantin Evchenko Abhilash Raj University of Illinois, University of Illinois, Oregon State University Urbana-Champaign Urbana-Champaign [email protected] [email protected] [email protected] Rakesh B. Bobba Sibin Mohan Roy H. Campbell Oregon State University University of Illinois, University of Illinois, [email protected] Urbana-Champaign Urbana-Champaign [email protected] [email protected] ABSTRACT on the Last-Level-Cache (LLC) that is shared across multiple cores While there exist many isolation mechanisms that are available [18, 23, 43, 44, 48] – these make defenses much harder. to cloud service providers, including virtual machines, containers, Many defenses against cache-side-channel attacks in cloud envi- etc. , the problem of side-channel increases in importance as a re- ronments have also been proposed (e.g., [6, 19, 21, 22, 24, 25, 28, 31, maining security vulnerability – particularly in the presence of 32, 37–40, 45, 51]). However, the proposed solutions suer from a shared caches and multicore processors. In this paper we present variety of drawbacks: (a) some are probabilistic [25, 37, 51]; (b) oth- a hardware-software mechanism that improves the isolation of ers do not protect applications when SMT is enabled [51]; (c) some cloud processes in the presence of shared caches on multicore require developers to re-write applications [19, 22, 31], (d) while chips. Combining the Intel CAT architecture that enables cache others require hardware changes [39, 40] impacting deployability; partitioning on the y with novel scheduling techniques and state (e) some depend on violating x86 semantics by modifying the reso- cleansing mechanisms, we enable cache-side-channel free comput- lution, accuracy or availability of timing instructions [21, 24, 38] ing for Linux-based containers and virtual machines, in particular, and consequently require signicant changes to the applications. those managed by KVM. We do a preliminary evaluation of our Compiler-based [6] and page coloring based cache-partitioning system using a CPU bound workload. Our system allows Simultane- [28, 32, 45] approaches have high overheads making them imprac- ous Multithreading (SMT) to remain enabled and does not require tical. application level changes. Defenses against cache-side-channel attacks that eliminate the attacks, rather than frustrate techniques employed by the attacker KEYWORDS are desirable. Shannon’s noisy-channel coding theorem states that information can be transmitted, regardless of the amount of noise on cache, side-channels, scheduling, hardware partitioning, cloud com- the channel. Probabilistic defenses (e.g., [25, 37, 51]) may decrease puting the bit-rate of attacks, but cannot fully eliminate them. In addition to a guaranteed defense, the solution must not severely impact (i) the performance of the applications or (ii) utilization of the machine. 1 INTRODUCTION In other words, defenses must minimize the performance impact of Cache-based side-channel attacks (e.g., [13, 26, 27]) are a threat enforcing hard isolation to remain practical. For instance, disabling to computing environments where a diverse set of users share hyper-threading [51], which many existing solutions do, can have hardware resources. Such attacks take advantage of observable a signicant performance impact on the applications. To the best side-eects (on hardware) due to the execution of software pro- of our knowledge, every cloud provider enables hyperthreading. grams. A number of these attacks focus on dierences in timing Furthermore, the solutions must be easy to adopt. History has shown while accessing shared processor caches. Recently, researchers have that solutions requiring additional development time (or signicant adapted these cache-based side-channel attacks to cloud computing changes to existing applications) have a harder time being adopted environments, especially Infrastructure-as-a-Service (IaaS) clouds (as shown in the Return Oriented Programming (ROP) community (e.g., [18, 23, 30, 47]), and showed that secrets and sensitive infor- [34]). Thus, solutions that require developers make application level mation can be extracted across co-located virtual machines (VMs). changes [19, 22] may be challenging to apply to existing workloads. Container frameworks such as Docker[7] that virtualize the oper- In this paper, we present a framework designed to eliminate ating system are even more susceptible to such attacks since they side-channel attacks in cloud computing systems that use multicore share the underlying operating system (e.g., [48]). processors with a shared LLC. The proposed framework uses a Initial cache-based side-channel attacks focused on schedulers, combination of Commodity-o-the-Shelf (COTS) hardware features either at the OS level or Virtual Machine Monitor (VMM) layer [13, along with novel scheduling techniques to eliminate cache-based side- 26, 47]. Other approaches also focused on resource sharing – e.g., channel attacks. In particular, we use Cache Allocation Technology using the processor core (for instance SMT on a single core) to (CAT) [17] that allows us to partition last-level caches at runtime. access shared L1 and L2 caches [27]. Recent attacks have focused CAT, coupled with state cleansing between context switches, and 1 selective sharing of common libraries removes any possibility of Broadwell and Skylake micro-architectures that succeeded Haswell cache-timing-based side-channel attacks between dierent security micro-architecture. domains. We implement a novel scheduling method, as an extension While our implementation and evaluation used an Intel Haswell to the commonly-used Completely-Fair-Scheduler (CFS) in Linux, to processor with Intel CAT technology the proposed approach is reduce the overheads inherent due to any such cleansing operation. generally applicable to any multi-core processor with a hierarchical Our solution provides a transparent1 way to eliminate side-channel cache, shared last-level cache, and a mechanism to partition the attacks, while still working with hyperthreading enabled systems. It shared last-level cache. works with containers, kernel-based virtual machines (KVMs) and any other schedulable entity that relies on the OS scheduler2. In summary, the proposed framework: 2.2 Attack Model While there are many potential threats to security in public cloud C1 Eliminates cache-based side-channel attacks for schedula- environments (e.g., [5, 35]) the focus of this paper is on cache-based ble units (e.g., containers, KVMs) side-channel attacks (e.g., [46, 48]). At a high-level, in cache-based C2 Requires no application level changes side-channel attacks an attacker deduces information about the C3 Allows providers to exploit hyperthreading, and victim’s computations by observing the victims cache usage. The C4 Imposes modest performance overheads information deduced can range from high-level information such 2 SYSTEM AND ATTACK MODEL as which tenant you are co-located with (e.g., [30]) to more ne grained details such as cryptographic keys or items in a shopping cart (e.g., [18, 48]). In such attacks an attacker process rst needs to co-locate (i.e., get assigned to the same physical server) itself with the target or vic- tim in the infrastructure. Methods to both achieve co-residency [30] and to thwart co-residency (e.g., [1, 14, 15, 25, 49]) have been discussed in the literature. In this work we assume that an at- tacker is able to co-locate with the victim and focus on thwart- ing side-channel attacks themselves. Our framework complements approaches that thwart co-residency. Figure 1: Hierarchical Cache in Modern Processors There are primarily two techniques to exploit cache based side- channels discussed in the literature, namely, ‘Prime+Probe” attacks 2.1 System Model [27] and ‘Flush-Reload” attacks [13]. It is important to note that while these techniques are popular, they are only possible because We consider public Platform-as-a-Service (PaaS) or Infrastructure- of measurable interference. Our solution addresses these specic as-a-cloud (IaaS) cloud environments. Such environments allow techniques and other techniques that leverage the cache as a side- for co-residency of multiple computational appliances (e.g., con- channel. tainers, VMs) belonging to potentially dierent security domains. (a) “Prime+Probe” attacks [27]: At a high level, the attack We assume that the cloud computing infrastructure is built using ‘primes’ the entire cache with random data. After waiting for a cer- commodity-o-the-shelf (COTS) components. In particular, we as- tain time (so that the victim executes), the adversary then ‘probes’ sume that the servers have multi-core processors with multiple the cache to see which of its own lines have been evicted – thus levels of caches, some of which are shared (See Figure 1). We also providing information on which lines were used by the victim. This assume that the servers have a runtime mechanism to partition the information combined with the knowledge of cache access patterns last-level shared cache. exhibited by victim programs (e.g., cryptographic algorithms) can For this work, we evaluated our approach using an Intel Haswell be used to extract information (e.g., cryptographic key being used) series processor that has a three-level cache hierarchy: private about the victim. level 1 (L1) and level 2 (L2) caches for each core (64KB
Recommended publications
  • Implementing a Parallel World Model Using Linux Containers for Efficient System Administration
    Implementing a parallel world model using Linux containers for efficient system administration (Paper) Yasushi Shinjo and Wataru Ishida Jinpeng Wei Department of Computer Science School of Computing and Information Sciences University of Tsukuba Florida International University 1-1-1 Tennoudai, Tsukuba, Ibaraki 305-8573, Japan Miami, Florida, USA Email: [email protected] Abstract—This paper describes the implementation of a par- software updates. However, this method does not help to run allel world model using Linux containers. A parallel world the production environment while testing. (or parallel universe) model allows a user to create multiple To address these problems, we propose providing a parallel execution environments, called worlds, in a single operating system and to manipulate these worlds. This model enables world model at the operating system level. A parallel world or a system administrator to create a new test world that looks parallel universe model is a model to describe time machines like a production world. The system administrator upgrades in science fiction (SF) and to interpret observations in quantum fundamental software and tests applications in the new test physics. In our parallel world model at the operating system world while running the production world. If the applications level, a world is a container of files and an execution environ- do not pass the tests, the administrator deletes the new world. If the applications pass the tests, the administrator merges the ment of processes. Using this parallel world model, a system test world into the production world. Prior to the merge, the administrator can upgrade fundamental software, as follows.
    [Show full text]
  • The Virtual Filesystem Interface in 4.4BSDI
    The Virtual Filesystem Interface in 4.4BSDI Marshall Kirk McKusick Consultant and Author Berkeley, California ABSTRACT: This paper describes the virtual filesys- tem interface found in 4.4BSD. This interface is de- signed around an object oriented virtual file node or "vnode" data structure. The vnode structure is de- scribed along with its method for dynamically expand- ing its set of operations. These operations have been divided into two groups: those to manage the hierarchi- cal filesystem name space and those to manage the flat filestore. The translation of pathnames is described, as it requires a tight coupling between the virtual filesys- tem layer and the underþing filesystems through which the path traverses. This paper describes the filesystem services that are exported from the vnode interface to its clients, both local and remote. It also describes the set of services provided by the vnode layer to its client filesystems. The vnode interface has been generalized to allow multiple filesystems to be stacked together. After describing the stacking functionality, several examples of stacking filesystems are shown. t To appear in The Design and Implementation of the 4.4BSD Operating System, by Marshall Kirk McKusick, publisher. et al., @1995 by Addison-Wesley Publishing Companf Inc. Reprinted with the permission of the o 1995 The USENIX Association, Computing Systems, Vol. 8 ' No. 1 ' Winter 1995 I. The Virtual Filesystem Interface In early UNIX systems, the file entries directly referenced the local filesystem inode, see Figure I [Leffler et al. 1989]. This approach worked fine when there was a single filesystem implementation. However, with the advent of multþle filesystem types, the architecture had to be generalized.
    [Show full text]
  • A NAS Integrated File System for On-Site Iot Data Storage
    A NAS Integrated File System for On-site IoT Data Storage Yuki Okamoto1 Kenichi Arai2 Toru Kobayashi2 Takuya Fujihashi1 Takashi Watanabe1 Shunsuke Saruwatari1 1Graduate School of Information Science and Technology, Osaka University, Japan 2Graduate School of Engineering, Nagasaki University, Japan Abstract—In the case of IoT data acquisition, long-term storage SDFS, multiple NAS can be handled as one file system and of large amounts of sensor data is a significant challenge. When a users can easily add new NAS. cloud service is used, fixed costs such as a communication line for The remainder of this paper is organized as follows. In uploading and a monthly fee are unavoidable. In addition, the use of large-capacity storage servers incurs high initial installation section 2, we discuss the issues associated with the sensor data costs. In this paper, we propose a Network Attached Storage storage. Section 3 describes the overview and implementation (NAS) integrated file system called the “Sensor Data File System of the proposed file system, SDFS. In section 4, we evaluate (SDFS)”, which has advantages of being on-site, low-cost, and the performance of SDFS and existing file systems. Section 5 highly scalable. We developed the SDFS using FUSE, which introduces related work, and Section 6 summarizes the main is an interface for implementing file systems in user-space. In this work, we compared SDFS with existing integrated storage findings of this paper. modalities such as aufs and unionfs-fuse. The results indicate that II. ISSUES ASSOCIATED WITH THE SENSOR DATA STORAGE SDFS achieves an equivalent throughput compared with existing file systems in terms of read/write performance.
    [Show full text]
  • A BRIEF HISTORY of the BSD FAST FILE SYSTEM 9 June07login Press.Qxd:Login June 06 Volume 31 5/27/07 10:22 AM Page 10
    June07login_press.qxd:login June 06 Volume 31 5/27/07 10:22 AM Page 9 I FIRST STARTED WORKING ON THE UNIX file system with Bill Joy in the late MARSHALL KIRK MCKUSICK 1970s. I wrote the Fast File System, now called UFS, in the early 1980s. In this a brief history of article, I have written a survey of the work that I and others have done to the BSD Fast File improve the BSD file systems. Much of System this research has been incorporated into other file systems. Dr. Marshall Kirk McKusick writes books and articles, teaches classes on UNIX- and BSD-related subjects, and provides expert-witness testimony on software patent, trade secret, and copyright issues, particu - 1979: Early Filesystem Work larly those related to operating systems and file sys - tems. While at the University of California at Berke - The first work on the UNIX file system at Berke - ley, he implemented the 4.2BSD Fast File System and was the Research Computer Scientist at the Berkeley ley attempted to improve both the reliability and Computer Systems Research Group (CSRG) oversee - the throughput of the file system. The developers ing the development and release of 4.3BSD and improved reliability by staging modifications to 4.4BSD. critical filesystem information so that the modifi - [email protected] cations could be either completed or repaired cleanly by a program after a crash [14]. Doubling the block size of the file system improved the per - formance of the 4.0BSD file system by a factor of more than 2 when compared with the 3BSD file system.
    [Show full text]
  • Upgrade Without Bricking
    Upgrade without Bricking Arnout Vandecappelle http://mind.be/content/Presentation_Upgrade-without-Bricking.pdf or .odp © 2012 Essensium N.V. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License You never know where your product will be used High-precision GNSS receiver You never know where your product will be used What if you install new firmware on remote systems? What if you install new firmware on remote systems? Murphy's Law What if you install new firmware on remote systems? Murphy's Law Upgrade without Bricking Arnout Vandecappelle http://mind.be/content/Presentation_Upgrade-without-Bricking.pdf or .odp © 2012 Essensium N.V. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License Overview 1 Failure mechanisms ● Power failure ● Bad firmware ● Communication errors 2 Boot loader upgrade 3 Package-based upgrade Overview 1 Failure mechanisms ● Power failure ● Bad firmware ● Communication errors 2 Boot loader upgrade 3 Package-based upgrade Power failure Power fails during upgrade ⇒ new firmware only partially written Solutions: Add fail-safe firmware Detect failed power Atomic update of firmware images Use journalling filesystem for writable data Detecting power failure: Switch to fail-safe firmware 1. Boot current firmware fail- boot current config safe loader firmware files FW Detecting power failure: Switch to fail-safe firmware 2. Switch to fail-safe fail- boot current config safe loader firmware files FW Detecting power failure: Switch to fail-safe firmware fail- boot new config safe loader firmware files FW 3. Overwrite firmware Detecting power failure: Switch to fail-safe firmware 4. Fail-safe restarts upgrade fail- boot new config safe loader firmware files FW Detecting power failure: Switch to fail-safe firmware 5.
    [Show full text]
  • A Method of Merging Vmware Disk Images Through File System Unification by Sarah X
    A Method of Merging VMware Disk Images MASSACHUSETTS INSTITUTE through File System Unification OF TECHN4OLOGY by DEC 16 2010 Sarah X. Cheng LIBRARIES S.B., Computer Science and Engineering, Massachusetts Institute of Technology (2004) Submitted to the Department of Electrical Engineering and Computer Science in partial fulfillment of the requirements for the degree of Master of Engineering in Electrical Engineering and Computer Science at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY ACHIVES February 2011 © Massachusetts Institute of Technology 2011. All rights reserved. -7--) Author ...... ...... Department of Electrical Enginer' d Computer Science October 5, 2010 ... s ..... Certified by............. Stephen A. Ward Professor Thesis Supervisor Accepted by........ Dr. Christopher J. Terman Chairman, Master of Engineering Thesis Committee 2 A Method of Merging VMware Disk Images through File System Unification by Sarah X. Cheng Submitted to the Department of Electrical Engineering and Computer Science on October 5, 2010, in partial fulfillment of the requirements for the degree of Master of Engineering in Electrical Engineering and Computer Science Abstract This thesis describes a method of merging the contents of two VMware disk images by merging the file systems therein. Thus, two initially disparate file systems are joined to appear and behave as a single file system. The problem of file system namespace unification is not a new one, with predecessors dating as far back as 1988 to present-day descendants such as UnionFS and union mounts. All deal with the same major issues - merging directory contents of source branches and handling any naming conflicts (namespace de-duplication), and allowing top-level edits of file system unions in presence of read-only source branches (copy-on-write).
    [Show full text]
  • Use the Overlayfs Storage Driver | Docker Documentation
    Use the OverlayFS storage driver Estimated reading time: 18 minutes OverlayFS is a modern union filesystem that is similar to AUFS, but faster and with a simpler implementation. Docker provides two storage drivers for OverlayFS: the original overlay , and the newer and more stable overlay2 . This topic refers to the Linux kernel driver as OverlayFS and to the Docker storage driver as overlay or overlay2 . ! Note:: IfIf youyou useuse OverlayFS,OverlayFS, useuse thethe overlay2 driverdriver ratherrather thanthan thethe overlay driver,driver, becausebecause itit isis moremore eefficient in terms of inode utilization. To use the new driver, you need version 4.0 or higher of thethe LinuxLinux kernel,kernel, oror RHELRHEL oror CentOSCentOS usingusing versionversion 3.10.0-5143.10.0-514 andand above. For more information about differences between overlay vs overlay2 , check Docker storage drivers (https://docs.docker.com/storage/storagedriver/select-storage-driver/). Prerequisites OverlayFS is supported if you meet the following prerequisites: The overlay2 driver is supported on Docker CE, and Docker EE 17.06.02-ee5 and up, and is the recommended storage driver. Version 4.0 or higher of the Linux kernel, or RHEL or CentOS using version 3.10.0-514 of the kernel or higher. If you use an older kernel, you need to use the overlay driver, which is not recommended. The overlay and overlay2 drivers are supported on xfs backing filesystems, but only with d_type=true enabled. Use xfs_info to verify that the ftype option is set to 1 . To format an xfs filesystem correctly, use the flag -n ftype=1 .
    [Show full text]
  • Docker Containers for HEP - first Steps
    docker containers for HEP - first steps Sébastien Binet LAL/IN2P3 2014-05-21 S. Binet (LAL) docker 2014-05-21 1 / 19 Outline What ? Why ? How ? (When ?) S. Binet (LAL) docker 2014-05-21 2 / 19 Docker: what is it ? http://www.docker.io/ an open source project to pack, ship and run any application as a lightweight container High level description kind of like a lightweightVM runs in its own process space has its own network interface can run stuff as root Low level description chroot on steroids container = isolated process(es) share kernel with host no device emulation S. Binet (LAL) docker 2014-05-21 3 / 19 Docker: why ? same use cases than for VMs speed: boots in (milli)seconds footprint: 100-1000 containers on a single machine/laptop. small disk requirements Containers vs. VMs S. Binet (LAL) docker 2014-05-21 4 / 19 Docker: why ? Efficiency: almost no overhead processes are isolated but run straight on the host CPU performance = native performance memory performance = a few % shaved off for (optional) accounting network perfomace = small overhead Efficiency: storage friendly unioning filesystems snapshotting filesystems copy-on-write provisionning takes a few milliseconds . and a few kilobytes creating a new container/base-image takes a few seconds S. Binet (LAL) docker 2014-05-21 5 / 19 Docker: how ? LinuX Containers (LXC) Control Groups and Namepsaces AUFS (overlaying filesystem), or BTRFS, or DeviceMapper Client-Server with an http/REST API LXC Let’s your run a Linux system within another Linux system A container is a group of processes on a Linux box, put together is an isolated environment From the inside, it looks like a VM.
    [Show full text]
  • State of the Union When You Don’T Need Union Mounts
    State of the Union When you don't need Union Mounts Jan Blunck Novell [email protected] 30. October 2009 What Union? I Not the European Union ... this is Dresden not Brussels I This is about Filesystems I In particular about Filesystem Namespace Unification What Union? I Not the European Union ... this is Dresden not Brussels I This is about Filesystems I In particular about Filesystem Namespace Unification What Union? I Not the European Union ... this is Dresden not Brussels I This is about Filesystems I In particular about Filesystem Namespace Unification Outline Introduction Where is the Problem? Unioning Filesystems UnionFS Another UnionFS UnionFS-FUSE mini fo Union Mount You probably don't need Union Mounts Device-Mapper Snapshot Delta Filesystem CLIC Filesystem SquashFS Fake Write Support Shared root filessytem - NFS Root Shared root filessytem - XIP Whats left to do than? Thanks Disclaimer I'm the author of the VFS based Union Mount patches. That somehow makes me biased. I'll try my very best though ... Where is the Problem? POSIX Requirements I seek to cookie POSIX is missing I whiteout filetype DT WHITEOUT I topology of mount tree I open (directories) by inode number Where is the Problem? POSIX Requirements I seek to cookie POSIX is missing I whiteout filetype DT WHITEOUT I topology of mount tree I open (directories) by inode number Where is the Problem? I NFS Sucks ftp://ftp.lst.de/pub/people/okir/papers/2006-OLS/ nfs-sucks-slides.pdf Where is the Problem? I NFS Sucks ftp://ftp.lst.de/pub/people/okir/papers/2006-OLS/ nfs-sucks-slides.pdf
    [Show full text]
  • Liveng Documentation Release 1.0
    liveng Documentation Release 1.0 LumIT Labs Feb 04, 2019 Contents 1 Why liveng 3 2 More features 5 3 Table of contents 7 3.1 Standard Debian live...........................................7 3.2 Set up a standard Debian live......................................8 3.3 liveng structure..............................................9 3.4 UEFI Secure Boot............................................ 14 3.5 Persistence................................................ 16 3.6 Kernel update............................................... 21 3.7 Kernel update, the Debian way...................................... 23 3.8 Kernel update improvements....................................... 24 3.9 About liveng............................................... 25 3.10 liveng-based operating systems and tools................................ 25 3.11 License.................................................. 25 i ii liveng Documentation, Release 1.0 Next Generation Linux live distributions concepts A live operating system allows booting from a removable medium, such a USB key, without the need of being installed to the hard drive. Contents 1 liveng Documentation, Release 1.0 2 Contents CHAPTER 1 Why liveng None of the existing ISO9660-based live operating systems provide a kernel update feature: the kernel and the initrd are the only components that a live operating system cannot update, because they lay outside of the data persistence partition and the system partition is ISO9660-formatted, so not writeable - which is the best option for a live, because of its strength
    [Show full text]
  • Linux - Hard Drives, Partitions and Filesystems Naming Convention
    Linux - Hard Drives, Partitions and Filesystems Naming Convention IDE drives are referred to as hda for the first drive, hdb for the second etc. Serial ATA and SCSI drives are referenced as sda, sdb etc. Hard drive partitions are represented by an additional number. The partitions on each drive are referred numerically. The first partition on the first drive is referred to as hda1, the second as hda2, the third as hda3 etc. Linux IDE naming conventions: Device Description Configuration /dev/(s)hda 1st (Primary) IDE controller Master /dev/(s)hdb 1st (Primary) IDE controller Slave /dev/(s)hdc 2nd (Secondary) IDE controller Master /dev/(s)hdd 2nd (Secondary) IDE controller Slave Linux SATA/SCSI naming conventions: /dev/sda 1st SATA /dev/sdb 2nd SATA Partitioning A computer system may have multiple drives with primary partitions but only one primary partition may be active on one drive only. The active primary partition is used for booting the system and is referenced by the Master Boot Record (MBR). Each hard drive may only have a maximum of four primary partitions. You must an OS from a primary partition. Extended partitions allow one to place up to 24 partitions on a single drive. The first partition on the first drive is referred to as hda1, the second as hda2, the third as hda3 etc. Use the fdisk command under LINUX to partition a hardrive. Implicit in the fdisk command is the mkdev command that creates the device file for the partition. On sime UNIX systems, the mkdev command is explicitly used to create the device file.
    [Show full text]
  • Freebsd and Openbsd Are Increasingly Gaining Traction In
    < Day Day Up > Mastering FreeBSD and OpenBSD Security By Paco Hope, Yanek Korff, Bruce Potter ............................................... Publisher: O'Reilly Pub Date: March 2005 ISBN: 0-596-00626-8 Pages: 464 Table of Contents | Index | Errata FreeBSD and OpenBSD are increasingly gaining traction in educational institutions, non- profits, and corporations worldwide because they provide significant security advantages over Linux. Although a lot can be said for the robustness, clean organization, and stability of the BSD operating systems, security is one of the main reasons system administrators use these two platforms. There are plenty of books to help you get a FreeBSD or OpenBSD system off the ground, and all of them touch on security to some extent, usually dedicating a chapter to the subject. But, as security is commonly named as the key concern for today's system administrators, a single chapter on the subject can't provide the depth of information you need to keep your systems secure. FreeBSD and OpenBSD are rife with security "building blocks" that you can put to use, and Mastering FreeBSD and OpenBSD Security shows you how. Both operating systems have kernel options and filesystem features that go well beyond traditional Unix permissions and controls. This power and flexibility is valuable, but the colossal range of possibilities need to be tackled one step at a time. This book walks you through the installation of a hardened operating system, the installation and configuration of critical services, and ongoing maintenance of your FreeBSD and OpenBSD systems. Using an application-specific approach that builds on your existing knowledge, the book provides sound technical information on FreeBSD and Open-BSD security with plenty of real- world examples to help you configure and deploy a secure system.
    [Show full text]