The Cryptographic Disk Driver Roland C

Total Page:16

File Type:pdf, Size:1020Kb

The Cryptographic Disk Driver Roland C The CryptoGraphic Disk Driver Roland C. Dowdeswell John Ioannidis [email protected] [email protected] The NetBSD Project AT&T Labs – Research Abstract caching of data blocks less effective and have a serious We present the design and implementation of CGD, overall impact on performance. CFS also does not pro- the CryptoGraphic Disk driver. CGD is a pseudo-device tect the filesystem metadata as it encrypts each file sep- driver that sits below the buffer cache, and provides an arately and does not encrypt file system meta-data. It encrypted view of an underlying raw partition. It was de- may be possible in many scenarios to get much of the signed with high performance and ease of use in mind. information that is desired simply by examining the di- CGD is aimed at laptops, other single-user computers or rectory layout. TCFS also uses NFS as its transport, but removable storage, where protection from other concur- operates as an NFS client rather than a server. TCFS has rent users is not essential, but protection against loss or many more features than CFS, but also shares the draw- theft is important. backs of using NFS. To fulfill the needs for secure file storage in a laptop 1 Introduction environment, we built the CryptoGraphic Disk (CGD). The number of laptop users is increasing continuously, CGD is a device driver that looks just like an ordinary and with it the amount of sensitive data that resides out- disk drive, and encrypts an entire real disk partition. It side traditional data protection mechanisms—physical is thus suited for single-user environments (mostly lap- (security guards) or electronic (firewalls). There have tops) where protection from other users on the same ma- been several well-publicized cases of top executives hav- chine is not essential, but protection against physical loss ing their laptops lost or stolen, with highly sensitive is paramount, as is high performance. CGD was written corporate data in them [3]. In fact, any potentially re- for and is available in NetBSD, but can be readily ported movable storage suffers from such threats, as the case to any other BSD-derivative with very few changes. of the missing disk drives from a government research This is a similar approach to that taken by OpenBSD’s lab around 2000 [1] demonstrates. Some of the cases vnd(4) driver, FreeBSD’s GEOM driver and Linux’s involved the violation of doctor–patient privilege [10] loopback mounts. Each of these has a few drawbacks. which may expose doctors or hospitals to liability for OpenBSD’s vnd(4) driver and FreeBSD’s GEOM driver disclosing confidential patient data. When computers do not present a modular framework for defining encryp- are retired, the hard drives may contain sensitive data, tion methods which we discuss in Section 2. We dis- complicating their disposal. Cryptography provides the cuss some of the drawbacks of a vnd approach in Sec- ultimate protection in such cases, but while there exist tion 2.1. In Section 2.2, we discuss how OpenBSD’s many techniques and systems that employ cryptography vnd(4) driver, FreeBSD’s GEOM driver and Linux’s to protect files, many of them are cumbersome to use, loopback mounts do not have flexible key generation require expertise beyond that of the common user, or mechanisms, do not allow for n-factor authentication (unfortunately, in the case of many commercial systems) and do not adequately protect from dictionary attacks offer less security than advertised. We review some of against the pass phrase. these approaches in Section 4. There are many existing solutions to this problem, 2 Architecture and Implementation such as CFS[4], TCFS[5], OpenBSD’s vnd(4) encryp- In setting out to create a secure local storage facility tion, FreeBSD’s GEOM encryption, Linux’s loopback for Unix workstations, the main design considerations encryption, Cryptfs[17] and NCryptfs[16]. CFS and were flexibility, modularity, performance and robust- TCFS operate over the file system layer and for that rea- ness. The flexibility consideration implied the virtual son are well suited to encrypting files stored over a dis- disk approach. Using the disk-driver interface as the tributed file system such as NFS. CFS is implemented chosen abstraction gives its potential users the freedom as a userland NFS server and gains much in the way of to use any kind of file system they want on top of it, be portability, but unfortunately gains all of the drawbacks it FFS, swap space, or even space for a database appli- of NFS in the process. The semantics of NFS even on cation that writes to the raw partition. the local machine make file locking less reliable, make It is important that the design be modular since break- throughs in cryptanalysis are unpredictable and frequent. increases the number of places where deadlocks can oc- Being tied to a single cipher, a single method for choos- cur. In fact, we have run into such problems when trying ing IVs or a single method for generating keys would to run a system entirely off vnd disks on top of msdosfs force users to upgrade critical operating system compo- files. Secondly, because we are laying out an FFS (or nents upon the discovery of weaknesses or vulnerabil- some other) filesystem on top of a file which has already ities. Modularity also allows for use to be tailored to been laid out in an FFS filesystem, the upper filesystem a specific threat model. Allowing multiple ciphers en- will make block allocations based on erroneous assump- ables the user to perform cost-benefit analysis based on tions of block locality; these destroy many of the advan- an evaluation of their risk. Allowing multiple key gen- tages of the FFS layout algorithms. Experience with vnd eration methods allows CGD to be used under different actually indicates that this degradation is not that pro- threat models. For example, unattended booting might nounced, but that may be an artifact of the actual work- be a requirement and in this case it would make sense to load. Lastly, adding crypto to vnd as a way of provid- retrieve the keys from a GSS–API key server. N–factor ing an encrypted disk runs into ease-of-use problems. authentication might be required and CGD provides for To do so, a user would have to create a filesystem on this. the disk, allocate a single maximal-sized file, configure The performance consideration led to the decision it with vnd and partition the resulting pseudo-disk. At- to place the cryptographic disk functionality below the taching and mounting at runtime also add their share of buffer cache; that is, create a virtual disk driver that di- complexity. Complexity for the user is unacceptable un- rectly accesses the raw disk beneath it. This allows all less it delivers value; it is preferable to spend extra effort kernel-level (or even user-level) software that makes as- once if it results in easier use. Moreover, a user will im- sumptions about disk layout to work (whether these as- mediately recognize that, for example, /dev/cgd0a is an sumptions are justified is beyond the scope of this pa- encrypted device, rather than have to remember whether per). they configured the /dev/vnd0a with or without encryp- The robustness consideration led to the decision to tion. This last reason is why we did not release a null place the most complex code in user land in the con- encryption transform. figuration utility. The user land configuration utility per- CGD is a pseudo disk, in the same vein as the concate- forms all key management, key retrieval, etc. This leaves nated disk driver (ccd(4)) or RAIDframe (raid(4)). Ccd the kernel code the easier task of encrypting blocks takes multiple partitions and presents them as a single which makes the kernel code straightforward to audit. disk by either concatenating them or interleaving their The main disadvantage of the pseudo–disk approach blocks (RAID 0). RAIDframe uses the same techniques is that there is no per-user keying or any other per-user to provide RAID 0, 1, 4, and 5. cryptographic isolation. For better or worse, the security A disk device presents both a block interface and a model of Unix is left unchanged. This, of course, is not character interface. CGD does its interesting work in the a problem in the intended user-base for CGD, namely, strategy() call in the block interface and the ioctl() call in laptop users or owners of removable storage in national the character interface. The rest of the interface simply nuclear research laboratories. In any case, if the oper- presents a normal disk/pseudo-disk in the same way as ating system is not trusted to provide adequate protec- ccd(4), raid(4) or vnd(4). For further information about tion, potential intruders can read keys or buffer blocks the block and character devices please refer to “The De- off /dev/kmem anyway, so this is not as big a problem as sign and Implementation of the 4.4BSD Operating Sys- it first appears. tem”[11]. For the purposes of this project, we imple- The CGD code base consists of two parts: a kernel mented a generic set of functions that could be shared driver and user-level configuration software. We exam- by all of the pseudo–disks to simplify the code. ine these two parts next. The ioctl() function responds to all the normal disk ioctl(2)s and also presents two more: CGDIOCSET and 2.1 The Kernel Driver CGDIOCCLR.
Recommended publications
  • Package 'Filelock'
    Package ‘filelock’ October 5, 2018 Title Portable File Locking Version 1.0.2 Author Gábor Csárdi Maintainer Gábor Csárdi <[email protected]> Description Place an exclusive or shared lock on a file. It uses 'LockFile' on Windows and 'fcntl' locks on Unix-like systems. License MIT + file LICENSE LazyData true URL https://github.com/r-lib/filelock#readme BugReports https://github.com/r-lib/filelock/issues RoxygenNote 6.0.1.9000 Suggests callr (>= 2.0.0), covr, testthat Encoding UTF-8 NeedsCompilation yes Repository CRAN Date/Publication 2018-10-05 10:30:12 UTC R topics documented: lock .............................................2 Index 5 1 2 lock lock Advisory File Locking and Unlocking Description There are two kinds of locks, exclusive and shared, see the exclusive argument and other details below. Usage lock(path, exclusive = TRUE, timeout = Inf) unlock(lock) Arguments path Path to the file to lock. If the file does not exist, it will be created, but the directory of the file must exist. Do not place the lock on a file that you want to read from or write to! *Always use a special lock file. See details below. exclusive Whether to acquire an exclusive lock. An exclusive lock gives the process ex- clusive access to the file, no other processes can place any kind of lock on it. A non-exclusive lock is a shared lock. Multiple processes can hold a shared lock on the same file. A process that writes to a file typically requests an exclusive lock, and a process that reads from it typically requests a shared lock.
    [Show full text]
  • The Complete Freebsd
    The Complete FreeBSD® If you find errors in this book, please report them to Greg Lehey <grog@Free- BSD.org> for inclusion in the errata list. The Complete FreeBSD® Fourth Edition Tenth anniversary version, 24 February 2006 Greg Lehey The Complete FreeBSD® by Greg Lehey <[email protected]> Copyright © 1996, 1997, 1999, 2002, 2003, 2006 by Greg Lehey. This book is licensed under the Creative Commons “Attribution-NonCommercial-ShareAlike 2.5” license. The full text is located at http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode. You are free: • to copy, distribute, display, and perform the work • to make derivative works under the following conditions: • Attribution. You must attribute the work in the manner specified by the author or licensor. • Noncommercial. You may not use this work for commercial purposes. This clause is modified from the original by the provision: You may use this book for commercial purposes if you pay me the sum of USD 20 per copy printed (whether sold or not). You must also agree to allow inspection of printing records and other material necessary to confirm the royalty sums. The purpose of this clause is to make it attractive to negotiate sensible royalties before printing. • Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. • For any reuse or distribution, you must make clear to others the license terms of this work. • Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above.
    [Show full text]
  • Freebsd Handbook
    FreeBSD Handbook http://www.freebsd.org/doc/en_US.ISO8859-1/books/han... FreeBSD Handbook The FreeBSD Documentation Project Copyright © 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013 The FreeBSD Documentation Project Welcome to FreeBSD! This handbook covers the installation and day to day use of FreeBSD 8.3-RELEASE and FreeBSD 9.1-RELEASE. This manual is a work in progress and is the work of many individuals. As such, some sections may become dated and require updating. If you are interested in helping out with this project, send email to the FreeBSD documentation project mailing list. The latest version of this document is always available from the FreeBSD web site (previous versions of this handbook can be obtained from http://docs.FreeBSD.org/doc/). It may also be downloaded in a variety of formats and compression options from the FreeBSD FTP server or one of the numerous mirror sites. If you would prefer to have a hard copy of the handbook, you can purchase one at the FreeBSD Mall. You may also want to search the handbook. REDISTRIBUTION AND USE IN SOURCE (XML DOCBOOK) AND 'COMPILED' FORMS (XML, HTML, PDF, POSTSCRIPT, RTF AND SO FORTH) WITH OR WITHOUT MODIFICATION, ARE PERMITTED PROVIDED THAT THE FOLLOWING CONDITIONS ARE MET: 1. REDISTRIBUTIONS OF SOURCE CODE (XML DOCBOOK) MUST RETAIN THE ABOVE COPYRIGHT NOTICE, THIS LIST OF CONDITIONS AND THE FOLLOWING DISCLAIMER AS THE FIRST LINES OF THIS FILE UNMODIFIED. 2. REDISTRIBUTIONS IN COMPILED FORM (TRANSFORMED TO OTHER DTDS, CONVERTED TO PDF, POSTSCRIPT, RTF AND OTHER FORMATS) MUST REPRODUCE THE ABOVE COPYRIGHT NOTICE, THIS LIST OF CONDITIONS AND THE FOLLOWING DISCLAIMER IN THE DOCUMENTATION AND/OR OTHER MATERIALS PROVIDED WITH THE DISTRIBUTION.
    [Show full text]
  • Mac OS X for UNIX Users the Power of UNIX with the Simplicity of Macintosh
    Mac OS X for UNIX Users The power of UNIX with the simplicity of Macintosh. Features Mac OS X version 10.3 “Panther” combines a robust and open UNIX-based foundation with the richness and usability of the Macintosh interface, bringing UNIX technology Open source, standards-based UNIX to the mass market. Apple has made open source and standards a key part of its foundation strategy and delivers an operating system built on a powerful UNIX-based foundation •Based on FreeBSD 5 and Mach 3.0 • Support for POSIX, Linux, and System V APIs that is innovative and easy to use. • High-performance math libraries, including There are over 8.5 million Mac OS X users, including scientists, animators, developers, vector/DSP and PowerPC G5 support and system administrators, making Mac OS X the most widely used UNIX-based desktop • Optimized X11 window server for UNIX GUIs operating system. In addition, Mac OS X is the only UNIX-based environment that •Open source code available via the natively runs Microsoft Office, Adobe Photoshop, and thousands of other consumer Darwin project applications—all side by side with traditional command-line, X11, and Java applications. Standards-based networking For notebook computer users, Mac OS X delivers full power management and mobility •Open source TCP/IP-based networking support for Apple’s award-winning PowerBook G4. architecture, including IPv4, IPv6, and L2TP/IPSec •Interoperability with NFS, AFP, and Windows (SMB/CIFS) file servers •Powerful web server (Apache) •Open Directory 2, an LDAP-based directory services
    [Show full text]
  • Managing Network File Systems in Oracle® Solaris 11.4
    Managing Network File Systems in ® Oracle Solaris 11.4 Part No: E61004 August 2021 Managing Network File Systems in Oracle Solaris 11.4 Part No: E61004 Copyright © 2002, 2021, Oracle and/or its affiliates. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software" or "commercial computer software documentation" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the license contained in the applicable contract.
    [Show full text]
  • Portalocker Documentation Release 2.3.2
    Portalocker Documentation Release 2.3.2 Rick van Hattem Aug 27, 2021 CONTENTS 1 portalocker - Cross-platform locking library1 1.1 Overview.................................................1 1.2 Redis Locks...............................................1 1.3 Python 2.................................................2 1.4 Tips....................................................2 1.5 Links...................................................2 1.6 Examples.................................................3 1.7 Versioning................................................4 1.8 Changelog................................................4 1.9 License..................................................4 1.9.1 portalocker package.......................................4 1.9.1.1 Submodules......................................4 1.9.1.2 Module contents....................................9 1.9.2 tests package.......................................... 13 1.9.2.1 Module contents.................................... 13 1.9.3 License............................................. 13 2 Indices and tables 15 Python Module Index 17 Index 19 i ii CHAPTER ONE PORTALOCKER - CROSS-PLATFORM LOCKING LIBRARY 1.1 Overview Portalocker is a library to provide an easy API to file locking. An important detail to note is that on Linux and Unix systems the locks are advisory by default. By specifying the -o mand option to the mount command it is possible to enable mandatory file locking on Linux. This is generally not recommended however. For more information about the subject: • https://en.wikipedia.org/wiki/File_locking
    [Show full text]
  • Real-Time Audio Servers on BSD Unix Derivatives
    Juha Erkkilä Real-Time Audio Servers on BSD Unix Derivatives Master's Thesis in Information Technology June 17, 2005 University of Jyväskylä Department of Mathematical Information Technology Jyväskylä Author: Juha Erkkilä Contact information: [email protected].fi Title: Real-Time Audio Servers on BSD Unix Derivatives Työn nimi: Reaaliaikaiset äänipalvelinsovellukset BSD Unix -johdannaisjärjestelmissä Project: Master's Thesis in Information Technology Page count: 146 Abstract: This paper covers real-time and interprocess communication features of 4.4BSD Unix derived operating systems, and especially their applicability for real- time audio servers. The research ground of bringing real-time properties to tradi- tional Unix operating systems (such as 4.4BSD) is covered. Included are some design ideas used in BSD-variants, such as using multithreaded kernels, and schedulers that can provide real-time guarantees to processes. Factors affecting the design of real- time audio servers are considered, especially the suitability of various interprocess communication facilities as mechanisms to pass audio data between applications. To test these mechanisms on a real operating system, an audio server and a client utilizing these techniques is written and tested on an OpenBSD operating system. The performance of the audio server and OpenBSD is analyzed, with attempts to identify some bottlenecks of real-time operation in the OpenBSD system. Suomenkielinen tiivistelmä: Tämä tutkielma kattaa reaaliaikaisuus- ja prosessien väliset kommunikaatio-ominaisuudet, keskittyen 4.4BSD Unix -johdannaisiin käyt- töjärjestelmiin, ja erityisesti siihen kuinka hyvin nämä soveltuvat reaaliaikaisille äänipalvelinsovelluksille. Tutkimusalueeseen sisältyy reaaliaikaisuusominaisuuk- sien tuominen perinteisiin Unix-käyttöjärjestelmiin (kuten 4.4BSD:hen). Mukana on suunnitteluideoita, joita on käytetty joissakin BSD-varianteissa, kuten säikeis- tetyt kernelit, ja skedulerit, jotka voivat tarjota reaaliaikaisuustakeita prosesseille.
    [Show full text]
  • Design and Implementation of XNU Port of Lustre Client File System
    Design and Implementation of XNU port of Lustre Client File System Danilov Nikita 2005.02.01 Abstract Describes structure of Lustre client file system module for XNU (Darwin kernel). In particular, changes that were necessary in core XNU kernel to enable unique Lustre requirements (e.g., intents) are discussed in much detail. Changes to the platform-independent core of Lustre in order to make it more portable are discussed in the companion paper Lustre Universal Portability Specification. Contents 1 Introduction 2 2 Distribution 3 3 Backgroundon XNU 3 3.1 XNUVFS.......................................... ......... 3 3.1.1 namei()....................................... ......... 4 3.1.2 vnodelifecycle ................................ ........... 6 3.2 XNUpagecache.................................... ........... 6 3.3 XNUSynchronization .............................. ............. 7 3.4 Miscellania..................................... ............. 9 4 High Level Design 9 4.1 XLLIntentHandling ............................... ............. 9 4.1.1 Requirements .................................. .......... 9 4.1.2 FunctionalSpecification . .............. 10 4.1.3 UseCases ...................................... ........ 10 4.1.4 LogicalSpecification . ............. 11 4.1.5 StateSpecification ......................... .... ............ 12 4.2 Sessions........................................ ............ 12 4.2.1 Requirements .................................. .......... 12 4.2.2 FunctionalSpecification . .............. 12 4.2.3 UseCases .....................................
    [Show full text]
  • Lock Or No-Lock?
    Lock Or No-Lock? Abstract guaranteeing atomicity are necessary when these oper- ations must be atomic. Many scientific applications require high perfor- With the advent of parallel I/O libraries data can be mance concurrent IO accesses to a file by multiple pro- accessed in various complex patterns. Locking mecha- cesses. Those applications rely indirectly on atomic IO nisms are used to ensure that shared data is not being capabilities inorder to perform updates to structured violated. Adapted from the POSIX semantics, parallel datasets, such as those stored in HDF5 format files. file system like GPFS [9] and Lustre [10] provide byte Current support for atomic mode operations such as range locking mechanism. Byte range locks provide these in MPI-IO is performed by locking around the an option for guaranteeing atomicity of non-contiguous operations, imposing lock overhead in all situations, operations. By locking the entire region, changes can even though in many cases these operations are non- be made using a read-modify-write sequence. How- overlapping in the file. We propose to isolate non- ever, this approach does not consider the actual non- overlapping accesses from overlapping ones in collec- contiguous access pattern that may occur in a byte tive I/O cases, allowing the non-overlapping ones to range and introduces false sharing. This approach also proceed without imposing lock overhead. To enable this limits the benefits of parallel I/O that can be gained, we have implemented an efficient conflict detection al- by unnecessarily serializing the accesses. To address gorithm in MPI-IO using MPI file views and datatypes.
    [Show full text]
  • With the Spiagent File Locking Add-On Evaluator's Guide
    with the SPIAgent File Locking Add-On Evaluator’s Guide ©2010 Software Pursuits, Inc. Table of Contents Introduction ....................................................................................................................... 2 System Requirements ....................................................................................................... 2 Contact Information ........................................................................................................... 3 Required Add-Ons for SPIAgent File Locking ................................................................... 3 SPIAgent Add-On .......................................................................................................... 3 SPIAgent File Locking Add-On ..................................................................................... 4 Other SureSync Add-Ons ................................................................................................. 4 ArchiveSync Add-On ..................................................................................................... 4 What is SPIAgent File Locking? ........................................................................................ 4 Supported Applications ..................................................................................................... 6 Expected Application Behavior when Encountering Locks ............................................... 7 Our Scenario ..................................................................................................................
    [Show full text]
  • Mac OS X Server File Services Administration for Version 10.4 Or Later
    Mac OS X Server File Services Administration For Version 10.4 or Later K Apple Computer, Inc. © 2005 Apple Computer, Inc. All rights reserved. The owner or authorized user of a valid copy of Mac OS X Server software may reproduce this publication for the purpose of learning to use such software. No part of this publication may be reproduced or transmitted for commercial purposes, such as selling copies of this publication or for providing paid-for support services. Every effort has been made to ensure that the information in this manual is accurate. Apple Computer, Inc., is not responsible for printing or clerical errors. Apple 1 Infinite Loop Cupertino CA 95014-2084 www.apple.com The Apple logo is a trademark of Apple Computer, Inc., registered in the U.S. and other countries. Use of the “keyboard” Apple logo (Option-Shift-K) for commercial purposes without the prior written consent of Apple may constitute trademark infringement and unfair competition in violation of federal and state laws. Apple, the Apple logo, AppleShare, AppleTalk, Mac, Macintosh, QuickTime, Xgrid, and Xserve are trademarks of Apple Computer, Inc., registered in the U.S. and other countries. Finder is a trademark of Apple Computer, Inc. Adobe and PostScript are trademarks of Adobe Systems Incorporated. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company, Ltd. Other company and product names mentioned herein are trademarks of their respective companies. Mention of third-party products is for informational purposes only and constitutes neither an endorsement nor a recommendation.
    [Show full text]
  • Securing Mac OS X - Presentation Slides
    Securing Mac OS X - Presentation Slides Securing Mac OS X Paul Day, pd(at)csse.uwa.edu.au “Keep others out - With Mac OS X, you may never need to worry about security again.” Top 10 reasons to upgrade Apple web-site 1 Securing Mac OS X - Presentation Slides Introduction Background • Mac OS X made a major transition from Classic to X. – Introduced Unix in the form of FreeBSD, NeXT and the Mach/Darwin Kernel • One of the more secure Unix installations by default, but still plenty of drawbacks. 2 Securing Mac OS X - Presentation Slides Overview Aims of this talk: • Discuss methods of hardening OS X from a: – Local user perspective – Network perspective • Point out vulnerabilities in recommendations and existing technologies. Similar work - why bother? • Tried not to let paranoia result in recommendations with little/no benefit but large inconvenience. • Included recommendations, and discussed vulnerabilities others have over-looked. • Simplified and reduced background and semi-relevant information. 3 Securing Mac OS X - Presentation Slides Local Security Local security? Methods to harden security within Mac OS X from a local user perspective: – With local physical access to the machine via its console, OR – With interactive local access to the machine via methods such as Secure Shell (SSH) or Apple Remote Desktop (ARD). 4 Securing Mac OS X - Presentation Slides Login Window • Enable it • Disable auto-login • Insert login window message • Change your password Login Window Enable it and disable auto-login •Uncheck “Automatically log in as:”
    [Show full text]