swift 05/06/28 11:42:44 Added: xml/htdocs/doc/en/draft pax-utils.xml Log: Placing pax utils doc in draft
Revision Changes Path 1.1 xml/htdocs/doc/en/draft/pax-utils.xml file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/pax-utils.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/pax-utils.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo Index: pax-utils.xml =================================================================== <?xml version='1.0' encoding="UTF-8"?> <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/pax-utils.xml,v 1.1 2005/06/28 11:42:43 swift Exp $ --> <!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> <guide link="/doc/en/handbook/draft/pax-utils.xml"> <title>Gentoo PaX Utilities</title> <author title="Author"> <mail link="[EMAIL PROTECTED]">Sven Vermeulen</mail> </author> <author title="Editor"> <mail link="[EMAIL PROTECTED]">Ned Ludd</mail> </author> <abstract> </abstract> <!-- The content of this document is licensed under the CC-BY-SA license --> <!-- See http://creativecommons.org/licenses/by-sa/2.0 --> <license/> <version>0.1</version> <date>2005-01-01</date> <chapter> <title>What is this guide about?</title> <section> <title>Introduction</title> <body> <p> The security of a system goes beyond setting up a decent firewall and good service configurations. The binaries you run, the libraries you load, might also be vulnerable against attacks. Although the exact vulnerabilities are not known until they are discovered, there are ways to prevent them from happening. </p> <p> One possible attack vector is to make advantage of writable <e>and</e> executable segments in a program or library, allowing malicious users to run their own code using the vulnerable application or library. </p> <p> This guide will inform you how to use the <c>pax-utils</c> package to find and identify problematic binaries. We will also cover the use of <c>pspax</c> (a tool to view PaX-specific capabilities) and <c>dumpelf</c> (a tool that prints out a C structure containing a workable copy of a given object). </p> <p> But before we start with that, some information on <e>objects</e> is in place. Users familiar with segments and dynamic linking will not learn anything from this and can immediately continue with <uri link="#scanelf">Extracting ELF Information from Binaries</uri>. </p> </body> </section> <section> <title>ELF objects</title> <body> <p> Every executable binary on your system is structured in a specific way, allowing the Linux kernel to load and execute the file. Actually, this goes beyond plain executable binaries: this also holds for shared objects; more about those later. </p> <p> The structure of such a binary is defined in the ELF standard. ELF stands for <e>Executable and Linkable Format</e>. If you are really interested in the gory details, check out the <uri link="http://www.linuxbase.org/spec/book/ELF-generic/ELF-generic.html";> Generic ELF spec</uri> or the <c>elf(5)</c> man page. </p> <p> An executable ELF file has the following parts: </p> <ul> <li> The <e>ELF header</e> contains information on the <e>type</e> of file (is it an executable, a shared library, ...), the target architecture, the location of the Program Header, Section Header and String Header in the file and the location of the first executable instruction </li> <li> The <e>Program Header</e> informs the system how to create a process from the binary file. It is actually a table consisting of entries for each segment in the program. Each entry contains the type, addresses (physical and virtual), size, access rights, ... </li> <li> The <e>Section Header</e> is a table consisting of entries for each section in the program. Each entry contains the name, type, size, ... and <e>what</e> information the section holds. </li> <li> Data, containing the sections and segments mentioned previously. </li> </ul> <p> A <e>section</e> is a small unit consisting of specific data: instructions, variable data, symbol table, relocation information, and so on. A <e>segment</e> is a collection of sections; segments are the units that are actually transferred to memory. </p> </body> </section> <section> <title>Shared Objects</title> <body> <p> Way back when, every application binary contained <e>everything</e> it needed to operate correctly. Such binaries are called <e>statically linked</e> binaries. They are, however, space consuming since different applications use the same functions over and over again. </p> <p> A <e>shared object</e> contains the definition and instructions for such functions. Every application that wants can <e>dynamically</e> link against such a shared object so that it can benefit from the already existing functionality. </p> <p> An application that is dynamically linked to a shared object contains <e>symbols</e>, references for the real functionality. When such an application is loaded in memory, it will first ask the runtime linker to resolve each and every symbol it has. The runtime linker will load the appropriate shared objects in memory and resolve the symbolic references between them. </p> </body> </section> <section> <title>Segments and Sections</title> <body> <p> How the ELF file is looked upon depends on the view we have: when we are dealing with a binary file in Execution View, the ELF file contains segments. When the file is seen in Linking View, the ELF file contains sections. One segment spans just one or more (continuous) sections. </p> </body> </section> </chapter> <chapter id="scanelf"> <title>Extracting ELF Information from Binaries</title> <section> <title>The scanelf Application</title> <body> <p> The <c>scanelf</c> application is part of the <c>app-misc/pax-utils</c> package. With this application you can print out information specific to the ELF structure of a binary. The following table sums up the various options. </p> <table> <tr> <th>Option</th> <th>Long Option</th> <th>Description</th> </tr> <tr> <ti>-p</ti> <ti>--path</ti> <ti>Scan all directories in the PATH environment</ti> </tr> <tr> <ti>-l</ti> <ti>--ldpath</ti> <ti>Scan all directories mentioned in <path>/etc/ld.so.conf</path></ti> </tr> <tr> <ti>-R</ti> <ti>--recursive</ti> <ti>Scan directories recursively</ti> </tr> <tr> <ti>-m</ti> <ti>--mount</ti> <ti>Stay within the same mount (do not jump to other file systems)</ti> </tr> <tr> <ti>-y</ti> -- [email protected] mailing list
