<!-- LEFT NAV SEARCH END -->

		</td>
		
<!-- PUB PARTNERS END -->
<!-- END LEFT NAV -->

<td rowspan="8" align="right" valign="top"><img src="/images/iswbls.gif" width=1 height=400 alt="" border="0"></td>
<td><img src="/images/white.gif" width="5" height="1" alt="" border="0"></td>
<!-- end of ITK left NAV -->

<!-- begin main content -->
<td width="100%" valign="top" align="left">


<!-- END SUB HEADER -->

<!--Begin Content Column -->

<FONT FACE="Arial,Helvetica" SIZE="-1">
To access the contents, click the chapter and section titles.
</FONT>
<P>
<B>Intrusion Detection: Network Security beyond the Firewall</B>
<FONT SIZE="-1">
<BR>
<I>(Publisher: John Wiley & Sons, Inc.)</I>
<BR>
Author(s): Terry Escamilla
<BR>
ISBN: 0471290009
<BR>
Publication Date: 11/01/98
</FONT>
<P>
<form name="Search" method="GET" action="http://search.earthweb.com/search97/search_redir.cgi">

<INPUT TYPE="hidden" NAME="Action" VALUE="Search">
<INPUT TYPE="hidden" NAME="SearchPage" VALUE="http://search.earthweb.com/search97/samples/forms/srchdemo.htm">
<INPUT TYPE="hidden" NAME="Collection" VALUE="ITK">
<INPUT TYPE="hidden" NAME="ResultTemplate" VALUE="itk-full.hts">
<INPUT TYPE="hidden" NAME="ViewTemplate" VALUE="view.hts">

<font face="arial, helvetica" size=2><b>Search this book:</b></font><br>
<INPUT NAME="queryText" size=50 VALUE="">&nbsp;<input type="submit" name="submitbutton" value="Go!">
<INPUT type=hidden NAME="section_on" VALUE="on">
<INPUT type=hidden NAME="section" VALUE="http://www.itknowledge.com/reference/standard/0471290009/">

</form>


<!-- Empty Reference Subhead -->

<!--ISBN=0471290009//-->
<!--TITLE=Intrusion Detection: Network Security Beyond the Firewall//-->
<!--AUTHOR=Terry Escamilla//-->
<!--PUBLISHER=John Wiley & Sons, Inc.//-->
<!--IMPRINT=Wiley Computer Publishing//-->
<!--CHAPTER=3//-->
<!--PAGES=088-092//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//-->

<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="086-088.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="092-093.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
<P><BR></P>
<P>IDs associated with a process can change during the course of program execution. The importance of this capability in UNIX and similar security models cannot be overemphasized. The ability to increase your security privileges by changing your EUID, EGID, RUID, or RGID is one of the basic notions in the UNIX security model. This privilege escalation mechanism is at the root (pun intended) of many UNIX hacks. The chief goal of most hacking attempts is to gain root privileges to exercise total control over the system. If you do not know or cannot guess the root password, the quickest path to becoming root is to log in as another user and find a way to change one of the UIDs to zero&#151;the UID of the root user. Related hacks involve changing one of the IDs to <I>any</I> user or group on the system other than the current user. Even incrementally increasing your privileges to those of nonroot users might lead to eventually compromising the root account.</P>
<P>You can change <I>who</I> a UNIX system thinks you are in two ways:</P>
<DL>
<DD><B>&#149;</B>&nbsp;&nbsp;You can explicitly change the IDs associated with a process by invoking library or kernel routines.
<DD><B>&#149;</B>&nbsp;&nbsp;You also can let the system automatically change your identity based on access permissions that are set for program files on the system.
</DL>
<P>This latter technique is the one you will explore first as you investigate access control rules for UNIX files and directories.
</P>
<H4 ALIGN="LEFT"><A NAME="Heading10"></A><FONT COLOR="#000077">UNIX File and Directory Permissions</FONT></H4>
<P>The UNIX operating system provides a hierarchical virtual file system that might consist of multiple physical storage devices. Each entry in the file system represents a file or directory. The file abstraction is used in the normal sense as a container for data, but in UNIX, the file abstraction also encompasses other concepts such as sockets, character and block devices, and even system memory. Many major UNIX entities are implemented in the file system in one way or another.
</P>
<P>The basic storage identifier is an <I>inode</I> that contains information about a file-system object. Each inode is associated with an owner UID and GID. These values are assigned when the file is created but can be changed later using the chown or chgrp command or with a corresponding library routine if invoked from a program. An inode can have only a single owner and a single group ID associated with it.</P>
<P>Traditional UNIX systems support DAC through the use of permission bits. Stored with each inode is a 16-bit mode word that controls access to the files represented by the inode. The least significant nine bits are the most important. Access control in UNIX can be specified for either the file&#146;s owner, the file&#146;s group, or all others. The three primary access modes are <I>read</I> (R), <I>write</I> (W), and <I>execute</I> (X). The interpretation for these modes varies for files and directories as shown in Table 3.1.</P>
<TABLE WIDTH="100%"><CAPTION ALIGN=LEFT><B>Table 3.1</B> Standard UNIX File Permissions
<TR>
<TH COLSPAN="3"><HR>
<TR>
<TH WIDTH="20%" ALIGN=LEFT VALIGN="BOTTOM">Permission
<TH WIDTH="30%" ALIGN=LEFT>Allowed Action If Object Is a File
<TH WIDTH="50%" ALIGN=LEFT VALIGN="BOTTOM">Allowed Action If Object Is a Directory
<TR>
<TH COLSPAN="3"><HR>
<TR>
<TD>R (read)
<TD>Read contents of file
<TD>List contents of the directory
<TR>
<TD>X (execute)
<TD>Execute file as a program
<TD>Search the directory
<TR>
<TD>W (write)
<TD>Change file contents
<TD>Add, rename, create files and subdirectories
<TR>
<TH COLSPAN="3"><HR>
</TABLE>
<P>Notice that these interpretations lead to some interesting conditions. If you have execute permission for a directory but not read permission, you can run programs but only if you know the name of the program. You cannot search the directory or list its contents to find the name of the program. In addition, if the file or program you want to access is nested deep within several subdirectories, you must have execute permissions to traverse the directory path.
</P>
<P>The ls command displays the permission bit settings for a file or directory. Additional arguments for ls cause it to reveal other inode attributes including file create date, last access time, and last change of any value in the inode (such as the file&#146;s length). See Figure 3.1 for an example of a directory listing.</P>
<P><A NAME="Fig1"></A><A HREF="javascript:displayWindow('images/03-01.jpg',500,110 )"><IMG SRC="images/03-01t.jpg"></A>
<BR><A HREF="javascript:displayWindow('images/03-01.jpg',500,110)"><FONT COLOR="#000077"><B>Figure 3.1</B></FONT></A>&nbsp;&nbsp;Sample UNIX directory listing.</P>
<P>In this example, the file entry for the file gunzip divulges important security information, such as the following:
</P>
<DL>
<DD><B>&#149;</B>&nbsp;&nbsp;The user who owns the file, the one whose name is &#147;bin.&#148;
<DD><B>&#149;</B>&nbsp;&nbsp;The group owner of the file is also group &#147;bin&#148; (although it could have been a different group).
<DD><B>&#149;</B>&nbsp;&nbsp;The file is composed of 110 512K blocks.
<DD><B>&#149;</B>&nbsp;&nbsp;The last modification time of the file was Mar 09 at 17:28.
<DD><B>&#149;</B>&nbsp;&nbsp;The file&#146;s inode has a <I>link count</I> of 1, meaning that no other files on the system reference this inode (such as through a hard link).
<DD><B>&#149;</B>&nbsp;&nbsp;The permissions are read, write, and execute for the owner; read and write for anyone in group bin; and only execute for any other user.
</DL>
<P>Another value that can be set in the inode&#146;s 16-bit mode field is the <I>sticky bit</I>. The original design of UNIX required that some directories be writeable by all users on the system. In general, this feature is not desirable in a software product. Nonetheless, the /tmp directory has always been writeable by anyone. To prevent users from deleting files that they do not own, the directory&#146;s sticky bit can be set. A command for setting the typical permissions for the /tmp directory would be as follows:</P>
<!-- CODE SNIP //-->
<PRE>
chmod 7777 /tmp
</PRE>
<!-- END CODE SNIP //-->
<P>The first 7 sets the sticky bit and the remaining 7s respectively enabled read, write, and execute permissions for owner, group, and world (or user, group, and other). World-writeable directories are not recommended. If you must use them, at least set the sticky bit to prevent the malicious deleting of files.
</P>
<P>Other mode bits that can be set include the set user ID and set group ID bits, SUID and SGID respectively. When a file&#146;s SUID bit is enabled, program execution can result in increased privileges for the requesting user. Recall that as a normal user on the system, you do not have sufficient privileges to perform all tasks on a system. For example, normal users are not allowed to write a new password directly into the shadow password file. Instead, to change your password, you must execute a privileged program that changes the password on your behalf. Hopefully, the program is well behaved. If not, the flaw can be exploited by you or any interested hacker.</P><P><BR></P>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="086-088.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="092-093.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>


<!-- all of the reference materials (books) have the footer and subfoot reveresed -->
<!-- reference_subfoot = footer -->
<!-- reference_footer = subfoot -->

<!-- BEGIN SUB FOOTER -->
		<br><br>
		</TD>
    </TR>
	</TABLE>

		
	<table width="640" border=0 cellpadding=0 cellspacing=0>
		<tr>
		<td align="left" width=135><img src="/images/white.gif" width=100 height="1" alt="" border="0"></td>
		
		
<!-- END SUB FOOTER -->

<!-- all of the books have the footer and subfoot reveresed -->
<!-- reference_subfoot = footer -->
<!-- reference_footer = subfoot -->

<!-- FOOTER -->
			
		<td width="515" align="left" bgcolor="#FFFFFF">
<font face="arial, helvetica" size="1"><b><a href="/products.html"><font color="#006666">Products</font></a>&nbsp;|&nbsp; <a href="/contactus.html"><font color="#006666">Contact Us</font></a>&nbsp;|&nbsp; <a href="/aboutus.html"><font color="#006666">About Us</font></a>&nbsp;|&nbsp; <a href="http://www.earthweb.com/corporate/privacy.html" target="_blank"><font color="#006666">Privacy</font></a> &nbsp;|&nbsp; <a href="http://www.itmarketer.com/" target="_blank"><font color="#006666">Ad Info</font></a> &nbsp;|&nbsp; <a href="/"><font color="#006666">Home</font></a></b>
		<br><br>
		
		Use of this site is subject to certain <a href="/agreement.html">Terms &amp; Conditions</a>, <a href="/copyright.html">Copyright &copy; 1996-1999 EarthWeb Inc.</a><br> 
All rights reserved.  Reproduction whole or in part in any form or medium without express written permision of EarthWeb is prohibited.</font><p>
</td>
		</tr>
</table>
</BODY>
</HTML>

<!-- END FOOTER -->