Open Source Licenses for Cisco Modeling Labs, Release 1.0.1

Total Page:16

File Type:pdf, Size:1020Kb

Open Source Licenses for Cisco Modeling Labs, Release 1.0.1 Open Source Used in Cisco Modeling Labs 1.0.1 Cisco Systems, Inc. www.cisco.com Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco website at www.cisco.com/go/offices. OL-32808-01 OL-32808-01 Ubuntu 12.04.3 LTS The operating system that Cisco Modeling Labs 1.0.1 runs on is the Ubuntu 12.04.3 LTS Operating System, which is separate from Cisco Modeling Labs 1.0.1. Ubuntu is a registered trademark of Canonical Ltd. For your convenience, we have made the Ubuntu 12.04.3 LTS Operating System available for download at http://www.cisco.com/web/learning/le31/le46/cln/cml/ubuntults.html, if you would like access to the source code and/or would like to review the licenses. The file is approximately 8.1 GB. Therefore, we recommend that you use a download manager to assist you in obtaining the file. Open Source Used in Cisco Modeling Labs 1.0.1 Cisco Systems, Inc. www.cisco.com Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco website at www.cisco.com/go/offices. OL-32808-01 Ubuntu 14.04 LTS Users can create a virtual Linux server image, to be used for purposes such as jump hosts, traffic generation, and scripting. The Ubuntu 14.04 LTS Operating system source code is available at: http://www.cisco.com/web/learning/le31/le46/cln/cml/ubuntults.html Ubuntu is a registered trademark of Canonical Ltd. Open Source Used In Cisco Modeling Labs 1.0.1 Cisco Systems, Inc. www.cisco.com Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco website at www.cisco.com/go/offices. Text Part Number: 78EE117C99-54081098 Open Source Used In Cisco Modeling Labs 1.0.1 1 This document contains licenses and notices for open source software used in this product. With respect to the free/open source software listed in this document, if you have any questions or wish to receive a copy of any source code to which you may be entitled under the applicable free/open source license(s) (such as the GNU Lesser/General Public License), please contact us at [email protected]. In your requests please include the following reference number 78EE117C99-54081098 Contents 1.1 autonetkit 0.8 1.1.1 Available under license 1.2 configobj 4.7.1 :2010/02/07 1.2.1 Available under license 1.3 lxml 3.1.0 1.3.1 Available under license 1.4 mako 0.8.0 1.4.1 Available under license 1.5 markupsafe 0.9.3 1.5.1 Available under license 1.6 netaddr python library 0.7.10 :4.8.0 1.6.1 Available under license 1.7 networkx 1.7 1.7.1 Available under license 1.8 PyYAML 3.10 :3.el6 1.8.1 Available under license 1.9 tornado 3.0.1 1.9.1 Available under license 1.1 autonetkit 0.8 1.1.1 Available under license : Copyright (c) 2012, University of Adelaide All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright Open Source Used In Cisco Modeling Labs 1.0.1 2 notice, this list of conditions and the following disclaimer. * Redistributions in binary form 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. * Neither the name of the University of Adelaide nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1.2 configobj 4.7.1 :2010/02/07 1.2.1 Available under license : This package was debianized by Gustavo Noronha Silva <[email protected]> on Sun, 07 May 2006 22:54:10 -0300. It was downloaded from http://www.voidspace.org.uk/python/configobj.html Copyright: Copyright (C) 2005-2010 Michael Foord, Mark Andrews, Nicola Larosa License: Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form 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. * Neither the name of Michael Foord nor the name of Voidspace may be used to endorse or promote products derived from this Open Source Used In Cisco Modeling Labs 1.0.1 3 software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. # configobj.py # A config file reader/writer that supports nested sections in config files. # Copyright (C) 2005-2010 Michael Foord, Nicola Larosa # E-mail: fuzzyman AT voidspace DOT org DOT uk # nico AT tekNico DOT net # ConfigObj 4 # http://www.voidspace.org.uk/python/configobj.html # Released subject to the BSD License # Please see http://www.voidspace.org.uk/python/license.shtml # Scripts maintained at http://www.voidspace.org.uk/python/index.shtml # For information about bugfixes, updates and support, please join the # ConfigObj mailing list: # http://lists.sourceforge.net/lists/listinfo/configobj-develop # Comments, suggestions and bug reports welcome. 1.3 lxml 3.1.0 1.3.1 Available under license : GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free Open Source Used In Cisco Modeling Labs 1.0.1 4 software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary.
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]