DOCSLIB.ORG

Hardening Di Un Sistema Debian GNU/Linux

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Hardening Di Un Sistema Debian GNU/Linux HHararddeneniinngg ddii uunn sisistemstemaa DDebebiianan GGNNUU//LLiinnuuxx Principali passi per la configurazione e copia & incolla (molto) l'ottimizzazione in ottica di sicurezza commentato (poco) di (hardening) di un server basato su “Securing Debian Manual” Debian GNU/Linux per fornire i servizi apt-get install harden-doc più comuni. Verranno analizzate le principali modifiche da apportare rispetto ad un'installazione "by-default", espresse alcune 26 Novembre 2004 considerazioni e valutazioni in ottica di Security Day, Cesena sicurezza, analizzati alcuni strumenti utili per rafforzare le difese e monitorare lo stato 27 Novembre 2004 del sistema. Linux Day, Rimini IgIgoorr FFaalclcoommatàatà -- kokobba@[email protected] Hardening di un sistema Debian GNU/Linux – 26 Novembre 2004, Security Day, Cesena / 27 Novembre 2004, Linux Day, Rimini - [email protected] Tutti i brani citati sono di proprietà dei legittimi autori e soggetti ad eventuali restrizioni. Il resto(?) è liberamente distribuibile secondo la GNU FDL - Pagina 1 HHararddeneniningg FrFromom Wikipedia,Wikipedia, thethe frfreeee encyclopediaencyclopedia “In computing, hardening is the process of securing a system. This work is especially done to protect systems against attackers. This would typically include removal of unnecessary usernames or logins and the disabling or removal of unnecessary services. On a typical Windows server, one example would be the disabling of the "print spooler" as this may not be needed. There are various methods of hardening Unix and Linux systems. This may involve, among other measures, applying a patch to the kernel such as Exec Shield or PaX; closing open network ports; and setting up intrusion-detection systems (such as firewalls) and intrusion-prevention systems. See also: Computer Security, Computer Network Security, Security Policy, Linux: Security Enhanced Linux” Hardening di un sistema Debian GNU/Linux – 26 Novembre 2004, Security Day, Cesena / 27 Novembre 2004, Linux Day, Rimini - [email protected] Tutti i brani citati sono di proprietà dei legittimi autori e soggetti ad eventuali restrizioni. Il resto(?) è liberamente distribuibile secondo la GNU FDL - Pagina 2 DDiisclsclaiaimmerer “P“Pleaselease (d(doonn''t)t) trytry ththisis atat hhoomme”e” ● Alcune o tutte le procedure ed i suggerimenti riportati potrebbero danneggiare irreparabilmente i vostri dati, il vostro sistema, il vostro tostapane ed il vostro conto in banca... ● MAI (ho detto MAI) eseguire operazioni di hardening su un sistema 'in produzione' senza sapere esattamente cosa si sta facendo ● Provate e riprovate i singoli passi su sistemi di prova e cmq procedete per passi graduali ● Tenete traccia di tutte le operazioni che effettuate (“diario di bordo”) in modo da poter tornare facilmente sui vostri passi (man script) ● Alcuni software e procedure (anche relativi al sistema operativo stesso) potrebbero non funzionare correttamente ● Casco ben allacciato in testa e prudenza, sempre! Hardening di un sistema Debian GNU/Linux – 26 Novembre 2004, Security Day, Cesena / 27 Novembre 2004, Linux Day, Rimini - [email protected] Tutti i brani citati sono di proprietà dei legittimi autori e soggetti ad eventuali restrizioni. Il resto(?) è liberamente distribuibile secondo la GNU FDL - Pagina 3 SecuSecurriinngg DDebebiianan ManManuualal rrevev 2.992.99 JavierJavier FerFernández-Snández-Sanguinoanguino PPeñaeña <<jfs@[email protected]>> “This document describes security in the Debian project. Starting with the process of securing and hardening the default Debian GNU/Linux distribution installation. It also covers some of the common tasks to set up a secure network environment using Debian GNU/Linux, gives additional information on the security tools available and talks about how security is enforced in Debian by the security team.” “One of the hardest things about writing security documents is that every case is unique. Two things you have to pay attention to are the threat environment and the security needs of the individual site, host, or network. For instance, the security needs of a home user are completely different from a network in a bank.” “Securing Debian is not very different from securing any other system; in order to do it properly, you must first decide what you intend to do with it. After this, you will have to consider that the following tasks need to be taken care of if you want a really secure system.” http://www.debian.org/doc/manuals/securing-debian-howto/ Hardening di un sistema Debian GNU/Linux – 26 Novembre 2004, Security Day, Cesena / 27 Novembre 2004, Linux Day, Rimini - [email protected] Tutti i brani citati sono di proprietà dei legittimi autori e soggetti ad eventuali restrizioni. Il resto(?) è liberamente distribuibile secondo la GNU FDL - Pagina 4 PerPerchchéé DDebebiianan GGNNUU//LLiinnuux?x? ● “Debian problems are always handled openly, even security related. Security issues are discussed openly on the debian-security mailing list. Debian Security Advisories are sent to public mailing lists (both internal and external) and are published on the public server. As the Debian Social Contract (http://www.debian.org/social_ contract) states: We Won t Hide Problems We will keep our entire bug-report database open for public view at all times. Reports that users file on-line will immediately become visible to others.” ● “Security updates are the first priority. When a security problem arises in a Debian package, the security update is prepared as fast as possible and distributed for our stable and unstable releases, including all architectures.” ● “Information regarding security is centralized in a single point, http://security. debian.org/.” Hardening di un sistema Debian GNU/Linux – 26 Novembre 2004, Security Day, Cesena / 27 Novembre 2004, Linux Day, Rimini - [email protected] Tutti i brani citati sono di proprietà dei legittimi autori e soggetti ad eventuali restrizioni. Il resto(?) è liberamente distribuibile secondo la GNU FDL - Pagina 5 CChhii benben cocommiincincia..a.... ● “Before you install any operating system on your computer, set up a BIOS password. After installation (once you have enabled bootup from the hard disk) you should go back to the BIOS and change the boot sequence to disable booting from floppy, cdrom and other devices that shouldn t boot. Otherwise a cracker only needs physical access and a boot disk to access your entire system.” [più in generale, valutare il “Layer 0” :)] ● “Disabling booting unless a password is supplied is even better. This can be very effective if you run a server, because it is not rebooted very often. The downside to this tactic is that rebooting requires human intervention which can cause problems if the machine is not easily accessible.” [sconsigliabile] ● “Note: many BIOSes have well known default master passwords, and applications also exist to retrieve the passwords from the BIOS. Corollary: don t depend on this measure to secure console access to system.” [avendo accesso fisico al sistema, è possibile 'resettare' la password del BIOS, oppure accedere fisicamente ai dischi] Hardening di un sistema Debian GNU/Linux – 26 Novembre 2004, Security Day, Cesena / 27 Novembre 2004, Linux Day, Rimini - [email protected] Tutti i brani citati sono di proprietà dei legittimi autori e soggetti ad eventuali restrizioni. Il resto(?) è liberamente distribuibile secondo la GNU FDL - Pagina 6 ParPartitizizioonnamamenentoto ddeiei ddiischschii “An intelligent partition scheme depends on how the machine is used. A good rule of thumb is to be fairly liberal with your partitions and to pay attention to the following factors:” ● “Any directory tree which a user has write permissions to, such as e.g. /home, /tmp and / var/tmp/, should be on a separate partition. This reduces the risk of a user DoS by filling up your / mount point and rendering the system unusable (Note: this is not strictly true, since there is always some space reserved for root which a normal user cannot fill) as well as avoiding hardlink attacks” ● “Any partition which can fluctuate, e.g. /var (especially /var/log) should also be on a separate partition. On a Debian system, you should create /var a little bit bigger than on other systems, because downloaded packages (the apt cache) are stored in /var/cache / apt/archives.” Hardening di un sistema Debian GNU/Linux – 26 Novembre 2004, Security Day, Cesena / 27 Novembre 2004, Linux Day, Rimini - [email protected] Tutti i brani citati sono di proprietà dei legittimi autori e soggetti ad eventuali restrizioni. Il resto(?) è liberamente distribuibile secondo la GNU FDL - Pagina 7 ParPartitizizioonnamamenentoto ddeiei ddiischschii ● “Any partition where you want to install non-distribution software should be on a separate partition. According to the File Hierarchy Standard, this is /opt or /usr/local. If these are separate partitions, they will not be erased if you (have to) reinstall Debian itself.” ● “From a security point of view, it makes sense to try to move static data to its own partition, and then mount that partition read-only. Better yet, put the data on read-only media. See below for more details.” “In the case of a mail server it is important to have a separate partition for the mail spool. Remote users (either knowingly or unknowingly) can fill the mail spool (/var/mail and/or / var/spool/mail). If the spool is on a separate partition, this situation will not render the system unusable. Otherwise (if the spool directory is on the same partition as /var) the system might have important problems: log entries will not be created, packages can not be installed, and some programs might even have problems starting up (if they use /var/run).” Hardening di un sistema Debian GNU/Linux – 26 Novembre 2004, Security Day, Cesena / 27 Novembre 2004, Linux Day, Rimini - [email protected] Tutti i brani citati sono di proprietà dei legittimi autori e soggetti ad eventuali restrizioni. Il resto(?) è liberamente distribuibile secondo la GNU FDL - Pagina 8 ScelSceltata ddelel fifillesystemesystem “During the system partitioning you also have to decide which file system you want to use. The default file system selected in the Debian installation for Linux partitions is ext2.
Load more

Recommended publications
  • On Trends in Low-Level Exploitation
    On trends in low-level exploitation Christian W. Otterstad Department of Informatics, University of Bergen Abstract Low-level computer exploitation and its mitigation counterpart has accumulated some noteworthy history. Presently, especially in academia, it features a plethora of mitigation techniques and also various possible modes of attack. It has seen numerous developments building upon basic methods for both sides and certain trends have emerged. This paper is primarily an overview paper, focusing especially on x86 GNU/Linux. The basic reasons inherent for allowing low-level exploitability are identified and explained to provide background knowledge. The paper furthermore describes the history, present state of the art and future developments that are topical and appear to be important in the field. Several attack and defense techniques have overlapping notions with not always obvious differences. Herein the notion of the bar being raised for both exploits and mitigation methods is examined and extrapolated upon based on the known relevant present state and history. The difference between academia and the industry is discussed especially where it relates to application of new mitigation techniques. Based on this examination some patterns and trends are identified and a conjecture for the likely future development of both is presented and justified. This paper was presented at the NIK-2016 conference; see http://www.nik.no/. 1 Introduction and earlier related work In 1972 the paper “Computer Security Technology Planning Study” was published [1]. Since then, research surrounding the main ideas in this paper has grown to become a ma- ture and complex field in its own right. There are many different exploitation techniques and mitigation techniques.
    [Show full text]
  • Detecting Exploit Code Execution in Loadable Kernel Modules
    Detecting Exploit Code Execution in Loadable Kernel Modules HaizhiXu WenliangDu SteveJ.Chapin Systems Assurance Institute Syracuse University 3-114 CST, 111 College Place, Syracuse, NY 13210, USA g fhxu02, wedu, chapin @syr.edu Abstract and pointer checks can lead to kernel-level exploits, which can jeopardize the integrity of the running kernel. Inside the In current extensible monolithic operating systems, load- kernel, exploitcode has the privilegeto interceptsystem ser- able kernel modules (LKM) have unrestricted access to vice routines, to modify interrupt handlers, and to overwrite all portions of kernel memory and I/O space. As a result, kernel data. In such cases, the behavior of the entire sys- kernel-module exploitation can jeopardize the integrity of tem may become suspect. the entire system. In this paper, we analyze the threat that Kernel-level protection is different from user space pro- comes from the implicit trust relationship between the oper- tection. Not every application-level protection mechanism ating system kernel and loadable kernel modules. We then can be applied directly to kernel code, because privileges present a specification-directed access monitoring tool— of the kernel environment is different from that of the user HECK, that detects kernel modules for malicious code ex- space. For example, non-executableuser page [21] and non- ecution. Inside the module, HECK prevents code execution executable user stack [29] use virtual memory mapping sup- on the kernel stack and the data sections; on the bound- port for pages and segments, but inside the kernel, a page ary, HECK restricts the module’s access to only those kernel or segment fault can lead to kernel panic.
    [Show full text]
  • Securing Debian HOWTO
    Securing Debian HOWTO Javier Fernández-Sanguino Peña <[email protected]> v1.92 6 noviembre 2001Tue Oct 23 00:59:57 CEST 2001 Abstract This document describes the process of securing and hardening the default Debian installation. It covers some of the common taks to setup a secure network environment using Debian GNU/Linux. Copyright Notice Copyright c 2001 Alexander Reelsen, Javier Fernández-Sanguino Peña Copyright c 2000 Alexander Reelsen however it is distributed under the terms of the GNU free documentation license. This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY. i Contents 1 Introduction 1 1.1 Download the HOWTO ................................... 1 1.2 Organizational Notes/Feedback ............................... 2 1.3 Prior knowledge ....................................... 2 1.4 Things that need to be written (TODO) ........................... 2 1.5 Changelog .......................................... 4 1.5.1 Version 1.92 .................................... 4 1.5.2 Version 1.91 .................................... 4 1.5.3 Version 1.9 ..................................... 4 1.5.4 Version 1.8 ..................................... 5 1.5.5 Version 1.7 ..................................... 5 1.5.6 Version 1.6 ..................................... 5 1.5.7 Version 1.5 ..................................... 6 1.5.8 Version 1.4 ..................................... 6 1.5.9 Version 1.3 ..................................... 6 1.5.10 Version 1.2 ..................................... 6 1.5.11 Version 1.1 ..................................... 6 1.5.12 Version 1.0 ..................................... 6 1.6 Credits ............................................ 7 2 Before you begin 9 2.1 What do you want this system for? ............................. 9 2.2 Be aware of general security problems ........................... 9 2.3 How does Debian handle security? ............................. 11 CONTENTS ii 3 Before and during the installation 13 3.1 Choose a BIOS password .................................
    [Show full text]
  • Securing Debian Manual
    Securing Debian Manual Javier Fernández-Sanguino Peña <[email protected]> 2.6 10 octubre 2002Wed, 18 Sep 2002 14:09:35 +0200 Abstract This document describes the process of securing and hardening the default Debian installation. It covers some of the common tasks to set up a secure network environment using Debian GNU/Linux. It also gives additional information on the security tools available as well as the work done by the Debian security team. Copyright Notice Copyright © 2002 Javier Fernández-Sanguino Peña Copyright © 2001 Alexander Reelsen, Javier Fernández-Sanguino Peña Copyright © 2000 Alexander Reelsen Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 (http://www.fsf.org/copyleft/fdl. html) or any later version published by the Free Software Foundation. It is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY. i Contents 1 Introduction 1 1.1 Download the manual .................................. 1 1.2 Organizational Notes/Feedback ............................ 2 1.3 Prior knowledge ...................................... 2 1.4 Things that need to be written (FIXME/TODO) .................... 2 1.5 Changelog/History .................................... 5 1.5.1 Version 2.6 (september 2002) .......................... 5 1.5.2 Version 2.5 (september 2002) .......................... 5 1.5.3 Version 2.5 (august 2002) ............................ 5 1.5.4 Version 2.4 ..................................... 9 1.5.5 Version 2.3 ..................................... 9 1.5.6 Version 2.3 ..................................... 9 1.5.7 Version 2.2 ..................................... 10 1.5.8 Version 2.1 ..................................... 10 1.5.9 Version 2.0 ..................................... 10 1.5.10 Version 1.99 ...................................
    [Show full text]
  • Integrity Checking for Process Hardening
    Integrity Checking For Process Hardening by Kyung-suk Lhee B.A. Korea University, 1991 Graduate Diploma, Griffith University, 1993 M.A. Boston University, 1995 DISSERTATION Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer and Information Science in the Graduate School of Syracuse University May 2005 Advisor: Professor Steve J. Chapin Abstract Computer intrusions can occur in various ways. Many of them occur by exploiting program flaws and system configuration errors. Existing solutions that detects specific kinds of flaws are substantially different from each other, so aggregate use of them may be incompatible and require substantial changes in the current system and computing practice. Intrusion detection systems may not be the answer either, because they are inherently inaccurate and susceptible to false positives/negatives. This dissertation presents a taxonomy of security flaws that classifies program vulnerabilities into finite number of error categories, and presents a security mechanism that can produce accurate solutions for many of these error categories in a modular fashion. To be accurate, a solution should closely match the characteristic of the target error category. To ensure this, we focus only on error categories whose characteristics can be defined in terms of a violation of process integrity. The thesis of this work is that the proposed approach produces accurate solutions for many error categories. To prove the accuracy of produced solutions, we define the process integrity checking approach and analyze its properties. To prove that this approach can cover many error categories, we develop a classification of program security flaws and find error characteristics (in terms of a process integrity) from many of these categories.
    [Show full text]
  • Secure Programming for Linux HOWTO Secure Programming for Linux HOWTO
    Secure Programming for Linux HOWTO Secure Programming for Linux HOWTO Table of Contents Secure Programming for Linux HOWTO........................................................................................................1 David A. Wheeler, dwheeler@dwheeler.com.........................................................................................1 1.Introduction...........................................................................................................................................1 2.Background...........................................................................................................................................1 3.Summary of Linux Security Features...................................................................................................1 4.Validate All Input.................................................................................................................................1 5.Avoid Buffer Overflow.........................................................................................................................2 6.Structure Program Internals and Approach...........................................................................................2 7.Carefully Call Out to Other Resources.................................................................................................2 8.Send Information Back Judiciously......................................................................................................2 9.Special Topics.......................................................................................................................................2
    [Show full text]
  • EXPRESSSCOPE Engine 3 User's Guide
    EXPRESSSCOPE Engine 3 User’s Guide Scalable Modular Server DX2000 1. Overview 2. Configuring the Server Module 3. Configuring a Management PC 4. Networking 5. Using Remote Management 6. Troubleshooting 20.102.01-120-02 April, 2016 TRADEMARKS AND PATENTS EXPRESSSCOPE is registered trademarks of NEC Corporation. Microsoft, Windows and Windows Vista, Windows Media Player, Windows Server, Internet Explorer are registered trademarks of Microsoft Corporation in the United States and other countries. Firefox is registered trademarks of the Mozilla Foundation. Java is registered trademarks of Oracle and/or its affiliates. Red Hat is registered trademarks of Red Hat, Inc. in the United States and other countries. Active Directory is registered trademarks of Microsoft Corporation in the United States and other countries. NFS is registered trademarks of Sun Microsystems, Inc. in the United States and other countries. (Sun Microsystems is registered trademarks of Oracle and/or its affiliates) Linux is registered trademarks of Mr. Linus Torvalds in the United States and other countries. UNIX is registered trademarks of The Open Group in the United States and other countries. JavaScript is registered trademarks of Oracle and/or its affiliates. OpenLDAP is registered trademarks of the OpenLDAP Foundation. NOTES (1) No part of this manual may be reproduced in any form without the prior written permission of NEC Corporation. (2) The contents of this User’s Guide may be revised without prior notice. (3) The contents of this User's Guide shall not be copied or altered without the prior written permission of NEC Corporation. (4) All efforts have been made to ensure the accuracy of all information in this User's Guide.
    [Show full text]
  • EXPRESSSCOPE Engine 3 User's Guide
    EXPRESSSCOPE Engine 3 User’s Guide (for ft series) NEC Express Server Express5800 Series 1. Overview 2. Configuring the Server 3. Configuring a Management PC 4. Networking 5. Using Remote Management 6. Command Line Interface 7. WS-Management (Web Service for Management) 8. Troubleshooting 30.103.01-120.01 July, 2017 © NEC Corporation 2011-2017 TRADEMARKS AND PATENTS EXPRESSSCOPE is registered trademarks of NEC Corporation. EXPRESSBUILDER and ESMPRO are registered trademarks of NEC Corporation. Microsoft, Windows and Windows Vista, Windows Media Player, Windows Server, Internet Explorer are registered trademarks of Microsoft Corporation in the United States and other countries. Firefox is registered trademarks of the Mozilla Foundation. Java is registered trademarks of Oracle and/or its affiliates. Red Hat is registered trademarks of Red Hat, Inc. in the United States and other countries. Active Directory is registered trademarks of Microsoft Corporation in the United States and other countries. Linux is registered trademarks of Mr. Linus Torvalds in the United States and other countries. JavaScript is registered trademarks of Oracle and/or its affiliates. OpenLDAP is registered trademarks of the OpenLDAP Foundation. NOTES (1) No part of this manual may be reproduced in any form without the prior written permission of NEC Corporation. (2) The contents of this User’s Guide may be revised without prior notice. (3) The contents of this User's Guide shall not be copied or altered without the prior written permission of NEC Corporation. (4) All efforts have been made to ensure the accuracy of all information in this User's Guide. If you notice any part unclear, incorrect, or omitted in this User's Guide, contact the sales agent where you purchased this product.
    [Show full text]
  • Android™ Hacker's Handbook
    ffi rs.indd 01:50:14:PM 02/28/2014 Page ii Android™ Hacker’s Handbook ffi rs.indd 01:50:14:PM 02/28/2014 Page i ffi rs.indd 01:50:14:PM 02/28/2014 Page ii Android™ Hacker’s Handbook Joshua J. Drake Pau Oliva Fora Zach Lanier Collin Mulliner Stephen A. Ridley Georg Wicherski ffi rs.indd 01:50:14:PM 02/28/2014 Page iii Android™ Hacker’s Handbook Published by John Wiley & Sons, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256 www.wiley.com Copyright © 2014 by John Wiley & Sons, Inc., Indianapolis, Indiana ISBN: 978-1-118-60864-7 ISBN: 978-1-118-60861-6 (ebk) ISBN: 978-1-118-92225-5 (ebk) Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1 No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or autho- rization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions. Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifi cally disclaim all warranties, including without limitation warranties of fi tness for a particular purpose.
    [Show full text]
  • Secure Programming for Linux and Unix HOWTO
    Secure Programming for Linux and Unix HOWTO David A. Wheeler v3.010 Edition Copyright © 1999, 2000, 2001, 2002, 2003 David A. Wheeler v3.010, 3 March 2003 This book provides a set of design and implementation guidelines for writing secure programs for Linux and Unix systems. Such programs include application programs used as viewers of remote data, web applications (including CGI scripts), network servers, and setuid/setgid programs. Specific guidelines for C, C++, Java, Perl, PHP, Python, Tcl, and Ada95 are included. For a current version of the book, see http://www.dwheeler.com/secure−programs This book is Copyright (C) 1999−2003 David A. Wheeler. Permission is granted to copy, distribute and/or modify this book under the terms of the GNU Free Documentation License (GFDL), Version 1.1 or any later version published by the Free Software Foundation; with the invariant sections being ``About the Author'', with no Front−Cover Texts, and no Back−Cover texts. A copy of the license is included in the section entitled "GNU Free Documentation License". This book is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Secure Programming for Linux and Unix HOWTO Table of Contents Chapter 1. Introduction......................................................................................................................................1 Chapter 2. Background......................................................................................................................................4
    [Show full text]
  • Linux Security Modules: General Security Support for the Linux Kernel
    USENIX Association Proceedings of the 11th USENIX Security Symposium San Francisco, California, USA August 5-9, 2002 THE ADVANCED COMPUTING SYSTEMS ASSOCIATION © 2002 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. Linux Security Modules: General Security Support for the Linux Kernel Chris Wright and Crispin Cowan Stephen Smalley WireX Communications, Inc. NAI Labs, Network Associates, Inc. [email protected], [email protected] [email protected] James Morris Greg Kroah-Hartman Intercode Pty Ltd IBM Linux Technology Center [email protected] [email protected] Abstract mented [9, 1, 4, 41, 23, 10, 29, 37], mainstream oper- ating systems typically still lack support for these en- hancements. In part, the absence of such enhancements The access control mechanisms of existing mainstream is due to a lack of agreement within the security com- operating systems are inadequate to provide strong sys- munity on the right general solution. tem security. Enhanced access control mechanisms have failed to win acceptance into mainstream operating sys- Like many other general-purpose operating systems, the tems due in part to a lack of consensus within the se- Linux kernel only provides discretionary access controls curity community on the right solution.
    [Show full text]
  • Proceedings of the 11 USENIX Security Symposium
    USENIX Association Proceedings of the 11th USENIX Security Symposium San Francisco, California, USA August 5-9, 2002 THE ADVANCED COMPUTING SYSTEMS ASSOCIATION © 2002 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. Type-Assisted Dynamic Buffer Overflow Detection Kyung-suk Lhee and Steve J. Chapin Center for Systems Assurance Syracuse University g fklhee, chapin @ecs.syr.edu Abstract tack overflows a buffer to overwrite the return address of a function, so that the return address points to the at- tack code that is injected into the stack by the attacker, Programs written in C are inherently vulnerable to buffer rather than the legitimate call point. The control flow overflow attacks. Functions are frequently passed point- is directed to the attack code when the function returns. ers as parameters without any hint of their sizes. Since The stack smashing attack exploits the stack configura- their sizes are unknown, most run time buffer overflow tion and the function call mechanism. There are other detection techniques instead rely on signatures of known types of buffer overflow attacks that exploit data struc- attacks or loosely estimate the range of the referenced tures in the heap as well as in the stack.
    [Show full text]