Security-Enhanced Darwin: Porting Selinux to Mac OS X
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Building a SAN-Less Private Cloud with IBM Powervm and IBM Powervc
Front cover Building a SAN-less Private Cloud with IBM PowerVM and IBM PowerVC Javier Bazan Lazcano Stephen Lutz Redpaper International Technical Support Organization Building a SAN-less Private Cloud with IBM PowerVM and IBM PowerVC July 2018 REDP-5455-02 Note: Before using this information and the product it supports, read the information in “Notices” on page v. Third Edition (July 2018) This edition applies to Version 1, Release 4, Modification 1 of IBM Cloud PowerVC Manager for Software-Defined Infrastructure V1.1 (product number 5765-VCD). © Copyright International Business Machines Corporation 2017, 2018. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . .v Trademarks . vi Preface . vii Authors. vii Now you can become a published author, too! . viii Comments welcome. viii Stay connected to IBM Redbooks . viii Chapter 1. Architecture of a software-defined infrastructure solution with IBM Power Systems servers and IBM PowerVC . 1 1.1 Software-defined infrastructure . 2 1.2 The motivation behind software-defined infrastructure . 2 1.3 Use cases . 4 1.3.1 Use case 1: Building a storage area network-less cloud . 4 1.3.2 Use case 2: Building an iSCSI-backed cloud . 5 1.3.3 More use cases. 5 1.4 Rack topologies and components . 6 1.4.1 Starter cloud . 7 1.4.2 Mini cloud . 8 1.4.3 Rack scale . 9 1.4.4 Storage/management switches. 10 1.4.5 Data switches . 10 1.4.6 Network nodes . -
Debugging Kernel Problems
Debugging Kernel Problems by GregLehey Edition for AsiaBSDCon 2004 Taipei, 13 March 2004 Debugging Kernel Problems by GregLehey([email protected]) Copyright © 1995-2004 GregLehey 3Debugging Kernel Problems Preface Debugging kernel problems is a black art. Not manypeople do it, and documentation is rare, in- accurate and incomplete. This document is no exception: faced with the choice of accuracyand completeness, I chose to attempt the latter.Asusual, time was the limiting factor,and this draft is still in beta status. This is a typical situation for the whole topic of kernel debugging: building debug tools and documentation is expensive,and the people who write them are also the people who use them, so there'satendencytobuild as much of the tool as necessary to do the job at hand. If the tool is well-written, it will be reusable by the next person who looks at a particular area; if not, it might fall into disuse. Consider this book a starting point for your own develop- ment of debugging tools, and remember: more than anywhere else, this is an area with ``some as- sembly required''. Debugging Kernel Problems 4 1 Introduction Operating systems fail. All operating systems contain bugs, and theywill sometimes cause the system to behave incorrectly.The BSD kernels are no exception. Compared to most other oper- ating systems, both free and commercial, the BSD kernels offer a large number of debugging tools. This tutorial examines the options available both to the experienced end user and also to the developer. In this tutorial, we’ll look at the following topics: • Howand whykernels fail. -
Virtual Memory - Paging
Virtual memory - Paging Johan Montelius KTH 2020 1 / 32 The process code heap (.text) data stack kernel 0x00000000 0xC0000000 0xffffffff Memory layout for a 32-bit Linux process 2 / 32 Segments - a could be solution Processes in virtual space Address translation by MMU (base and bounds) Physical memory 3 / 32 one problem Physical memory External fragmentation: free areas of free space that is hard to utilize. Solution: allocate larger segments ... internal fragmentation. 4 / 32 another problem virtual space used code We’re reserving physical memory that is not used. physical memory not used? 5 / 32 Let’s try again It’s easier to handle fixed size memory blocks. Can we map a process virtual space to a set of equal size blocks? An address is interpreted as a virtual page number (VPN) and an offset. 6 / 32 Remember the segmented MMU MMU exception no virtual addr. offset yes // < within bounds index + physical address segment table 7 / 32 The paging MMU MMU exception virtual addr. offset // VPN available ? + physical address page table 8 / 32 the MMU exception exception virtual address within bounds page available Segmentation Paging linear address physical address 9 / 32 a note on the x86 architecture The x86-32 architecture supports both segmentation and paging. A virtual address is translated to a linear address using a segmentation table. The linear address is then translated to a physical address by paging. Linux and Windows do not use use segmentation to separate code, data nor stack. The x86-64 (the 64-bit version of the x86 architecture) has dropped many features for segmentation. -
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 -
Moving FLASK to BSD Systems
MovingMoving FLASKFLASK toto BSDBSD SSystemsystems SELinux Symposium 2006 Chris Vance Information Systems Security Operation, SPARTA, Inc. Vance_20060301_01 Overview • Security Frameworks • A Brief History • SELinux Inspired… – Security Enhanced BSD – Security Enhanced Darwin Vance_20060301_02 Security Frameworks • Traditional UNIX security isn’t enough – OS hardening – Mandatory protection – Flexible, manageable, scalable protection • Support required in the operating system for new security services – Costs of locally maintaining security extensions are high – Framework offers extensibility so that policies may be enhanced without changing the base operating system • There does not appear to be one perfect security model or policy – Sites may have different security/performance trade-offs – Sites may have special local requirements – Vendors unlikely to adopt a single policy • Bottom Line: Frameworks for Linux, FreeBSD, Darwin Vance_20060301_03 How We Got Here… Vance_20060301_04 Focus and Reuse • Don’t “reinvent” security – Learn from the past – The research is often decades old – A good design is durable, doesn’t require constant change – FLASK hasn’t changed much recently, what’s that mean? • Leverage existing technology, focus on “new” issues – Focus on improving operating system security – Spend the time to get Frameworks correct – Work with vendor for acceptance – Develop rule sets that work – Develop effective tools to manage policy • Do innovate – Don’t stop thinking! – Don’t squash new ideas – Re-factor old ideas Vance_20060301_05 -
Virtual Memory in X86
Fall 2017 :: CSE 306 Virtual Memory in x86 Nima Honarmand Fall 2017 :: CSE 306 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 • 1 MB of usable memory • No paging • No user mode; processor has only one protection level • Protected mode – Standard 32-bit x86 mode • Combination of segmentation and paging • Privilege levels (separate user and kernel) • 32-bit virtual address • 32-bit physical address • 36-bit if Physical Address Extension (PAE) feature enabled Fall 2017 :: CSE 306 x86 Processor Modes • Long mode – 64-bit mode (aka amd64, x86_64, etc.) • Very similar to 32-bit mode (protected mode), but bigger address space • 48-bit virtual address space • 52-bit physical address space • Restricted segmentation use • Even more obscure modes we won’t discuss today xv6 uses protected mode w/o PAE (i.e., 32-bit virtual and physical addresses) Fall 2017 :: CSE 306 Virt. & Phys. Addr. Spaces in x86 Processor • Both RAM hand hardware devices (disk, Core NIC, etc.) connected to system bus • Mapped to different parts of the physical Virtual Addr address space by the BIOS MMU Data • You can talk to a device by performing Physical Addr read/write operations on its physical addresses Cache • Devices are free to interpret reads/writes in any way they want (driver knows) System Interconnect (Bus) : all addrs virtual DRAM Network … Disk (Memory) Card : all addrs physical Fall 2017 :: CSE 306 Virt-to-Phys Translation in x86 0xdeadbeef Segmentation 0x0eadbeef Paging 0x6eadbeef Virtual Address Linear Address Physical Address Protected/Long mode only • Segmentation cannot be disabled! • But can be made a no-op (a.k.a. -
Operating Systems
UC Santa Barbara Operating Systems Christopher Kruegel Department of Computer Science UC Santa Barbara http://www.cs.ucsb.edu/~chris/ Virtual Memory and Paging UC Santa Barbara • What if a program is too big to be loaded in memory • What if a higher degree of multiprogramming is desirable • Physical memory is split in page frames • Virtual memory is split in pages • OS (with help from the hardware) manages the mapping between pages and page frames 2 Mapping Pages to Page Frames UC Santa Barbara • Virtual memory: 64KB • Physical memory: 32KB • Page size: 4KB • Virtual memory pages: 16 • Physical memory pages: 8 3 Memory Management Unit UC Santa Barbara • Automatically performs the mapping from virtual addresses into physical addresses 4 Memory Management Unit UC Santa Barbara • Addresses are split into a page number and an offset • Page numbers are used to look up a table in the MMU with as many entries as the number of virtual pages • Each entry in the table contains a bit that states if the virtual page is actually mapped to a physical one • If it is so, the entry contains the number of physical page used • If not, a page fault is generated and the OS has to deal with it 5 Page Tables UC Santa Barbara • Page tables contain an entry for each virtual table • If virtual memory is big (e.g., 32 bit and 64 bit addresses) the table can become of unmanageable size • Solution: instead of keeping them in the MMU move them to main memory • Problem: page tables are used each time an access to memory is performed. -
Operating System Structure
Operating System Structure Joey Echeverria [email protected] modified by: Matthew Brewer [email protected] Nov 15, 2006 Carnegie Mellon University: 15-410 Fall 2006 Overview • Motivations • Kernel Structures – Monolithic Kernels ∗ Kernel Extensions – Open Systems – Microkernels – Exokernels – More Microkernels • Final Thoughts Carnegie Mellon University: 15-410 Fall 2006 1 Motivations • Operating systems have a hard job. • Operating systems are: – Hardware Multiplexers – Abstraction layers – Protection boundaries – Complicated Carnegie Mellon University: 15-410 Fall 2006 2 Motivations • Hardware Multiplexer – Each process sees a “computer” as if it were alone – Requires allocation and multiplexing of: ∗ Memory ∗ Disk ∗ CPU ∗ IO in general (network, graphics, keyboard etc.) • If OS is multiplexing it must also allocate – Priorities, Classes? - HARD problems!!! Carnegie Mellon University: 15-410 Fall 2006 3 Motivations • Abstraction Layer – Presents “simple”, “uniform” interface to hardware – Applications see a well defined interface (system calls) ∗ Block Device (hard drive, flash card, network mount, USB drive) ∗ CD drive (SCSI, IDE) ∗ tty (teletype, serial terminal, virtual terminal) ∗ filesystem (ext2-4, reiserfs, UFS, FFS, NFS, AFS, JFFS2, CRAMFS) ∗ network stack (TCP/IP abstraction) Carnegie Mellon University: 15-410 Fall 2006 4 Motivations • Protection Boundaries – Protect processes from each other – Protect crucial services (like the kernel) from process – Note: Everyone trusts the kernel • Complicated – See Project 3 :) – Full -
Lecture 15 15.1 Paging
CMPSCI 377 Operating Systems Fall 2009 Lecture 15 Lecturer: Emery Berger Scribe: Bruno Silva,Jim Partan 15.1 Paging In recent lectures, we have been discussing virtual memory. The valid addresses in a process' virtual address space correspond to actual data or code somewhere in the system, either in physical memory or on the disk. Since physical memory is fast and is a limited resource, we use the physical memory as a cache for the disk (another way of saying this is that the physical memory is \backed by" the disk, just as the L1 cache is \backed by" the L2 cache). Just as with any cache, we need to specify our policies for when to read a page into physical memory, when to evict a page from physical memory, and when to write a page from physical memory back to the disk. 15.1.1 Reading Pages into Physical Memory For reading, most operating systems use demand paging. This means that pages are only read from the disk into physical memory when they are needed. In the page table, there is a resident status bit, which says whether or not a valid page resides in physical memory. If the MMU tries to get a physical page number for a valid page which is not resident in physical memory, it issues a pagefault to the operating system. The OS then loads that page from disk, and then returns to the MMU to finish the translation.1 In addition, many operating systems make some use of pre-fetching, which is called pre-paging when used for pages. -
IBM Worklight V5.0.6 Technology Overview
IBM Software Technical White Paper WebSphere IBM Worklight V5.0.6 Technology overview IBM Worklight—Overview Contents IBM® Worklight® software helps enable organizational leaders to extend their business to mobile devices. This software provides an open, 1 IBM Worklight—Overview comprehensive and advanced mobile application platform for smart- phones and tablets, helping organizations of all sizes to efficiently 2 IBM Worklight—Components develop, connect, run and manage mobile and omni-channel applications. 3 Development tools Leveraging standards-based technologies and tools, the IBM team has created Worklight software that provides a single integrated platform. 8 Runtime server environment This platform includes a comprehensive development environment, 9 The IBM Worklight Console mobile-optimized runtime middleware, a private enterprise application store and an integrated management and analytics console—all supported 9 IBM Worklight Device by a variety of security mechanisms. Runtime components 10 Security and authentication Develop. The IBM Worklight Studio and the IBM Worklight software mechanisms development kit (SDK) simplify the development of mobile and omni- channel applications (apps) throughout multiple mobile platforms, includ- ing iOS, Android, BlackBerry, Windows 8, Windows Phone and Java ME. The IBM Worklight optimization framework fosters code reuse while delivering rich user experiences that match the styling requirements of each target environment. With such code reuse, IBM Worklight reduces costs of development, reduces time-to-market and provides strong support for your ongoing management efforts. Connect. The IBM Worklight Server architecture and adapter technol- ogy simplifies the integration of mobile apps with back-end enterprise systems and cloud-based services. The IBM Worklight Server is designed IBM Software Technical White Paper WebSphere to fit quickly into your organization’s IT infrastructure and is Console. -
Chapter 2 Operating System Structures
Operating Systems Associate Prof. Yongkun Li 中科大-计算机学院 副教授 http://staff.ustc.edu.cn/~ykli Chapter 2 Operating System Structures 1 Objectives • Operating System Services – User Operating System Interface – System Calls • Operating System Structure • Operating System Design and Implementation • MISC: Debugging, Generation & System Boot 2 Operating System Services Services Overview, User Interface 3 Operating System Services • Operating systems provide – an environment for execution of programs and – services to programs and users • Services may differ from one OS to another • What are the common classes? – Convenience of the user – Efficiency of the system 4 Overview of Operating System Services 5 OS Services for Helping Users • User interface - Almost all operating systems have a user interface (UI). – Three forms • Command-Line (CLI) – Shell command • Batch – Shell script • Graphics User Interface (GUI) – Windows system 6 OS Services for Helping Users • Program execution – Load a program into memory – Run the program – End execution • either normally or • abnormally (indicating error) 7 OS Services for Helping Users • I/O operations - A running program may require I/O, which may involve a file or an I/O device – Common I/Os: read, write, etc. – Special functions: recording CD/DVD • Notes: Users usually cannot control I/O devices directly, so OS provides a mean to do I/O – Mainly for efficiency and protection 8 OS Services for Helping Users • File-system manipulation - The file system is of particular interest – OS provides a variety of file systems • Major services – read and write files and directories – create and delete files and directories – search for a given file – list file Information – permission management: allow/deny access 9 OS Services for Helping Users • Communications: information exchange between processes – Processes on the same computer – Processes between computers over a network • Implementations – Shared memory • Two or more processes read/write to a shared section of mem. -
Darwin: Mac OS X's Core OS
ADC April 2001 3/8/01 1:57 PM Page 1 Apple Developer Connection Direct Darwin: Mac OS X’s Core OS eneath Mac OS X’s user-friendly and attractive user interface, Most of the reference documents can be Aqua, and the application frameworks (Classic, Carbon and found in the /Developer/Documentation/ BCocoa) is Darwin: Mac OS X’s core OS. Unseen by users, Kernel directory on any Mac OS X system Darwin provides a strong yet flexible foundation with features like with the Mac OS X Developer Tools package preemptive multitasking, protected memory and real-time support installed. that make Mac OS X a truly modern operating system. The focus of this article is to provide a brief overview of Components of Darwin Darwin and its components as well as give an introduction to Just like in the old Reese’s Peanut Butter developing kernel extensions—modules that extend Darwin’s Cups commercials (“You’ve got chocolate in functionality. For more in-depth information, you should read my peanut butter… No, you’ve got peanut butter on my choco- Inside Mac OS X: Kernel Environment which is available, along late!”), Darwin blends a mixture of mature industry standard com- with other documents referred to in this article, on the Apple ponents such as Mach and BSD with Apple-engineered components Developer Connection (ADC) web site in the Mac OS X to provide Mac OS X with a stable, reliable and extensible founda- Documentation section: tion. Darwin consists of five main components: Mach, I/O Kit, File http://developer.apple.com/techpubs/macosx/macosx.html System, Networking and BSD.