diff --git a/LDP/guide/docbook/Linux-Networking/NetROM.xml b/LDP/guide/docbook/Linux-Networking/NetROM.xml deleted file mode 100644 index ee1b61b2..00000000 --- a/LDP/guide/docbook/Linux-Networking/NetROM.xml +++ /dev/null @@ -1,274 +0,0 @@ - - -NetROM - - This document describes how to setup the ax25-utilities package for - Amateur Radio such that it makes Netrom Nodes for the Node program and - the BBS software from John-Paul Roubelat, F6FBB. The DOS G8BPQ Switch - makes a bbs node and many features, it was expected that the Linux - ax25-utils would have a similar capability. This was not the case. - Help came from John Ackerman, N8UR who put a message on the Linux-Ham - SIG that he had done the BBS node and the info was on his web site! - When the information was tried it didn't work properly but much was - learned about the technique. Help from Tomi Manninen, OH2BNS did the - trick. Nodes for the BBS and the Node and the DX Cluster were made and - work fine. - - 1. Introduction - - It is possible, using just the ax25-util's to generate node listings - for the Node application and the FBB BBS and the DXNet DX Cluster. - This is done by changing the configuration files for Netrom and making - a Netrom entry for each application. At present there is a kernel - imposed limit of 4 Netrom entries. The new kernels are expected to - drop this limit. - - Now users look for CRUCES:K5DI-4 and LCBBS:K5DI-3 and LCDX:K5DI-5 on - the many nodes here in New Mexico, Texas and Arizona and are connected - like magic. They no longer need to remember anything. - - 2. How to Begin - - Obtain and read the AX25-HOWTO: - - ftp:/sunsite.unc.edu/pub/Linux/docs/HOWTO/AX25-HOWTO/ - - Using the AX25-HOWTO set up the normal Amateur Radio ax.25 and Netrom - system and make certain it is operating properly. When the software - "CALL" can be used to make either a ax25 or Netrom connection to a - distant node, the system is ready to change to one using node listings - like the BPQ Switch. - - 3. Some Details of the AX.25 Utilities - - Below is a list of all the applications and files that are needed to - set up a working ax.25 system. The Applications are all in the - /usr/sbin/ directory and the Configuration files are in the /etc/ax25/ - directory. Note: Kissattach is used only if you have TNC's in the Kiss - Mode. - - · kissattach Application - · call Application - · ax25d Application - · ax25d.conf Configuration file - · axspawn Application - · axspawn.conf Configuration file - · axports Configuration file - - There are several names that a ax25-util user must invent. Since this - paper uses the files of k5di, a listing of those names can be made. - - Name Call-sign Alias Other - - ax0 k5di-9 ax25 9600 baud - ax1 k5di-10 ax25 1200 baud - Netrom k5di-1 #CRUCE Real Netrom - netnod k5di-4 CRUCES Node node-list - netbbs k5di-3 LCBBS BBS node-list - netdx k5di-5 LCDX DX-Cluster - - It's a good idea to make a list like this on paper before you start to - change things. It is easy to put the wrong name in a control file. - - Kissattach is an application that connects the kernel to the TNC, sets - the tcp/ip address up, sets the speed of the connection, and is given - the serial port to use. - - Axports is a file that defines the name of the ax.25 ports and tells - kissattach what call-sign, baud-rate and window size to use. Below is - an example of a 2 TNC system. - - # /etc/ax25/axports - # Be very careful with the speed setting. This is the speed in - # bits/second that data passes from the computer to the TNC, and has - # nothing to do with the radio baud rate! - # - # The format of this file is: - # - # name call-sign speed paclen window description - # - ax0 K5DI-9 9600 255 3 445.1 (9600 bps) - ax1 K5DI-10 9600 255 1 145.07 (1200 bps) - - AX25D is the application that reads the ax25d.conf Configuration file - and answers calls made to the system. Below is a sample ax25d.conf - that has no Netrom defined. In fact all it will do is answer calls to - k5di-9 and k5di-10. When it answers it starts the node application and - logs the caller in. - - # /etc/ax25/ax25d.conf - # - # AX25D Configuration File. - # - # AX.25 ports begin with a '['. - # - [k5di-4 VIA ax0] - default * * * * * 0 - root /usr/sbin/node node - [k5di-4 VIA ax1] - default * * * * * 0 - root /usr/sbin/node node - # - - The next step is to get ax25d to answer a call to the alias CRUCES as - well as the call-sign. This is easy to do and is shown below: - - # /etc/ax25/ax25d.conf - # - # AX25D Configuration File. - # - # AX.25 ports begin with a '['. - # - [CRUCES VIA ax0] - default * * * * * 0 - root /usr/sbin/node node - [k5di-4 VIA ax0] - default * * * * * 0 - root /usr/sbin/node node - [CRUCES VIA ax1] - default * * * * * 0 - root /usr/sbin/node node - [k5di-4 VIA ax1] - default * * * * * 0 - root /usr/sbin/node node - # - - If you have trouble, as root kill ax25d if it is running and then at - the prompt type ax25d &. As ax25d loads the ax25d.conf file it will - print out any errors it finds. This print out is very accurate and - tells you which row in the file is wrong. - - A connect from any adjacent node to k5di-4 or CRUCES will connect to - the k5di node. But Netrom is not transmitting a node listing for - CRUCES or k5di-4. This is done by changing some Netrom Configuration - files. - - 4. Setting Up Netrom - - Netrom has applications and files that control it's function and to - achieve the G8BPQ look and function we must use these in ways never - intended. Below is a list of these components of Netrom: - - - · nrattach Application - · netromd Application - · nrports Configuration File - · nrbroadcast Configuration File - - Nrattach is the application that works with the kernel and - establishes the ports and tcp-ip used by Netrom. To use nrattach - you place it in your startup file and the example looks like this: - - /usr/sbin/nrattach -i 44.30.2.5 netrom - /usr/sbin/nrattach -i 44.30.2.5 netnod - - Nrattach gets some of it's information from a configuration file - called nrports. This file is shown below: - - # /etc/ax25/nrports - # - # The format of this file is: - # - # name call-sign alias paclen description - # - netrom K5DI-1 #CRUCE 235 Switch - netnod K5DI-4 CRUCES 235 Real Node - - There is no change to the nrbroadcast file so the remaining changes - will be made to the ax25d.conf file. In this file you normally put the - real netrom application called k5di-1, but since a call to k5di-1 or - #CRUCE gets undesirable results, leave that entry out of ax25d.conf - and a user will get just a "busy" when calling. - - Instead put in the netnod and that will allow ax25d to answer a call - to CRUCES. This is shown in the example below: - - # /etc/ax25/ax25d.conf - # - # AX25D Configuration File. - # - # AX.25 ports begin with a '['. - # - [CRUCES VIA ax0] - default * * * * * 0 - root /usr/sbin/node node - [k5di-4 VIA ax0] - default * * * * * 0 - root /usr/sbin/node node - [CRUCES VIA ax1] - default * * * * * 0 - root /usr/sbin/node node - [k5di-4 VIA ax1] - default * * * * * 0 - root /usr/sbin/node node - # - # NET/ROM ports begin with a '<'. - # - - default * * * * * * - root /usr/sbin/node node - # - - With these changes netrom node broadcasts will include the node - K5DI-4:CRUCES and K5DI-1:#CRUCE. By testing it was determined that a - call from any node to k5di-1 or #CRUCE got a busy, and a call to - k5di-4 or CRUCES connected to the node on this system. - - 5. Setting Up FBB and DXNet: - - The FBB packet BBS and DXNet Linux software are written to answer - calls to a call-sign defined in the configuration files. In these - examples the FBB call-sign is k5di-3 and the DXNet is k5di-5. - - Since calls to k5di-3 and k5di-5 are answered by other software, ax25d - is not used and these calls should NEVER be found in a ax25d.conf - file. But the nrports file needs to have the information added and 2 - more nrattach lines are added to the start file. The nrattach lines (4 - each) and the file "nrports" are shown below: - - /usr/sbin/nrattach -i 44.30.2.5 netrom - /usr/sbin/nrattach -i 44.30.2.5 netbbs - /usr/sbin/nrattach -i 44.30.2.5 netnod - /usr/sbin/nrattach -i 44.30.2.5 netdx - - # /etc/ax25/nrports - # - # The format of this file is: - # - # name call-sign alias paclen description - # - netrom K5DI-1 #CRUCE 235 Switch - netnod K5DI-4 CRUCES 235 Real Node - netbbs K5DI-3 LCBBS 235 FBB BBS - netdx K5DI-5 LCDX 235 DXNet DX Cluster - - These changes will make the node listings wanted but a call to LCBBS - will not work yet. Recall that FBB answers a call to k5di-3 but not - the alias. To achieve this a change to the - /usr/local/fbb/system/port.sys file is required. Before these changes - port.sys had a listing for the name "netrom". With these changes - replace "netrom" with "netbbs". That section of port.sys is shown - below: - - #TNC NbCh Com MultCh Pacln Maxfr NbFwd MxBloc M/P-Fwd Mode Freq - 0 0 0 0 0 0 0 0 00/01 ---- File-fwd. - 1 8 1 ax0 250 4 1 10 30/60 XUWY UHF port - 2 2 1 ax1 250 4 1 10 00/60 XUWY VHF port - 3 6 1 netbbs 250 4 4 10 30/60 XUWY BPQ look - 4 8 2 0 250 5 4 1000 5/15 TUWY Telnet - # - - A similar change is made to the "dxnet.cfg" file where netrom is - replaced with netdx. When these changes are made and a few hours have - passed to let Netrom send node lists, any nearby node will have nodes - listed to your Netrom for CRUCES and LCBBS and LCDX, and they will all - work just as they do when using the G8BPQ Switch under DOS. - - To configure the kernel for support of the NetROM protocol please - enable the following option, NetRom ( AF_NETROM ) - NetRom device names are `nr0', `nr1', etc. - - - - Kernel Compile Options: - - - Networking options ---> - [*] Amateur Radio AX.25 Level 2 - [*] Amateur Radio NET/ROM - - - - Most of the work for implementation of these protocols has been done - by Jonathon Naylor, jsn@cs.nott.ac.uk. - - diff --git a/LDP/guide/docbook/Linux-Networking/Rose.xml b/LDP/guide/docbook/Linux-Networking/Rose.xml deleted file mode 100644 index 153be5c1..00000000 --- a/LDP/guide/docbook/Linux-Networking/Rose.xml +++ /dev/null @@ -1,29 +0,0 @@ - - -Rose - - -The AX25, Netrom and Rose protocols are covered by the AX25-HOWTO. -These protocols are used by Amateur Radio Operators world wide in -packet radio experimentation. Most of the work for implementation -of these protocols has been done by Jonathon Naylor, -jsn@cs.nott.ac.uk. - - - -Rose device names are `rs0', `rs1', etc. in 2.1.* kernels. Rose is -available in the 2.1.* kernels. - - - - - Kernel Compile Options: - - - Networking options ---> - [*] Amateur Radio AX.25 Level 2 - <*> Amateur Radio X.25 PLP (Rose) - - - - diff --git a/LDP/guide/docbook/Linux-Networking/Security.xml b/LDP/guide/docbook/Linux-Networking/Security.xml deleted file mode 100644 index 6fc271c2..00000000 --- a/LDP/guide/docbook/Linux-Networking/Security.xml +++ /dev/null @@ -1,23551 +0,0 @@ -Linux Security HOWTO - -Kevin Fenzi - -tummy.com, ltd. - - - -Dave Wreski - -linuxsecurity.com - - - -v2.3, 22 January 2004 - - - This document is a general overview of security issues that face the -administrator of Linux systems. It covers general security philosophy and a -number of specific examples of how to better secure your Linux system from -intruders. Also included are pointers to security-related material and -programs. Improvements, constructive criticism, additions and corrections are -gratefully accepted. Please mail your feedback to both authors, with -"Security HOWTO" in the subject. - ------------------------------------------------------------------------------ -Table of Contents -1. Introduction - 1.1. New Versions of this Document - 1.2. Feedback - 1.3. Disclaimer - 1.4. Copyright Information - - -2. Overview - 2.1. Why Do We Need Security? - 2.2. How Secure Is Secure? - 2.3. What Are You Trying to Protect? - 2.4. Developing A Security Policy - 2.5. Means of Securing Your Site - 2.6. Organization of This Document - - -3. Physical Security - 3.1. Computer locks - 3.2. BIOS Security - 3.3. Boot Loader Security - 3.4. xlock and vlock - 3.5. Security of local devices - 3.6. Detecting Physical Security Compromises - - -4. Local Security - 4.1. Creating New Accounts - 4.2. Root Security - - -5. Files and File system Security - 5.1. Umask Settings - 5.2. File Permissions - 5.3. Integrity Checking - 5.4. Trojan Horses - - -6. Password Security and Encryption - 6.1. PGP and Public-Key Cryptography - 6.2. SSL, S-HTTP and S/MIME - 6.3. Linux IPSEC Implementations - 6.4. ssh (Secure Shell) and stelnet - 6.5. PAM - Pluggable Authentication Modules - 6.6. Cryptographic IP Encapsulation (CIPE) - 6.7. Kerberos - 6.8. Shadow Passwords. - 6.9. "Crack" and "John the Ripper" - 6.10. CFS - Cryptographic File System and TCFS - Transparent - Cryptographic File System - 6.11. X11, SVGA and display security - - -7. Kernel Security - 7.1. 2.0 Kernel Compile Options - 7.2. 2.2 Kernel Compile Options - 7.3. Kernel Devices - - -8. Network Security - 8.1. Packet Sniffers - 8.2. System services and tcp_wrappers - 8.3. Verify Your DNS Information - 8.4. identd - 8.5. Configuring and Securing the Postfix MTA - 8.6. SATAN, ISS, and Other Network Scanners - 8.7. sendmail, qmail and MTA's - 8.8. Denial of Service Attacks - 8.9. NFS (Network File System) Security. - 8.10. NIS (Network Information Service) (formerly YP). - 8.11. Firewalls - 8.12. IP Chains - Linux Kernel 2.2.x Firewalling - 8.13. Netfilter - Linux Kernel 2.4.x Firewalling - 8.14. VPNs - Virtual Private Networks - - -9. Security Preparation (before you go on-line) - 9.1. Make a Full Backup of Your Machine - 9.2. Choosing a Good Backup Schedule - 9.3. Testing your backups - 9.4. Backup Your RPM or Debian File Database - 9.5. Keep Track of Your System Accounting Data - 9.6. Apply All New System Updates. - - -10. What To Do During and After a Breakin - 10.1. Security Compromise Underway. - 10.2. Security Compromise has already happened - - -11. Security Sources - 11.1. LinuxSecurity.com References - 11.2. FTP Sites - 11.3. Web Sites - 11.4. Mailing Lists - 11.5. Books - Printed Reading Material - - -12. Glossary -13. Frequently Asked Questions -14. Conclusion -15. Acknowledgments - -1. Introduction - - This document covers some of the main issues that affect Linux security. -General philosophy and net-born resources are discussed. - - A number of other HOWTO documents overlap with security issues, and those -documents have been pointed to wherever appropriate. - - This document is not meant to be a up-to-date exploits document. Large -numbers of new exploits happen all the time. This document will tell you -where to look for such up-to-date information, and will give some general -methods to prevent such exploits from taking place. ------------------------------------------------------------------------------ - -1.1. New Versions of this Document - - New versions of this document will be periodically posted to -comp.os.linux.answers. They will also be added to the various sites that -archive such information, including: - - [http://www.linuxdoc.org/] http://www.linuxdoc.org/ - - The very latest version of this document should also be available in various -formats from: - - - -  *  [http://scrye.com/~kevin/lsh/] http://scrye.com/~kevin/lsh/ - -  *  [http://www.linuxsecurity.com/docs/Security-HOWTO] http:// - www.linuxsecurity.com/docs/Security-HOWTO - -  *  [http://www.tummy.com/security-howto] http://www.tummy.com/ - security-howto - - ------------------------------------------------------------------------------ -1.2. Feedback - - All comments, error reports, additional information and criticism of all -sorts should be directed to: - - [mailto:kevin-securityhowto@tummy.com] kevin-securityhowto@tummy.com - - and - - [mailto:dave@linuxsecurity.com] dave@linuxsecurity.com - - Note: Please send your feedback to both authors. Also, be sure and include -"Linux" "security", or "HOWTO" in your subject to avoid Kevin's spam filter. ------------------------------------------------------------------------------ - -1.3. Disclaimer - - No liability for the contents of this document can be accepted. Use the -concepts, examples and other content at your own risk. Additionally, this is -an early version, possibly with many inaccuracies or errors. - - A number of the examples and descriptions use the RedHat(tm) package layout -and system setup. Your mileage may vary. - - As far as we know, only programs that, under certain terms may be used or -evaluated for personal purposes will be described. Most of the programs will -be available, complete with source, under [http://www.gnu.org/copyleft/ -gpl.html] GNU terms. ------------------------------------------------------------------------------ - -1.4. Copyright Information - - This document is copyrighted (c)1998-2000 Kevin Fenzi and Dave Wreski, and -distributed under the following terms: - - - -  *  Linux HOWTO documents may be reproduced and distributed in whole or in - part, in any medium, physical or electronic, as long as this copyright - notice is retained on all copies. Commercial redistribution is allowed - and encouraged; however, the authors would like to be notified of any - such distributions. - -  *  All translations, derivative works, or aggregate works incorporating - any Linux HOWTO documents must be covered under this copyright notice. - That is, you may not produce a derivative work from a HOWTO and impose - additional restrictions on its distribution. Exceptions to these rules - may be granted under certain conditions; please contact the Linux HOWTO - coordinator at the address given below. - -  *  If you have questions, please contact Tim Bynum, the Linux HOWTO - coordinator, at - - - [mailto:tjbynum@metalab.unc.edu] tjbynum@metalab.unc.edu ------------------------------------------------------------------------------ - -2. Overview - - This document will attempt to explain some procedures and commonly-used -software to help your Linux system be more secure. It is important to discuss -some of the basic concepts first, and create a security foundation, before we -get started. ------------------------------------------------------------------------------ - -2.1. Why Do We Need Security? - - In the ever-changing world of global data communications, inexpensive -Internet connections, and fast-paced software development, security is -becoming more and more of an issue. Security is now a basic requirement -because global computing is inherently insecure. As your data goes from point -A to point B on the Internet, for example, it may pass through several other -points along the way, giving other users the opportunity to intercept, and -even alter, it. Even other users on your system may maliciously transform -your data into something you did not intend. Unauthorized access to your -system may be obtained by intruders, also known as "crackers", who then use -advanced knowledge to impersonate you, steal information from you, or even -deny you access to your own resources. If you're wondering what the -difference is between a "Hacker" and a "Cracker", see Eric Raymond's -document, "How to Become A Hacker", available at [http://www.catb.org/~esr/ -faqs/hacker-howto.html] http://www.catb.org/~esr/faqs/hacker-howto.html. ------------------------------------------------------------------------------ - -2.2. How Secure Is Secure? - - First, keep in mind that no computer system can ever be completely secure. -All you can do is make it increasingly difficult for someone to compromise -your system. For the average home Linux user, not much is required to keep -the casual cracker at bay. However, for high-profile Linux users (banks, -telecommunications companies, etc), much more work is required. - - Another factor to take into account is that the more secure your system is, -the more intrusive your security becomes. You need to decide where in this -balancing act your system will still be usable, and yet secure for your -purposes. For instance, you could require everyone dialing into your system -to use a call-back modem to call them back at their home number. This is more -secure, but if someone is not at home, it makes it difficult for them to -login. You could also setup your Linux system with no network or connection -to the Internet, but this limits its usefulness. - - If you are a medium to large-sized site, you should establish a security -policy stating how much security is required by your site and what auditing -is in place to check it. You can find a well-known security policy example at -[http://www.faqs.org/rfcs/rfc2196.html] http://www.faqs.org/rfcs/ -rfc2196.html. It has been recently updated, and contains a great framework -for establishing a security policy for your company. ------------------------------------------------------------------------------ - -2.3. What Are You Trying to Protect? - - Before you attempt to secure your system, you should determine what level of -threat you have to protect against, what risks you should or should not take, -and how vulnerable your system is as a result. You should analyze your system -to know what you're protecting, why you're protecting it, what value it has, -and who has responsibility for your data and other assets. - - - -  *  Risk is the possibility that an intruder may be successful in attempting - to access your computer. Can an intruder read or write files, or execute - programs that could cause damage? Can they delete critical data? Can they - prevent you or your company from getting important work done? Don't - forget: someone gaining access to your account, or your system, can also - impersonate you. - - Additionally, having one insecure account on your system can result in - your entire network being compromised. If you allow a single user to - login using a .rhosts file, or to use an insecure service such as tftp, - you risk an intruder getting 'his foot in the door'. Once the intruder - has a user account on your system, or someone else's system, it can be - used to gain access to another system, or another account. - -  *  Threat is typically from someone with motivation to gain unauthorized - access to your network or computer. You must decide whom you trust to - have access to your system, and what threat they could pose. - - There are several types of intruders, and it is useful to keep their - different characteristics in mind as you are securing your systems. - -   +  The Curious - This type of intruder is basically interested in - finding out what type of system and data you have. - -   +  The Malicious - This type of intruder is out to either bring down - your systems, or deface your web page, or otherwise force you to - spend time and money recovering from the damage he has caused. - -   +  The High-Profile Intruder - This type of intruder is trying to use - your system to gain popularity and infamy. He might use your - high-profile system to advertise his abilities. - -   +  The Competition - This type of intruder is interested in what data - you have on your system. It might be someone who thinks you have - something that could benefit him, financially or otherwise. - -   +  The Borrowers - This type of intruder is interested in setting up - shop on your system and using its resources for their own purposes. - He typically will run chat or irc servers, porn archive sites, or - even DNS servers. - -   +  The Leapfrogger - This type of intruder is only interested in your - system to use it to get into other systems. If your system is - well-connected or a gateway to a number of internal hosts, you may - well see this type trying to compromise your system. - - -  *  Vulnerability describes how well-protected your computer is from another - network, and the potential for someone to gain unauthorized access. - - What's at stake if someone breaks into your system? Of course the - concerns of a dynamic PPP home user will be different from those of a - company connecting their machine to the Internet, or another large - network. - - How much time would it take to retrieve/recreate any data that was lost? - An initial time investment now can save ten times more time later if you - have to recreate data that was lost. Have you checked your backup - strategy, and verified your data lately? - - ------------------------------------------------------------------------------ -2.4. Developing A Security Policy - - Create a simple, generic policy for your system that your users can readily -understand and follow. It should protect the data you're safeguarding as well -as the privacy of the users. Some things to consider adding are: who has -access to the system (Can my friend use my account?), who's allowed to -install software on the system, who owns what data, disaster recovery, and -appropriate use of the system. - - A generally-accepted security policy starts with the phrase - - " That which is not permitted is prohibited" - - This means that unless you grant access to a service for a user, that user -shouldn't be using that service until you do grant access. Make sure the -policies work on your regular user account. Saying, "Ah, I can't figure out -this permissions problem, I'll just do it as root" can lead to security holes -that are very obvious, and even ones that haven't been exploited yet. - - [ftp://www.faqs.org/rfcs/rfc1244.html] rfc1244 is a document that describes -how to create your own network security policy. - - [ftp://www.faqs.org/rfcs/rfc1281.html] rfc1281 is a document that shows an -example security policy with detailed descriptions of each step. - - Finally, you might want to look at the COAST policy archive at [ftp:// -coast.cs.purdue.edu/pub/doc/policy] ftp://coast.cs.purdue.edu/pub/doc/policy -to see what some real-life security policies look like. ------------------------------------------------------------------------------ - -2.5. Means of Securing Your Site - - This document will discuss various means with which you can secure the -assets you have worked hard for: your local machine, your data, your users, -your network, even your reputation. What would happen to your reputation if -an intruder deleted some of your users' data? Or defaced your web site? Or -published your company's corporate project plan for next quarter? If you are -planning a network installation, there are many factors you must take into -account before adding a single machine to your network. - - Even if you have a single dial up PPP account, or just a small site, this -does not mean intruders won't be interested in your systems. Large, -high-profile sites are not the only targets -- many intruders simply want to -exploit as many sites as possible, regardless of their size. Additionally, -they may use a security hole in your site to gain access to other sites -you're connected to. - - Intruders have a lot of time on their hands, and can avoid guessing how -you've obscured your system just by trying all the possibilities. There are -also a number of reasons an intruder may be interested in your systems, which -we will discuss later. ------------------------------------------------------------------------------ - -2.5.1. Host Security - - Perhaps the area of security on which administrators concentrate most is -host-based security. This typically involves making sure your own system is -secure, and hoping everyone else on your network does the same. Choosing good -passwords, securing your host's local network services, keeping good -accounting records, and upgrading programs with known security exploits are -among the things the local security administrator is responsible for doing. -Although this is absolutely necessary, it can become a daunting task once -your network becomes larger than a few machines. ------------------------------------------------------------------------------ - -2.5.2. Local Network Security - - Network security is as necessary as local host security. With hundreds, -thousands, or more computers on the same network, you can't rely on each one -of those systems being secure. Ensuring that only authorized users can use -your network, building firewalls, using strong encryption, and ensuring there -are no "rogue" (that is, unsecured) machines on your network are all part of -the network security administrator's duties. - - This document will discuss some of the techniques used to secure your site, -and hopefully show you some of the ways to prevent an intruder from gaining -access to what you are trying to protect. ------------------------------------------------------------------------------ - -2.5.3. Security Through Obscurity - - One type of security that must be discussed is "security through obscurity". -This means, for example, moving a service that has known security -vulnerabilities to a non-standard port in hopes that attackers won't notice -it's there and thus won't exploit it. Rest assured that they can determine -that it's there and will exploit it. Security through obscurity is no -security at all. Simply because you may have a small site, or a relatively -low profile, does not mean an intruder won't be interested in what you have. -We'll discuss what you're protecting in the next sections. ------------------------------------------------------------------------------ - -2.6. Organization of This Document - - This document has been divided into a number of sections. They cover several -broad security issues. The first, Section 3, covers how you need to protect -your physical machine from tampering. The second, Section 4, describes how to -protect your system from tampering by local users. The third, Section 5, -shows you how to setup your file systems and permissions on your files. The -next, Section 6, discusses how to use encryption to better secure your -machine and network. Section 7 discusses what kernel options you should set -or be aware of for a more secure system. Section 8, describes how to better -secure your Linux system from network attacks. Section 9, discusses how to -prepare your machine(s) before bringing them on-line. Next, Section 10, -discusses what to do when you detect a system compromise in progress or -detect one that has recently happened. In Section 11, some primary security -resources are enumerated. The Q and A section Section 13, answers some -frequently-asked questions, and finally a conclusion in Section 14 - - The two main points to realize when reading this document are: - - - -  *  Be aware of your system. Check system logs such as /var/log/messages and - keep an eye on your system, and - -  *  Keep your system up-to-date by making sure you have installed the - current versions of software and have upgraded per security alerts. Just - doing this will help make your system markedly more secure. - - ------------------------------------------------------------------------------ -3. Physical Security - - The first layer of security you need to take into account is the physical -security of your computer systems. Who has direct physical access to your -machine? Should they? Can you protect your machine from their tampering? -Should you? - - How much physical security you need on your system is very dependent on your -situation, and/or budget. - - If you are a home user, you probably don't need a lot (although you might -need to protect your machine from tampering by children or annoying -relatives). If you are in a lab, you need considerably more, but users will -still need to be able to get work done on the machines. Many of the following -sections will help out. If you are in an office, you may or may not need to -secure your machine off-hours or while you are away. At some companies, -leaving your console unsecured is a termination offense. - - Obvious physical security methods such as locks on doors, cables, locked -cabinets, and video surveillance are all good ideas, but beyond the scope of -this document. :) ------------------------------------------------------------------------------ - -3.1. Computer locks - - Many modern PC cases include a "locking" feature. Usually this will be a -socket on the front of the case that allows you to turn an included key to a -locked or unlocked position. Case locks can help prevent someone from -stealing your PC, or opening up the case and directly manipulating/stealing -your hardware. They can also sometimes prevent someone from rebooting your -computer from their own floppy or other hardware. - - These case locks do different things according to the support in the -motherboard and how the case is constructed. On many PC's they make it so you -have to break the case to get the case open. On some others, they will not -let you plug in new keyboards or mice. Check your motherboard or case -instructions for more information. This can sometimes be a very useful -feature, even though the locks are usually very low-quality and can easily be -defeated by attackers with locksmithing. - - Some machines (most notably SPARC's and macs) have a dongle on the back -that, if you put a cable through, attackers would have to cut the cable or -break the case to get into it. Just putting a padlock or combo lock through -these can be a good deterrent to someone stealing your machine. ------------------------------------------------------------------------------ - -3.2. BIOS Security - - The BIOS is the lowest level of software that configures or manipulates your -x86-based hardware. LILO and other Linux boot methods access the BIOS to -determine how to boot up your Linux machine. Other hardware that Linux runs -on has similar software (Open Firmware on Macs and new Suns, Sun boot PROM, -etc...). You can use your BIOS to prevent attackers from rebooting your -machine and manipulating your Linux system. - - Many PC BIOSs let you set a boot password. This doesn't provide all that -much security (the BIOS can be reset, or removed if someone can get into the -case), but might be a good deterrent (i.e. it will take time and leave traces -of tampering). Similarly, on S/Linux (Linux for SPARC(tm) processor -machines), your EEPROM can be set to require a boot-up password. This might -slow attackers down. - - Another risk of trusting BIOS passwords to secure your system is the default -password problem. Most BIOS makers don't expect people to open up their -computer and disconnect batteries if they forget their password and have -equipped their BIOSes with default passwords that work regardless of your -chosen password. Some of the more common passwords include: - - j262 AWARD_SW AWARD_PW lkwpeter Biostar AMI Award bios BIOS setup cmos AMI! -SW1 AMI?SW1 password hewittrand shift + s y x z - - I tested an Award BIOS and AWARD_PW worked. These passwords are quite easily -available from manufacturers' websites and [http://astalavista.box.sk] http:/ -/astalavista.box.sk and as such a BIOS password cannot be considered adequate -protection from a knowledgeable attacker. - - Many x86 BIOSs also allow you to specify various other good security -settings. Check your BIOS manual or look at it the next time you boot up. For -example, some BIOSs disallow booting from floppy drives and some require -passwords to access some BIOS features. - - Note: If you have a server machine, and you set up a boot password, your -machine will not boot up unattended. Keep in mind that you will need to come -in and supply the password in the event of a power failure. ;( ------------------------------------------------------------------------------ - -3.3. Boot Loader Security - - The various Linux boot loaders also can have a boot password set. LILO, for -example, has password and restricted settings; password requires password at -boot time, whereas restricted requires a boot-time password only if you -specify options (such as single) at the LILO prompt. - - >From the lilo.conf man page: -password=password - The per-image option `password=...' (see below) applies to all images. - -restricted - The per-image option `restricted' (see below) applies to all images. - - password=password - Protect the image by a password. - - restricted - A password is only required to boot the image if - parameters are specified on the command line - (e.g. single). - - Keep in mind when setting all these passwords that you need to remember -them. :) Also remember that these passwords will merely slow the determined -attacker. They won't prevent someone from booting from a floppy, and mounting -your root partition. If you are using security in conjunction with a boot -loader, you might as well disable booting from a floppy in your computer's -BIOS, and password-protect the BIOS. - - Also keep in mind that the /etc/lilo.conf will need to be mode "600" -(readable and writing for root only), or others will be able to read your -passwords! - - >From the GRUB info page: GRUB provides "password" feature, so that only -administrators can start the interactive operations (i.e. editing menu -entries and entering the command-line interface). To use this feature, you -need to run the command `password' in your configuration file (*note -password::), like this: - - password --md5 PASSWORD - - If this is specified, GRUB disallows any interactive control, until you -press the key

and enter a correct password. The option `--md5' tells GRUB -that `PASSWORD' is in MD5 format. If it is omitted, GRUB assumes the -`PASSWORD' is in clear text. - - You can encrypt your password with the command `md5crypt' (*note -md5crypt::). For example, run the grub shell (*note Invoking the grub -shell::), and enter your password: - - grub> md5crypt Password: ********** Encrypted: $1$U$JK7xFegdxWH6VuppCUSIb. - - Then, cut and paste the encrypted password to your configuration file. - - Grub also has a 'lock' command that will allow you to lock a partition if -you don't provide the correct password. Simply add 'lock' and the partition -will not be accessable until the user supplies a password. - - If anyone has security-related information from a different boot loader, we -would love to hear it. (grub, silo, milo, linload, etc). - - Note: If you have a server machine, and you set up a boot password, your -machine will not boot up unattended. Keep in mind that you will need to come -in and supply the password in the event of a power failure. ;( ------------------------------------------------------------------------------ - -3.4. xlock and vlock - - If you wander away from your machine from time to time, it is nice to be -able to "lock" your console so that no one can tamper with, or look at, your -work. Two programs that do this are: xlock and vlock. - - xlock is a X display locker. It should be included in any Linux -distributions that support X. Check out the man page for it for more options, -but in general you can run xlock from any xterm on your console and it will -lock the display and require your password to unlock. - - vlock is a simple little program that allows you to lock some or all of the -virtual consoles on your Linux box. You can lock just the one you are working -in or all of them. If you just lock one, others can come in and use the -console; they will just not be able to use your virtual console until you -unlock it. vlock ships with RedHat Linux, but your mileage may vary. - - Of course locking your console will prevent someone from tampering with your -work, but won't prevent them from rebooting your machine or otherwise -disrupting your work. It also does not prevent them from accessing your -machine from another machine on the network and causing problems. - - More importantly, it does not prevent someone from switching out of the X -Window System entirely, and going to a normal virtual console login prompt, -or to the VC that X11 was started from, and suspending it, thus obtaining -your privileges. For this reason, you might consider only using it while -under control of xdm. ------------------------------------------------------------------------------ - -3.5. Security of local devices - - If you have a webcam or a microphone attached to your system, you should -consider if there is some danger of a attacker gaining access to those -devices. When not in use, unplugging or removing such devices might be an -option. Otherwise you should carefully read and look at any software with -provides access to such devices. ------------------------------------------------------------------------------ - -3.6. Detecting Physical Security Compromises - - The first thing to always note is when your machine was rebooted. Since -Linux is a robust and stable OS, the only times your machine should reboot is -when you take it down for OS upgrades, hardware swapping, or the like. If -your machine has rebooted without you doing it, that may be a sign that an -intruder has compromised it. Many of the ways that your machine can be -compromised require the intruder to reboot or power off your machine. - - Check for signs of tampering on the case and computer area. Although many -intruders clean traces of their presence out of logs, it's a good idea to -check through them all and note any discrepancy. - - It is also a good idea to store log data at a secure location, such as a -dedicated log server within your well-protected network. Once a machine has -been compromised, log data becomes of little use as it most likely has also -been modified by the intruder. - - The syslog daemon can be configured to automatically send log data to a -central syslog server, but this is typically sent unencrypted, allowing an -intruder to view data as it is being transferred. This may reveal information -about your network that is not intended to be public. There are syslog -daemons available that encrypt the data as it is being sent. - - Also be aware that faking syslog messages is easy -- with an exploit program -having been published. Syslog even accepts net log entries claiming to come -from the local host without indicating their true origin. - - Some things to check for in your logs: - -  *  Short or incomplete logs. - -  *  Logs containing strange timestamps. - -  *  Logs with incorrect permissions or ownership. - -  *  Records of reboots or restarting of services. - -  *  missing logs. - -  *  su entries or logins from strange places. - - - We will discuss system log data Section 9.5 in the HOWTO. ------------------------------------------------------------------------------ - -4. Local Security - - The next thing to take a look at is the security in your system against -attacks from local users. Did we just say local users? Yes! - - Getting access to a local user account is one of the first things that -system intruders attempt while on their way to exploiting the root account. -With lax local security, they can then "upgrade" their normal user access to -root access using a variety of bugs and poorly setup local services. If you -make sure your local security is tight, then the intruder will have another -hurdle to jump. - - Local users can also cause a lot of havoc with your system even (especially) -if they really are who they say they are. Providing accounts to people you -don't know or for whom you have no contact information is a very bad idea. ------------------------------------------------------------------------------ - -4.1. Creating New Accounts - - You should make sure you provide user accounts with only the minimal -requirements for the task they need to do. If you provide your son (age 10) -with an account, you might want him to only have access to a word processor -or drawing program, but be unable to delete data that is not his. - - Several good rules of thumb when allowing other people legitimate access to -your Linux machine: - - - -  *  Give them the minimal amount of privileges they need. - -  *  Be aware when/where they login from, or should be logging in from. - -  *  Make sure you remove inactive accounts, which you can determine by using - the 'last' command and/or checking log files for any activity by the - user. - -  *  The use of the same userid on all computers and networks is advisable to - ease account maintenance, and permits easier analysis of log data. - -  *  The creation of group user-id's should be absolutely prohibited. User - accounts also provide accountability, and this is not possible with group - accounts. - - - Many local user accounts that are used in security compromises have not been -used in months or years. Since no one is using them they, provide the ideal -attack vehicle. ------------------------------------------------------------------------------ - -4.2. Root Security - - The most sought-after account on your machine is the root (superuser) -account. This account has authority over the entire machine, which may also -include authority over other machines on the network. Remember that you -should only use the root account for very short, specific tasks, and should -mostly run as a normal user. Even small mistakes made while logged in as the -root user can cause problems. The less time you are on with root privileges, -the safer you will be. - - Several tricks to avoid messing up your own box as root: - -  *  When doing some complex command, try running it first in a - non-destructive way...especially commands that use globing: e.g., if you - want to do rm foo*.bak, first do ls foo*.bak and make sure you are going - to delete the files you think you are. Using echo in place of destructive - commands also sometimes works. - -  *  Provide your users with a default alias to the rm command to ask for - confirmation for deletion of files. - -  *  Only become root to do single specific tasks. If you find yourself - trying to figure out how to do something, go back to a normal user shell - until you are sure what needs to be done by root. - -  *  The command path for the root user is very important. The command path - (that is, the PATH environment variable) specifies the directories in - which the shell searches for programs. Try to limit the command path for - the root user as much as possible, and never include . (which means "the - current directory") in your PATH. Additionally, never have writable - directories in your search path, as this can allow attackers to modify or - place new binaries in your search path, allowing them to run as root the - next time you run that command. - -  *  Never use the rlogin/rsh/rexec suite of tools (called the r-utilities) - as root. They are subject to many sorts of attacks, and are downright - dangerous when run as root. Never create a .rhosts file for root. - -  *  The /etc/securetty file contains a list of terminals that root can login - from. By default (on Red Hat Linux) this is set to only the local virtual - consoles(vtys). Be very wary of adding anything else to this file. You - should be able to login remotely as your regular user account and then su - if you need to (hopefully over Section 6.4 or other encrypted channel), - so there is no need to be able to login directly as root. - -  *  Always be slow and deliberate running as root. Your actions could affect - a lot of things. Think before you type! - - - If you absolutely positively need to allow someone (hopefully very trusted) -to have root access to your machine, there are a few tools that can help. -sudo allows users to use their password to access a limited set of commands -as root. This would allow you to, for instance, let a user be able to eject -and mount removable media on your Linux box, but have no other root -privileges. sudo also keeps a log of all successful and unsuccessful sudo -attempts, allowing you to track down who used what command to do what. For -this reason sudo works well even in places where a number of people have root -access, because it helps you keep track of changes made. - - Although sudo can be used to give specific users specific privileges for -specific tasks, it does have several shortcomings. It should be used only for -a limited set of tasks, like restarting a server, or adding new users. Any -program that offers a shell escape will give root access to a user invoking -it via sudo. This includes most editors, for example. Also, a program as -innocuous as /bin/cat can be used to overwrite files, which could allow root -to be exploited. Consider sudo as a means for accountability, and don't -expect it to replace the root user and still be secure. ------------------------------------------------------------------------------ - -5. Files and File system Security - - A few minutes of preparation and planning ahead before putting your systems -on-line can help to protect them and the data stored on them. - -  *  There should never be a reason for users' home directories to allow SUID - /SGID programs to be run from there. Use the nosuid option in /etc/fstab - for partitions that are writable by others than root. You may also wish - to use nodev and noexec on users' home partitions, as well as /var, thus - prohibiting execution of programs, and creation of character or block - devices, which should never be necessary anyway. - -  *  If you are exporting file-systems using NFS, be sure to configure /etc/ - exports with the most restrictive access possible. This means not using - wild cards, not allowing root write access, and exporting read-only - wherever possible. - -  *  Configure your users' file-creation umask to be as restrictive as - possible. See Section 5.1. - -  *  If you are mounting file systems using a network file system such as - NFS, be sure to configure /etc/exports with suitable restrictions. - Typically, using `nodev', `nosuid', and perhaps `noexec', are desirable. - -  *  Set file system limits instead of allowing unlimited as is the default. - You can control the per-user limits using the resource-limits PAM module - and /etc/pam.d/limits.conf. For example, limits for group users might - look like this: - - - @users hard core 0 - @users hard nproc 50 - @users hard rss 5000 - - This says to prohibit the creation of core files, restrict the number of - processes to 50, and restrict memory usage per user to 5M. - - You can also use the /etc/login.defs configuration file to set the same - limits. - -  *  The /var/log/wtmp and /var/run/utmp files contain the login records for - all users on your system. Their integrity must be maintained because they - can be used to determine when and from where a user (or potential - intruder) has entered your system. These files should also have 644 - permissions, without affecting normal system operation. - -  *  The immutable bit can be used to prevent accidentally deleting or - overwriting a file that must be protected. It also prevents someone from - creating a hard link to the file. See the chattr(1) man page for - information on the immutable bit. - -  *  SUID and SGID files on your system are a potential security risk, and - should be monitored closely. Because these programs grant special - privileges to the user who is executing them, it is necessary to ensure - that insecure programs are not installed. A favorite trick of crackers is - to exploit SUID-root programs, then leave a SUID program as a back door - to get in the next time, even if the original hole is plugged. - - Find all SUID/SGID programs on your system, and keep track of what they - are, so you are aware of any changes which could indicate a potential - intruder. Use the following command to find all SUID/SGID programs on - your system: - - - root# find / -type f \( -perm -04000 -o -perm -02000 \) - - The Debian distribution runs a job each night to determine what SUID - files exist. It then compares this to the previous night's run. You can - look in /var/log/setuid* for this log. - - You can remove the SUID or SGID permissions on a suspicious program with - chmod, then restore them back if you absolutely feel it is necessary. - -  *  World-writable files, particularly system files, can be a security hole - if a cracker gains access to your system and modifies them. Additionally, - world-writable directories are dangerous, since they allow a cracker to - add or delete files as he wishes. To locate all world-writable files on - your system, use the following command: - - - root# find / -perm -2 ! -type l -ls - and be sure you know why those files are writable. In the normal course - of operation, several files will be world-writable, including some from / - dev, and symbolic links, thus the ! -type l which excludes these from the - previous find command. - -  *  - - Unowned files may also be an indication an intruder has accessed your - system. You can locate files on your system that have no owner, or belong - to no group with the command: - - - root# find / \( -nouser -o -nogroup \) -print - -  *  Finding .rhosts files should be a part of your regular system - administration duties, as these files should not be permitted on your - system. Remember, a cracker only needs one insecure account to - potentially gain access to your entire network. You can locate all - .rhosts files on your system with the following command: - root# find /home -name .rhosts -print - -  *  - - Finally, before changing permissions on any system files, make sure you - understand what you are doing. Never change permissions on a file because - it seems like the easy way to get things working. Always determine why - the file has that permission before changing it. - - ------------------------------------------------------------------------------ -5.1. Umask Settings - - The umask command can be used to determine the default file creation mode on -your system. It is the octal complement of the desired file mode. If files -are created without any regard to their permissions settings, the user could -inadvertently give read or write permission to someone that should not have -this permission. Typical umask settings include 022, 027, and 077 (which is -the most restrictive). Normally the umask is set in /etc/profile, so it -applies to all users on the system. The resulting permission is calculated as -follows: The default permission of user/group/others (7 for directories, 6 -for files) is combined with the inverted mask (NOT) using AND on a -per-bit-basis. - - Example 1: - - file, default 6, binary: 110 mask, eg. 2: 010, NOT: 101 - - resulting permission, AND: 100 (equals 4, r__) - - Example 2: - - file, default 6, binary: 110 mask, eg. 6: 110, NOT: 001 - - resulting permission, AND: 000 (equals 0, ___) - - Example 3: - - directory, default 7, binary: 111 mask, eg. 2: 010, NOT: 101 - - resulting permission, AND: 101 (equals 5, r_x) - - Example 4: - - directory, default 7, binary: 111 mask, eg. 6: 110, NOT: 001 - - resulting permission, AND: 001 (equals 1, __x) - - - # Set the user's default umask - umask 033 -Be sure to make root's umask 077, which will disable read, write, and execute -permission for other users, unless explicitly changed using chmod. In this -case, newly-created directories would have 744 permissions, obtained by -subtracting 033 from 777. Newly-created files using the 033 umask would have -permissions of 644. - - If you are using Red Hat, and adhere to their user and group ID creation -scheme (User Private Groups), it is only necessary to use 002 for a umask. -This is due to the fact that the default configuration is one user per group. ------------------------------------------------------------------------------ - -5.2. File Permissions - - It's important to ensure that your system files are not open for casual -editing by users and groups who shouldn't be doing such system maintenance. - - Unix separates access control on files and directories according to three -characteristics: owner, group, and other. There is always exactly one owner, -any number of members of the group, and everyone else. - - A quick explanation of Unix permissions: - - Ownership - Which user(s) and group(s) retain(s) control of the permission -settings of the node and parent of the node - - Permissions - Bits capable of being set or reset to allow certain types of -access to it. Permissions for directories may have a different meaning than -the same set of permissions on files. - - Read: - -  *  To be able to view contents of a file - -  *  To be able to read a directory - - - Write: - -  *  To be able to add to or change a file - -  *  To be able to delete or move files in a directory - - - Execute: - -  *  To be able to run a binary program or shell script - -  *  To be able to search in a directory, combined with read permission - - - - -Save Text Attribute: (For directories) - The "sticky bit" also has a different meaning when applied to - directories than when applied to files. If the sticky bit is set on a - directory, then a user may only delete files that the he owns or for - which he has explicit write permission granted, even when he has write - access to the directory. This is designed for directories like /tmp, - which are world-writable, but where it may not be desirable to allow any - user to delete files at will. The sticky bit is seen as a t in a long - directory listing. - - - - -SUID Attribute: (For Files) - This describes set-user-id permissions on the file. When the set user ID - access mode is set in the owner permissions, and the file is executable, - processes which run it are granted access to system resources based on - user who owns the file, as opposed to the user who created the process. - This is the cause of many "buffer overflow" exploits. - - -SGID Attribute: (For Files) - If set in the group permissions, this bit controls the "set group id" - status of a file. This behaves the same way as SUID, except the group is - affected instead. The file must be executable for this to have any - effect. - - - - -SGID Attribute: (For directories) - If you set the SGID bit on a directory (with chmod g+s directory), files - created in that directory will have their group set to the directory's - group. - - - You - The owner of the file - - Group - The group you belong to - - Everyone - Anyone on the system that is not the owner or a member of the -group - - File Example: - - - -rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin - 1st bit - directory? (no) - 2nd bit - read by owner? (yes, by kevin) - 3rd bit - write by owner? (yes, by kevin) - 4th bit - execute by owner? (no) - 5th bit - read by group? (yes, by users) - 6th bit - write by group? (no) - 7th bit - execute by group? (no) - 8th bit - read by everyone? (yes, by everyone) - 9th bit - write by everyone? (no) - 10th bit - execute by everyone? (no) - - - The following lines are examples of the minimum sets of permissions that are -required to perform the access described. You may want to give more -permission than what's listed here, but this should describe what these -minimum permissions on files do: - - --r-------- Allow read access to the file by owner ---w------- Allows the owner to modify or delete the file - (Note that anyone with write permission to the directory - the file is in can overwrite it and thus delete it) ----x------ The owner can execute this program, but not shell scripts, - which still need read permission ----s------ Will execute with effective User ID = to owner ---------s- Will execute with effective Group ID = to group --rw------T No update of "last modified time". Usually used for swap - files ----t------ No effect. (formerly sticky bit) - -Directory Example: - drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/ - 1st bit - directory? (yes, it contains many files) - 2nd bit - read by owner? (yes, by kevin) - 3rd bit - write by owner? (yes, by kevin) - 4th bit - execute by owner? (yes, by kevin) - 5th bit - read by group? (yes, by users - 6th bit - write by group? (no) - 7th bit - execute by group? (yes, by users) - 8th bit - read by everyone? (yes, by everyone) - 9th bit - write by everyone? (no) - 10th bit - execute by everyone? (yes, by everyone) - - - The following lines are examples of the minimum sets of permissions that are -required to perform the access described. You may want to give more -permission than what's listed, but this should describe what these minimum -permissions on directories do: - - -dr-------- The contents can be listed, but file attributes can't be read -d--x------ The directory can be entered, and used in full execution paths -dr-x------ File attributes can be read by owner -d-wx------ Files can be created/deleted, even if the directory - isn't the current one -d------x-t Prevents files from deletion by others with write - access. Used on /tmp -d---s--s-- No effect - - System configuration files (usually in /etc) are usually mode 640 -(-rw-r-----), and owned by root. Depending on your site's security -requirements, you might adjust this. Never leave any system files writable by -a group or everyone. Some configuration files, including /etc/shadow, should -only be readable by root, and directories in /etc should at least not be -accessible by others. - - - -SUID Shell Scripts - SUID shell scripts are a serious security risk, and for this reason the - kernel will not honor them. Regardless of how secure you think the shell - script is, it can be exploited to give the cracker a root shell. - - ------------------------------------------------------------------------------ -5.3. Integrity Checking - - Another very good way to detect local (and also network) attacks on your -system is to run an integrity checker like Tripwire, Aide or Osiris. These -integrety checkers run a number of checksums on all your important binaries -and config files and compares them against a database of former, known-good -values as a reference. Thus, any changes in the files will be flagged. - - It's a good idea to install these sorts of programs onto a floppy, and then -physically set the write protect on the floppy. This way intruders can't -tamper with the integrety checker itself or change the database. Once you -have something like this setup, it's a good idea to run it as part of your -normal security administration duties to see if anything has changed. - - You can even add a crontab entry to run the checker from your floppy every -night and mail you the results in the morning. Something like: - # set mailto - MAILTO=kevin - # run Tripwire - 15 05 * * * root /usr/local/adm/tcheck/tripwire -will mail you a report each morning at 5:15am. - - Integrity checkers can be a godsend to detecting intruders before you would -otherwise notice them. Since a lot of files change on the average system, you -have to be careful what is cracker activity and what is your own doing. - - You can find the freely available unsusported version of Tripwire at [http:/ -/www.tripwire.org] http://www.tripwire.org, free of charge. Manuals and -support can be purchased. - - Aide can be found at [http://www.cs.tut.fi/~rammer/aide.html] http:// -www.cs.tut.fi/~rammer/aide.html. - - Osiris can be found at [http://www.shmoo.com/osiris/] http://www.shmoo.com/ -osiris/. ------------------------------------------------------------------------------ - -5.4. Trojan Horses - - "Trojan Horses" are named after the fabled ploy in Virgil's "Aenid". The -idea is that a cracker distributes a program or binary that sounds great, and -encourages other people to download it and run it as root. Then the program -can compromise their system while they are not paying attention. While they -think the binary they just pulled down does one thing (and it might very -well), it also compromises their security. - - You should take care of what programs you install on your machine. RedHat -provides MD5 checksums and PGP signatures on its RPM files so you can verify -you are installing the real thing. Other distributions have similar methods. -You should never run any unfamiliar binary, for which you don't have the -source, as root. Few attackers are willing to release source code to public -scrutiny. - - Although it can be complex, make sure you are getting the source for a -program from its real distribution site. If the program is going to run as -root, make sure either you or someone you trust has looked over the source -and verified it. ------------------------------------------------------------------------------ - -6. Password Security and Encryption - - One of the most important security features used today are passwords. It is -important for both you and all your users to have secure, unguessable -passwords. Most of the more recent Linux distributions include passwd -programs that do not allow you to set a easily guessable password. Make sure -your passwd program is up to date and has these features. - - In-depth discussion of encryption is beyond the scope of this document, but -an introduction is in order. Encryption is very useful, possibly even -necessary in this day and age. There are all sorts of methods of encrypting -data, each with its own set of characteristics. - - Most Unicies (and Linux is no exception) primarily use a one-way encryption -algorithm, called DES (Data Encryption Standard) to encrypt your passwords. -This encrypted password is then stored in (typically) /etc/passwd (or less -commonly) /etc/shadow. When you attempt to login, the password you type in is -encrypted again and compared with the entry in the file that stores your -passwords. If they match, it must be the same password, and you are allowed -access. Although DES is a two-way encryption algorithm (you can code and then -decode a message, given the right keys), the variant that most Unixes use is -one-way. This means that it should not be possible to reverse the encryption -to get the password from the contents of /etc/passwd (or /etc/shadow). - - Brute force attacks, such as "Crack" or "John the Ripper" (see section -Section 6.9) can often guess passwords unless your password is sufficiently -random. PAM modules (see below) allow you to use a different encryption -routine with your passwords (MD5 or the like). You can use Crack to your -advantage, as well. Consider periodically running Crack against your own -password database, to find insecure passwords. Then contact the offending -user, and instruct him to change his password. - - You can go to [http://consult.cern.ch/writeup/security/security_3.html] -http://consult.cern.ch/writeup/security/security_3.html for information on -how to choose a good password. ------------------------------------------------------------------------------ - -6.1. PGP and Public-Key Cryptography - - Public-key cryptography, such as that used for PGP, uses one key for -encryption, and one key for decryption. Traditional cryptography, however, -uses the same key for encryption and decryption; this key must be known to -both parties, and thus somehow transferred from one to the other securely. - - To alleviate the need to securely transmit the encryption key, public-key -encryption uses two separate keys: a public key and a private key. Each -person's public key is available by anyone to do the encryption, while at the -same time each person keeps his or her private key to decrypt messages -encrypted with the correct public key. - - There are advantages to both public key and private key cryptography, and -you can read about those differences in [http://www.rsa.com/rsalabs/faq/] the -RSA Cryptography FAQ, listed at the end of this section. - - PGP (Pretty Good Privacy) is well-supported on Linux. Versions 2.6.2 and 5.0 -are known to work well. For a good primer on PGP and how to use it, take a -look at the PGP FAQ: [http://www.pgp.com/service/export/faq/55faq.cgi] http:/ -/www.pgp.com/service/export/faq/55faq.cgi - - Be sure to use the version that is applicable to your country. Due to export -restrictions by the US Government, strong-encryption is prohibited from being -transferred in electronic form outside the country. - - US export controls are now managed by EAR (Export Administration -Regulations). They are no longer governed by ITAR. - - There is also a step-by-step guide for configuring PGP on Linux available at -[http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/ -article7.html] http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/ -November1997/article7.html. It was written for the international version of -PGP, but is easily adaptable to the United States version. You may also need -a patch for some of the latest versions of Linux; the patch is available at -[ftp://metalab.unc.edu/pub/Linux/apps/crypto] ftp://metalab.unc.edu/pub/Linux -/apps/crypto. - - There is a project maintaining a free re-implementation of pgp with open -source. GnuPG is a complete and free replacement for PGP. Because it does not -use IDEA or RSA it can be used without any restrictions. GnuPG is in -compliance with [http://www.faqs.org/rfcs/rfc2440.html] OpenPGP. See the GNU -Privacy Guard web page for more information: [http://www.gnupg.org] http:// -www.gnupg.org/. - - More information on cryptography can be found in the RSA cryptography FAQ, -available at [http://www.rsa.com/rsalabs/newfaq/] http://www.rsa.com/rsalabs/ -newfaq/. Here you will find information on such terms as "Diffie-Hellman", -"public-key cryptography", "digital certificates", etc. ------------------------------------------------------------------------------ - -6.2. SSL, S-HTTP and S/MIME - - Often users ask about the differences between the various security and -encryption protocols, and how to use them. While this isn't an encryption -document, it is a good idea to explain briefly what each protocol is, and -where to find more information. - -  *  SSL: - SSL, or Secure Sockets Layer, is an encryption method developed - by Netscape to provide security over the Internet. It supports several - different encryption protocols, and provides client and server - authentication. SSL operates at the transport layer, creates a secure - encrypted channel of data, and thus can seamlessly encrypt data of many - types. This is most commonly seen when going to a secure site to view a - secure online document with Communicator, and serves as the basis for - secure communications with Communicator, as well as many other Netscape - Communications data encryption. More information can be found at [http:// - www.consensus.com/security/ssl-talk-faq.html] http://www.consensus.com/ - security/ssl-talk-faq.html. Information on Netscape's other security - implementations, and a good starting point for these protocols is - available at [http://home.netscape.com/info/security-doc.html] http:// - home.netscape.com/info/security-doc.html. It's also worth noting that the - SSL protocol can be used to pass many other common protocols, "wrapping" - them for security. See [http://www.quiltaholic.com/rickk/sslwrap/] http:/ - /www.quiltaholic.com/rickk/sslwrap/ - -  *  S-HTTP: - S-HTTP is another protocol that provides security services - across the Internet. It was designed to provide confidentiality, - authentication, integrity, and non-repudiability [cannot be mistaken for - someone else] while supporting multiple key-management mechanisms and - cryptographic algorithms via option negotiation between the parties - involved in each transaction. S-HTTP is limited to the specific software - that is implementing it, and encrypts each message individually. [ From - RSA Cryptography FAQ, page 138] - -  *  S/MIME: - S/MIME, or Secure Multipurpose Internet Mail Extension, is an - encryption standard used to encrypt electronic mail and other types of - messages on the Internet. It is an open standard developed by RSA, so it - is likely we will see it on Linux one day soon. More information on S/ - MIME can be found at [http://home.netscape.com/assist/security/smime/ - overview.html] http://home.netscape.com/assist/security/smime/ - overview.html. - - ------------------------------------------------------------------------------ -6.3. Linux IPSEC Implementations - - Along with CIPE, and other forms of data encryption, there are also several -other implementations of IPSEC for Linux. IPSEC is an effort by the IETF to -create cryptographically-secure communications at the IP network level, and -to provide authentication, integrity, access control, and confidentiality. -Information on IPSEC and Internet draft can be found at [http://www.ietf.org/ -html.charters/ipsec-charter.html] http://www.ietf.org/html.charters/ -ipsec-charter.html. You can also find links to other protocols involving key -management, and an IPSEC mailing list and archives. - - The x-kernel Linux implementation, which is being developed at the -University of Arizona, uses an object-based framework for implementing -network protocols called x-kernel, and can be found at [http:// -www.cs.arizona.edu/xkernel/hpcc-blue/linux.html] http://www.cs.arizona.edu/ -xkernel/hpcc-blue/linux.html. Most simply, the x-kernel is a method of -passing messages at the kernel level, which makes for an easier -implementation. - - Another freely-available IPSEC implementation is the Linux FreeS/WAN IPSEC. -Their web page states, ""These services allow you to build secure tunnels -through untrusted networks. Everything passing through the untrusted net is -encrypted by the IPSEC gateway machine and decrypted by the gateway at the -other end. The result is Virtual Private Network or VPN. This is a network -which is effectively private even though it includes machines at several -different sites connected by the insecure Internet."" - - It's available for download from [http://www.xs4all.nl/~freeswan/] http:// -www.xs4all.nl/~freeswan/, and has just reached 1.0 at the time of this -writing. - - As with other forms of cryptography, it is not distributed with the kernel -by default due to export restrictions. ------------------------------------------------------------------------------ - -6.4. ssh (Secure Shell) and stelnet - - ssh and stelnet are suites of programs that allow you to login to remote -systems and have a encrypted connection. - - openssh is a suite of programs used as a secure replacement for rlogin, rsh -and rcp. It uses public-key cryptography to encrypt communications between -two hosts, as well as to authenticate users. It can be used to securely login -to a remote host or copy data between hosts, while preventing -man-in-the-middle attacks (session hijacking) and DNS spoofing. It will -perform data compression on your connections, and secure X11 communications -between hosts. - - There are several ssh implementiations now. The original commercial -implementation by Data Fellows can be found at The ssh home page can be found -at [http://www.datafellows.com] http://www.datafellows.com. - - The excellent Openssh implementation is based on a early version of the -datafellows ssh and has been totally reworked to not include any patented or -proprietary pieces. It is free and under a BSD license. It can be found at: -[http://www.openssh.com] http://www.openssh.com. - - There is also a open source project to re-implement ssh from the ground up -called "psst...". For more information see: [http://www.net.lut.ac.uk/psst/] -http://www.net.lut.ac.uk/psst/ - - You can also use ssh from your Windows workstation to your Linux ssh server. -There are several freely available Windows client implementations, including -the one at [http://guardian.htu.tuwien.ac.at/therapy/ssh/] http:// -guardian.htu.tuwien.ac.at/therapy/ssh/ as well as a commercial implementation -from DataFellows, at [http://www.datafellows.com] http://www.datafellows.com. - - SSLeay is a free implementation of Netscape's Secure Sockets Layer protocol, -developed by Eric Young. It includes several applications, such as Secure -telnet, a module for Apache, several databases, as well as several algorithms -including DES, IDEA and Blowfish. - - Using this library, a secure telnet replacement has been created that does -encryption over a telnet connection. Unlike SSH, stelnet uses SSL, the Secure -Sockets Layer protocol developed by Netscape. You can find Secure telnet and -Secure FTP by starting with the SSLeay FAQ, available at [http:// -www.psy.uq.oz.au/~ftp/Crypto/] http://www.psy.uq.oz.au/~ftp/Crypto/. - - SRP is another secure telnet/ftp implementation. From their web page: - - ""The SRP project is developing secure Internet software for free worldwide -use. Starting with a fully-secure Telnet and FTP distribution, we hope to -supplant weak networked authentication systems with strong replacements that -do not sacrifice user-friendliness for security. Security should be the -default, not an option!" " - - For more information, go to [http://www-cs-students.stanford.edu/~tjw/srp/] -http://www-cs-students.stanford.edu/~tjw/srp/ ------------------------------------------------------------------------------ - -6.5. PAM - Pluggable Authentication Modules - - Newer versions of the Red Hat Linux and Debian Linux distributions ship with -a unified authentication scheme called "PAM". PAM allows you to change your -authentication methods and requirements on the fly, and encapsulate all local -authentication methods without recompiling any of your binaries. -Configuration of PAM is beyond the scope of this document, but be sure to -take a look at the PAM web site for more information. [http://www.kernel.org/ -pub/linux/libs/pam/index.html] http://www.kernel.org/pub/linux/libs/pam/ -index.html. - - Just a few of the things you can do with PAM: - - - -  *  Use encryption other than DES for your passwords. (Making them harder to - brute-force decode) - -  *  Set resource limits on all your users so they can't perform - denial-of-service attacks (number of processes, amount of memory, etc) - -  *  Enable shadow passwords (see below) on the fly - -  *  allow specific users to login only at specific times from specific - places - - - Within a few hours of installing and configuring your system, you can -prevent many attacks before they even occur. For example, use PAM to disable -the system-wide usage of .rhosts files in user's home directories by adding -these lines to /etc/pam.d/rlogin: - # - # Disable rsh/rlogin/rexec for users - # - login auth required pam_rhosts_auth.so no_rhosts ------------------------------------------------------------------------------ - -6.6. Cryptographic IP Encapsulation (CIPE) - - The primary goal of this software is to provide a facility for secure -(against eavesdropping, including traffic analysis, and faked message -injection) subnetwork interconnection across an insecure packet network such -as the Internet. - - CIPE encrypts the data at the network level. Packets traveling between hosts -on the network are encrypted. The encryption engine is placed near the driver -which sends and receives packets. - - This is unlike SSH, which encrypts the data by connection, at the socket -level. A logical connection between programs running on different hosts is -encrypted. - - CIPE can be used in tunnelling, in order to create a Virtual Private -Network. Low-level encryption has the advantage that it can be made to work -transparently between the two networks connected in the VPN, without any -change to application software. - - Summarized from the CIPE documentation: - - "The IPSEC standards define a set of protocols which can be used (among -other things) to build encrypted VPNs. However, IPSEC is a rather heavyweight -and complicated protocol set with a lot of options, implementations of the -full protocol set are still rarely used and some issues (such as key -management) are still not fully resolved. CIPE uses a simpler approach, in -which many things which can be parameterized (such as the choice of the -actual encryption algorithm used) are an install-time fixed choice. This -limits flexibility, but allows for a simple (and therefore efficient, easy to -debug...) implementation." - - Further information can be found at [http://www.inka.de/~bigred/devel/ -cipe.html] http://www.inka.de/~bigred/devel/cipe.html - - As with other forms of cryptography, it is not distributed with the kernel -by default due to export restrictions. ------------------------------------------------------------------------------ - -6.7. Kerberos - - Kerberos is an authentication system developed by the Athena Project at MIT. -When a user logs in, Kerberos authenticates that user (using a password), and -provides the user with a way to prove her identity to other servers and hosts -scattered around the network. - - This authentication is then used by programs such as rlogin to allow the -user to login to other hosts without a password (in place of the .rhosts -file). This authentication method can also used by the mail system in order -to guarantee that mail is delivered to the correct person, as well as to -guarantee that the sender is who he claims to be. - - Kerberos and the other programs that come with it, prevent users from -"spoofing" the system into believing they are someone else. Unfortunately, -installing Kerberos is very intrusive, requiring the modification or -replacement of numerous standard programs. - - You can find more information about kerberos by looking at [http:// -www.cis.ohio-state.edu/hypertext/faq/usenet/kerberos-faq/general/faq.html] -the kerberos FAQ, and the code can be found at [http://nii.isi.edu/info/ -kerberos/] http://nii.isi.edu/info/kerberos/. - - [From: Stein, Jennifer G., Clifford Neuman, and Jeffrey L. Schiller. -"Kerberos: An Authentication Service for Open Network Systems." USENIX -Conference Proceedings, Dallas, Texas, Winter 1998.] - - Kerberos should not be your first step in improving security of your host. -It is quite involved, and not as widely used as, say, SSH. ------------------------------------------------------------------------------ - -6.8. Shadow Passwords. - - Shadow passwords are a means of keeping your encrypted password information -secret from normal users. Recent versions of both Red Hat and Debian Linux -use shadow passwords by default, but on other systems, encrypted passwords -are stored in /etc/passwd file for all to read. Anyone can then run -password-guesser programs on them and attempt to determine what they are. -Shadow passwords, by contrast, are saved in /etc/shadow, which only -privileged users can read. In order to use shadow passwords, you need to make -sure all your utilities that need access to password information are -recompiled to support them. PAM (above) also allows you to just plug in a -shadow module; it doesn't require re-compilation of executables. You can -refer to the Shadow-Password HOWTO for further information if necessary. It -is available at [http://metalab.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html] -http://metalab.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html It is rather -dated now, and will not be required for distributions supporting PAM. ------------------------------------------------------------------------------ - -6.9. "Crack" and "John the Ripper" - - If for some reason your passwd program is not enforcing hard-to-guess -passwords, you might want to run a password-cracking program and make sure -your users' passwords are secure. - - Password cracking programs work on a simple idea: they try every word in the -dictionary, and then variations on those words, encrypting each one and -checking it against your encrypted password. If they get a match they know -what your password is. - - There are a number of programs out there...the two most notable of which are -"Crack" and "John the Ripper" ([http://www.openwall.com/john/] http:// -www.openwall.com/john/) . They will take up a lot of your CPU time, but you -should be able to tell if an attacker could get in using them by running them -first yourself and notifying users with weak passwords. Note that an attacker -would have to use some other hole first in order to read your /etc/passwd -file, but such holes are more common than you might think. - - Because security is only as strong as the most insecure host, it is worth -mentioning that if you have any Windows machines on your network, you should -check out L0phtCrack, a Crack implementation for Windows. It's available from -[http://www.l0pht.com] http://www.l0pht.com ------------------------------------------------------------------------------ - -6.10. CFS - Cryptographic File System and TCFS - Transparent Cryptographic -File System - - CFS is a way of encrypting entire directory trees and allowing users to -store encrypted files on them. It uses an NFS server running on the local -machine. RPMS are available at [http://www.zedz.net/redhat/] http:// -www.zedz.net/redhat/, and more information on how it all works is at [ftp:// -ftp.research.att.com/dist/mab/] ftp://ftp.research.att.com/dist/mab/. - - TCFS improves on CFS by adding more integration with the file system, so -that it's transparent to users that the file system that is encrypted. More -information at: [http://www.tcfs.it/] http://www.tcfs.it/. - - It also need not be used on entire file systems. It works on directory trees -as well. ------------------------------------------------------------------------------ - -6.11. X11, SVGA and display security - -6.11.1. X11 - - It's important for you to secure your graphical display to prevent attackers -from grabbing your passwords as you type them, reading documents or -information you are reading on your screen, or even using a hole to gain root -access. Running remote X applications over a network also can be fraught with -peril, allowing sniffers to see all your interaction with the remote system. - - X has a number of access-control mechanisms. The simplest of them is -host-based: you use xhost to specify the hosts that are allowed access to -your display. This is not very secure at all, because if someone has access -to your machine, they can xhost + their machine and get in easily. Also, if -you have to allow access from an untrusted machine, anyone there can -compromise your display. - - When using xdm (X Display Manager) to log in, you get a much better access -method: MIT-MAGIC-COOKIE-1. A 128-bit "cookie" is generated and stored in -your .Xauthority file. If you need to allow a remote machine access to your -display, you can use the xauth command and the information in your -.Xauthority file to provide access to only that connection. See the -Remote-X-Apps mini-howto, available at [http://metalab.unc.edu/LDP/HOWTO/mini -/Remote-X-Apps.html] http://metalab.unc.edu/LDP/HOWTO/mini/ -Remote-X-Apps.html. - - You can also use ssh (see Section 6.4, above) to allow secure X connections. -This has the advantage of also being transparent to the end user, and means -that no unencrypted data flows across the network. - - You can also disable any remote connections to your X server by using the -'-nolisten tcp' options to your X server. This will prevent any network -connections to your server over tcp sockets. - - Take a look at the Xsecurity man page for more information on X security. -The safe bet is to use xdm to login to your console and then use ssh to go to -remote sites on which you wish to run X programs. ------------------------------------------------------------------------------ - -6.11.2. SVGA - - SVGAlib programs are typically SUID-root in order to access all your Linux -machine's video hardware. This makes them very dangerous. If they crash, you -typically need to reboot your machine to get a usable console back. Make sure -any SVGA programs you are running are authentic, and can at least be somewhat -trusted. Even better, don't run them at all. ------------------------------------------------------------------------------ - -6.11.3. GGI (Generic Graphics Interface project) - - The Linux GGI project is trying to solve several of the problems with video -interfaces on Linux. GGI will move a small piece of the video code into the -Linux kernel, and then control access to the video system. This means GGI -will be able to restore your console at any time to a known good state. They -will also allow a secure attention key, so you can be sure that there is no -Trojan horse login program running on your console. [http:// -synergy.caltech.edu/~ggi/] http://synergy.caltech.edu/~ggi/ ------------------------------------------------------------------------------ - -7. Kernel Security - - This is a description of the kernel configuration options that relate to -security, and an explanation of what they do, and how to use them. - - As the kernel controls your computer's networking, it is important that it -be very secure, and not be compromised. To prevent some of the latest -networking attacks, you should try to keep your kernel version current. You -can find new kernels at [ftp://ftp.kernel.org] ?? or from your distribution -vendor. - - There is also a international group providing a single unified crypto patch -to the mainstream Linux kernel. This patch provides support for a number of -cryptographic subsystems and things that cannot be included in the mainstream -kernel due to export restrictions. For more information, visit their web page -at: [http://www.kerneli.org] http://www.kerneli.org ------------------------------------------------------------------------------ - -7.1. 2.0 Kernel Compile Options - - For 2.0.x kernels, the following options apply. You should see these options -during the kernel configuration process. Many of the comments here are from . -/linux/Documentation/Configure.help, which is the same document that is -referenced while using the Help facility during the make config stage of -compiling the kernel. - - - -  *  Network Firewalls (CONFIG_FIREWALL) - - This option should be on if you intend to run any firewalling or - masquerading on your Linux machine. If it's just going to be a regular - client machine, it's safe to say no. - -  *  IP: forwarding/gatewaying (CONFIG_IP_FORWARD) - - If you enable IP forwarding, your Linux box essentially becomes a - router. If your machine is on a network, you could be forwarding data - from one network to another, and perhaps subverting a firewall that was - put there to prevent this from happening. Normal dial-up users will want - to disable this, and other users should concentrate on the security - implications of doing this. Firewall machines will want this enabled, and - used in conjunction with firewall software. - - You can enable IP forwarding dynamically using the following command: - - - root# echo 1 > /proc/sys/net/ipv4/ip_forward - and disable it with the command: - root# echo 0 > /proc/sys/net/ipv4/ip_forward - Keep in mind the files in /proc are "virtual" files and the shown size of - the file might not reflect the data output from it. - -  *  IP: syn cookies (CONFIG_SYN_COOKIES) - - a "SYN Attack" is a denial of service (DoS) attack that consumes all the - resources on your machine, forcing you to reboot. We can't think of a - reason you wouldn't normally enable this. In the 2.2.x kernel series this - config option merely allows syn cookies, but does not enable them. To - enable them, you have to do: - - - root# echo 1 > /proc/sys/net/ipv4/tcp_syncookies

- -  *  IP: Firewalling (CONFIG_IP_FIREWALL) - - This option is necessary if you are going to configure your machine as a - firewall, do masquerading, or wish to protect your dial-up workstation - from someone entering via your PPP dial-up interface. - -  *  IP: firewall packet logging (CONFIG_IP_FIREWALL_VERBOSE) - - This option gives you information about packets your firewall received, - like sender, recipient, port, etc. - -  *  IP: Drop source routed frames (CONFIG_IP_NOSR) - - This option should be enabled. Source routed frames contain the entire - path to their destination inside of the packet. This means that routers - through which the packet goes do not need to inspect it, and just forward - it on. This could lead to data entering your system that may be a - potential exploit. - -  *  IP: masquerading (CONFIG_IP_MASQUERADE) If one of the computers on your - local network for which your Linux box acts as a firewall wants to send - something to the outside, your box can "masquerade" as that host, i.e., - it forewords the traffic to the intended destination, but makes it look - like it came from the firewall box itself. See [http://www.indyramp.com/ - masq] http://www.indyramp.com/masq for more information. - -  *  IP: ICMP masquerading (CONFIG_IP_MASQUERADE_ICMP) This option adds ICMP - masquerading to the previous option of only masquerading TCP or UDP - traffic. - -  *  IP: transparent proxy support (CONFIG_IP_TRANSPARENT_PROXY) This enables - your Linux firewall to transparently redirect any network traffic - originating from the local network and destined for a remote host to a - local server, called a "transparent proxy server". This makes the local - computers think they are talking to the remote end, while in fact they - are connected to the local proxy. See the IP-Masquerading HOWTO and - [http://www.indyramp.com/masq] http://www.indyramp.com/masq for more - information. - -  *  IP: always defragment (CONFIG_IP_ALWAYS_DEFRAG) - - Generally this option is disabled, but if you are building a firewall or - a masquerading host, you will want to enable it. When data is sent from - one host to another, it does not always get sent as a single packet of - data, but rather it is fragmented into several pieces. The problem with - this is that the port numbers are only stored in the first fragment. This - means that someone can insert information into the remaining packets that - isn't supposed to be there. It could also prevent a teardrop attack - against an internal host that is not yet itself patched against it. - -  *  Packet Signatures (CONFIG_NCPFS_PACKET_SIGNING) - - This is an option that is available in the 2.2.x kernel series that will - sign NCP packets for stronger security. Normally you can leave it off, - but it is there if you do need it. - -  *  IP: Firewall packet netlink device (CONFIG_IP_FIREWALL_NETLINK) - - This is a really neat option that allows you to analyze the first 128 - bytes of the packets in a user-space program, to determine if you would - like to accept or deny the packet, based on its validity. - - ------------------------------------------------------------------------------ -7.2. 2.2 Kernel Compile Options - - For 2.2.x kernels, many of the options are the same, but a few new ones have -been developed. Many of the comments here are from ./linux/Documentation/ -Configure.help, which is the same document that is referenced while using the -Help facility during the make config stage of compiling the kernel. Only the -newly- added options are listed below. Consult the 2.0 description for a list -of other necessary options. The most significant change in the 2.2 kernel -series is the IP firewalling code. The ipchains program is now used to -install IP firewalling, instead of the ipfwadm program used in the 2.0 -kernel. - - - -  *  Socket Filtering (CONFIG_FILTER) - - For most people, it's safe to say no to this option. This option allows - you to connect a user-space filter to any socket and determine if packets - should be allowed or denied. Unless you have a very specific need and are - capable of programming such a filter, you should say no. Also note that - as of this writing, all protocols were supported except TCP. - -  *  Port Forwarding - - Port Forwarding is an addition to IP Masquerading which allows some - forwarding of packets from outside to inside a firewall on given ports. - This could be useful if, for example, you want to run a web server behind - the firewall or masquerading host and that web server should be - accessible from the outside world. An external client sends a request to - port 80 of the firewall, the firewall forwards this request to the web - server, the web server handles the request and the results are sent - through the firewall to the original client. The client thinks that the - firewall machine itself is running the web server. This can also be used - for load balancing if you have a farm of identical web servers behind the - firewall. - - Information about this feature is available from http:// - www.monmouth.demon.co.uk/ipsubs/portforwarding.html (to browse the WWW, - you need to have access to a machine on the Internet that has a program - like lynx or Netscape). For general info, please see ftp:// - ftp.compsoc.net/users/steve/ipportfw/linux21/ - -  *  Socket Filtering (CONFIG_FILTER) - - Using this option, user-space programs can attach a filter to any socket - and thereby tell the kernel that it should allow or disallow certain - types of data to get through the socket. Linux socket filtering works on - all socket types except TCP for now. See the text file ./linux/ - Documentation/networking/filter.txt for more information. - -  *  IP: Masquerading - - The 2.2 kernel masquerading has been improved. It provides additional - support for masquerading special protocols, etc. Be sure to read the IP - Chains HOWTO for more information. - - ------------------------------------------------------------------------------ -7.3. Kernel Devices - - There are a few block and character devices available on Linux that will -also help you with security. - - The two devices /dev/random and /dev/urandom are provided by the kernel to -provide random data at any time. - - Both /dev/random and /dev/urandom should be secure enough to use in -generating PGP keys, ssh challenges, and other applications where secure -random numbers are required. Attackers should be unable to predict the next -number given any initial sequence of numbers from these sources. There has -been a lot of effort put in to ensuring that the numbers you get from these -sources are random in every sense of the word. - - The only difference between the two devices, is that /dev/random runs out of -random bytes and it makes you wait for more to be accumulated. Note that on -some systems, it can block for a long time waiting for new user-generated -entropy to be entered into the system. So you have to use care before using / -dev/random. (Perhaps the best thing to do is to use it when you're generating -sensitive keying information, and you tell the user to pound on the keyboard -repeatedly until you print out "OK, enough".) - - /dev/random is high quality entropy, generated from measuring the -inter-interrupt times etc. It blocks until enough bits of random data are -available. - - /dev/urandom is similar, but when the store of entropy is running low, it'll -return a cryptographically strong hash of what there is. This isn't as -secure, but it's enough for most applications. - - You might read from the devices using something like: - - - root# head -c 6 /dev/urandom | mimencode -This will print six random characters on the console, suitable for password -generation. You can find mimencode in the metamail package. - - See /usr/src/linux/drivers/char/random.c for a description of the algorithm. - - Thanks to Theodore Y. Ts'o, Jon Lewis, and others from Linux-kernel for -helping me (Dave) with this. ------------------------------------------------------------------------------ - -8. Network Security - - Network security is becoming more and more important as people spend more -and more time connected. Compromising network security is often much easier -than compromising physical or local security, and is much more common. - - There are a number of good tools to assist with network security, and more -and more of them are shipping with Linux distributions. ------------------------------------------------------------------------------ - -8.1. Packet Sniffers - - One of the most common ways intruders gain access to more systems on your -network is by employing a packet sniffer on a already compromised host. This -"sniffer" just listens on the Ethernet port for things like passwd and login -and su in the packet stream and then logs the traffic after that. This way, -attackers gain passwords for systems they are not even attempting to break -into. Clear-text passwords are very vulnerable to this attack. - - Example: Host A has been compromised. Attacker installs a sniffer. Sniffer -picks up admin logging into Host B from Host C. It gets the admins personal -password as they login to B. Then, the admin does a su to fix a problem. They -now have the root password for Host B. Later the admin lets someone telnet -from his account to Host Z on another site. Now the attacker has a password/ -login on Host Z. - - In this day and age, the attacker doesn't even need to compromise a system -to do this: they could also bring a laptop or pc into a building and tap into -your net. - - Using ssh or other encrypted password methods thwarts this attack. Things -like APOP for POP accounts also prevents this attack. (Normal POP logins are -very vulnerable to this, as is anything that sends clear-text passwords over -the network.) ------------------------------------------------------------------------------ - -8.2. System services and tcp_wrappers - - Before you put your Linux system on ANY network the first thing to look at -is what services you need to offer. Services that you do not need to offer -should be disabled so that you have one less thing to worry about and -attackers have one less place to look for a hole. - - There are a number of ways to disable services under Linux. You can look at -your /etc/inetd.conf file and see what services are being offered by your -inetd. Disable any that you do not need by commenting them out (# at the -beginning of the line), and then sending your inetd process a SIGHUP. - - You can also remove (or comment out) services in your /etc/services file. -This will mean that local clients will also be unable to find the service -(i.e., if you remove ftp, and try and ftp to a remote site from that machine -it will fail with an "unknown service" message). It's usually not worth the -trouble to remove services from /etc/services, since it provides no -additional security. If a local person wanted to use ftp even though you had -commented it out, they would make their own client that used the common FTP -port and would still work fine. - - Some of the services you might want to leave enabled are: - - - -  *  ftp - -  *  telnet (or ssh) - -  *  mail, such as pop-3 or imap - -  *  identd - - - If you know you are not going to use some particular package, you can also -delete it entirely. rpm -e packagename under the Red Hat distribution will -erase an entire package. Under Debian dpkg --remove does the same thing. - - Additionally, you really want to disable the rsh/rlogin/rcp utilities, -including login (used by rlogin), shell (used by rcp), and exec (used by rsh) -from being started in /etc/inetd.conf. These protocols are extremely insecure -and have been the cause of exploits in the past. - - You should check /etc/rc.d/rc[0-9].d (on Red Hat; /etc/rc[0-9].d on Debian), -and see if any of the servers started in those directories are not needed. -The files in those directories are actually symbolic links to files in the -directory /etc/rc.d/init.d (on Red Hat; /etc/init.d on Debian). Renaming the -files in the init.d directory disables all the symbolic links that point to -that file. If you only wish to disable a service for a particular run level, -rename the appropriate symbolic link by replacing the upper-case S with a -lower-case s, like this: - - - root# cd /etc/rc6.d - root# mv S45dhcpd s45dhcpd - - If you have BSD-style rc files, you will want to check /etc/rc* for programs -you don't need. - - Most Linux distributions ship with tcp_wrappers "wrapping" all your TCP -services. A tcp_wrapper (tcpd) is invoked from inetd instead of the real -server. tcpd then checks the host that is requesting the service, and either -executes the real server, or denies access from that host. tcpd allows you to -restrict access to your TCP services. You should make a /etc/hosts.allow and -add in only those hosts that need to have access to your machine's services. - - If you are a home dial up user, we suggest you deny ALL. tcpd also logs -failed attempts to access services, so this can alert you if you are under -attack. If you add new services, you should be sure to configure them to use -tcp_wrappers if they are TCP-based. For example, a normal dial-up user can -prevent outsiders from connecting to his machine, yet still have the ability -to retrieve mail, and make network connections to the Internet. To do this, -you might add the following to your /etc/hosts.allow: - - ALL: 127. - - And of course /etc/hosts.deny would contain: - - ALL: ALL - - which will prevent external connections to your machine, yet still allow you -from the inside to connect to servers on the Internet. - - Keep in mind that tcp_wrappers only protects services executed from inetd, -and a select few others. There very well may be other services running on -your machine. You can use netstat -ta to find a list of all the services your -machine is offering. ------------------------------------------------------------------------------ - -8.3. Verify Your DNS Information - - Keeping up-to-date DNS information about all hosts on your network can help -to increase security. If an unauthorized host becomes connected to your -network, you can recognize it by its lack of a DNS entry. Many services can -be configured to not accept connections from hosts that do not have valid DNS -entries. ------------------------------------------------------------------------------ - -8.4. identd - - identd is a small program that typically runs out of your inetd server. It -keeps track of what user is running what TCP service, and then reports this -to whoever requests it. - - Many people misunderstand the usefulness of identd, and so disable it or -block all off site requests for it. identd is not there to help out remote -sites. There is no way of knowing if the data you get from the remote identd -is correct or not. There is no authentication in identd requests. - - Why would you want to run it then? Because it helps you out, and is another -data-point in tracking. If your identd is un compromised, then you know it's -telling remote sites the user-name or uid of people using TCP services. If -the admin at a remote site comes back to you and tells you user so-and-so was -trying to hack into their site, you can easily take action against that user. -If you are not running identd, you will have to look at lots and lots of -logs, figure out who was on at the time, and in general take a lot more time -to track down the user. - - The identd that ships with most distributions is more configurable than many -people think. You can disable it for specific users (they can make a .noident -file), you can log all identd requests (We recommend it), you can even have -identd return a uid instead of a user name or even NO-USER. ------------------------------------------------------------------------------ - -8.5. Configuring and Securing the Postfix MTA - - The Postfix mail server was written by Wietse Venema, author of Postfix and -several other staple Internet security products, as an "attempt to provide an -alternative to the widely-used Sendmail program. Postfix attempts to be fast, -easy to administer, and hopefully secure, while at the same time being -sendmail compatible enough to not upset your users." - - Further information on postfix can be found at the [http://www.postfix.org] -Postfix home and in the [http://www.linuxsecurity.com/feature_stories/ -feature_story-91.html] Configuring and Securing Postfix. ------------------------------------------------------------------------------ - -8.6. SATAN, ISS, and Other Network Scanners - - There are a number of different software packages out there that do port and -service-based scanning of machines or networks. SATAN, ISS, SAINT, and Nessus -are some of the more well-known ones. This software connects to the target -machine (or all the target machines on a network) on all the ports they can, -and try to determine what service is running there. Based on this -information, you can tell if the machine is vulnerable to a specific exploit -on that server. - - SATAN (Security Administrator's Tool for Analyzing Networks) is a port -scanner with a web interface. It can be configured to do light, medium, or -strong checks on a machine or a network of machines. It's a good idea to get -SATAN and scan your machine or network, and fix the problems it finds. Make -sure you get the copy of SATAN from [http://metalab.unc.edu/pub/packages/ -security/Satan-for-Linux/] metalab or a reputable FTP or web site. There was -a Trojan copy of SATAN that was distributed out on the net. [http:// -www.trouble.org/~zen/satan/satan.html] http://www.trouble.org/~zen/satan/ -satan.html. Note that SATAN has not been updated in quite a while, and some -of the other tools below might do a better job. - - ISS (Internet Security Scanner) is another port-based scanner. It is faster -than Satan, and thus might be better for large networks. However, SATAN tends -to provide more information. - - Abacus is a suite of tools to provide host-based security and intrusion -detection. Look at it's home page on the web for more information. [http:// -www.psionic.com/abacus] http://www.psionic.com/abacus/ - - SAINT is a updated version of SATAN. It is web-based and has many more -up-to-date tests than SATAN. You can find out more about it at: [http:// -www.wwdsi.com/saint] http://www.wwdsi.com/~saint - - Nessus is a free security scanner. It has a GTK graphical interface for ease -of use. It is also designed with a very nice plug in setup for new -port-scanning tests. For more information, take a look at: [http:// -www.nessus.org/] http://www.nessus.org ------------------------------------------------------------------------------ - -8.6.1. Detecting Port Scans - - There are some tools designed to alert you to probes by SATAN and ISS and -other scanning software. However, if you liberally use tcp_wrappers, and look -over your log files regularly, you should be able to notice such probes. Even -on the lowest setting, SATAN still leaves traces in the logs on a stock Red -Hat system. - - There are also "stealth" port scanners. A packet with the TCP ACK bit set -(as is done with established connections) will likely get through a -packet-filtering firewall. The returned RST packet from a port that _had no -established session_ can be taken as proof of life on that port. I don't -think TCP wrappers will detect this. - - You might also look at SNORT, which is a free IDS (Intrusion Detection -System), which can detect other network intrusions. [http://www.snort.org] -http://www.snort.org ------------------------------------------------------------------------------ - -8.7. sendmail, qmail and MTA's - - One of the most important services you can provide is a mail server. -Unfortunately, it is also one of the most vulnerable to attack, simply due to -the number of tasks it must perform and the privileges it typically needs. - - If you are using sendmail it is very important to keep up on current -versions. sendmail has a long long history of security exploits. Always make -sure you are running the most recent version from [http://www.sendmail.org/] -http://www.sendmail.org. - - Keep in mind that sendmail does not have to be running in order for you to -send mail. If you are a home user, you can disable sendmail entirely, and -simply use your mail client to send mail. You might also choose to remove the -"-bd" flag from the sendmail startup file, thereby disabling incoming -requests for mail. In other words, you can execute sendmail from your startup -script using the following instead: - # /usr/lib/sendmail -q15m -This will cause sendmail to flush the mail queue every fifteen minutes for -any messages that could not be successfully delivered on the first attempt. - - Many administrators choose not to use sendmail, and instead choose one of -the other mail transport agents. You might consider switching over to qmail. -qmail was designed with security in mind from the ground up. It's fast, -stable, and secure. Qmail can be found at [http://www.qmail.org] http:// -www.qmail.org - - In direct competition to qmail is "postfix", written by Wietse Venema, the -author of tcp_wrappers and other security tools. Formerly called vmailer, and -sponsored by IBM, this is also a mail transport agent written from the ground -up with security in mind. You can find more information about postfix at -[http:/www.postfix.org] http://www.postfix.org ------------------------------------------------------------------------------ - -8.8. Denial of Service Attacks - - A "Denial of Service" (DoS) attack is one where the attacker tries to make -some resource too busy to answer legitimate requests, or to deny legitimate -users access to your machine. - - Denial of service attacks have increased greatly in recent years. Some of -the more popular and recent ones are listed below. Note that new ones show up -all the time, so this is just a few examples. Read the Linux security lists -and the bugtraq list and archives for more current information. - - - -  *  SYN Flooding - SYN flooding is a network denial of service attack. It - takes advantage of a "loophole" in the way TCP connections are created. - The newer Linux kernels (2.0.30 and up) have several configurable options - to prevent SYN flood attacks from denying people access to your machine - or services. See Section 7 for proper kernel protection options. - -  *  Pentium "F00F" Bug - It was recently discovered that a series of - assembly codes sent to a genuine Intel Pentium processor would reboot the - machine. This affects every machine with a Pentium processor (not clones, - not Pentium Pro or PII), no matter what operating system it's running. - Linux kernels 2.0.32 and up contain a work around for this bug, - preventing it from locking your machine. Kernel 2.0.33 has an improved - version of the kernel fix, and is suggested over 2.0.32. If you are - running on a Pentium, you should upgrade now! - -  *  Ping Flooding - Ping flooding is a simple brute-force denial of service - attack. The attacker sends a "flood" of ICMP packets to your machine. If - they are doing this from a host with better bandwidth than yours, your - machine will be unable to send anything on the network. A variation on - this attack, called "smurfing", sends ICMP packets to a host with your - machine's return IP, allowing them to flood you less detectably. You can - find more information about the "smurf" attack at [http:// - www.quadrunner.com/~chuegen/smurf.txt] http://www.quadrunner.com/~chuegen - /smurf.txt - - If you are ever under a ping flood attack, use a tool like tcpdump to - determine where the packets are coming from (or appear to be coming - from), then contact your provider with this information. Ping floods can - most easily be stopped at the router level or by using a firewall. - -  *  Ping o' Death - The Ping o' Death attack sends ICMP ECHO REQUEST packets - that are too large to fit in the kernel data structures intended to store - them. Because sending a single, large (65,510 bytes) "ping" packet to - many systems will cause them to hang or even crash, this problem was - quickly dubbed the "Ping o' Death." This one has long been fixed, and is - no longer anything to worry about. - -  *  Teardrop / New Tear - One of the most recent exploits involves a bug - present in the IP fragmentation code on Linux and Windows platforms. It - is fixed in kernel version 2.0.33, and does not require selecting any - kernel compile-time options to utilize the fix. Linux is apparently not - vulnerable to the "newtear" exploit. - - -You can find code for most exploits, and a more in-depth description of how -they work, at [http://www.rootshell.com] http://www.rootshell.com using their -search engine. ------------------------------------------------------------------------------ - -8.9. NFS (Network File System) Security. - - NFS is a very widely-used file sharing protocol. It allows servers running -nfsd and mountd to "export" entire file systems to other machines using NFS -filesystem support built in to their kernels (or some other client support if -they are not Linux machines). mountd keeps track of mounted file systems in / -etc/mtab, and can display them with showmount. - - Many sites use NFS to serve home directories to users, so that no matter -what machine in the cluster they login to, they will have all their home -files. - - There is some small amount of security allowed in exporting file systems. -You can make your nfsd map the remote root user (uid=0) to the nobody user, -denying them total access to the files exported. However, since individual -users have access to their own (or at least the same uid) files, the remote -root user can login or su to their account and have total access to their -files. This is only a small hindrance to an attacker that has access to mount -your remote file systems. - - If you must use NFS, make sure you export to only those machines that you -really need to. Never export your entire root directory; export only -directories you need to export. - - See the NFS HOWTO for more information on NFS, available at [http:// -metalab.unc.edu/mdw/HOWTO/NFS-HOWTO.html] http://metalab.unc.edu/mdw/HOWTO/ -NFS-HOWTO.html ------------------------------------------------------------------------------ - -8.10. NIS (Network Information Service) (formerly YP). - - Network Information service (formerly YP) is a means of distributing -information to a group of machines. The NIS master holds the information -tables and converts them into NIS map files. These maps are then served over -the network, allowing NIS client machines to get login, password, home -directory and shell information (all the information in a standard /etc/ -passwd file). This allows users to change their password once and have it -take effect on all the machines in the NIS domain. - - NIS is not at all secure. It was never meant to be. It was meant to be handy -and useful. Anyone that can guess the name of your NIS domain (anywhere on -the net) can get a copy of your passwd file, and use "crack" and "John the -Ripper" against your users' passwords. Also, it is possible to spoof NIS and -do all sorts of nasty tricks. If you must use NIS, make sure you are aware of -the dangers. - - There is a much more secure replacement for NIS, called NIS+. Check out the -NIS HOWTO for more information: [http://metalab.unc.edu/mdw/HOWTO/ -NIS-HOWTO.html] http://metalab.unc.edu/mdw/HOWTO/NIS-HOWTO.html ------------------------------------------------------------------------------ - -8.11. Firewalls - - Firewalls are a means of controlling what information is allowed into and -out of your local network. Typically the firewall host is connected to the -Internet and your local LAN, and the only access from your LAN to the -Internet is through the firewall. This way the firewall can control what -passes back and forth from the Internet and your LAN. - - There are a number of types of firewalls and methods of setting them up. -Linux machines make pretty good firewalls. Firewall code can be built right -into 2.0 and higher kernels. The user-space tools ipfwadm for 2.0 kernels and -ipchains for 2.2 kernels, allows you to change, on the fly, the types of -network traffic you allow. You can also log particular types of network -traffic. - - Firewalls are a very useful and important technique in securing your -network. However, never think that because you have a firewall, you don't -need to secure the machines behind it. This is a fatal mistake. Check out the -very good Firewall-HOWTO at your latest metalab archive for more information -on firewalls and Linux. [http://metalab.unc.edu/mdw/HOWTO/ -Firewall-HOWTO.html] http://metalab.unc.edu/mdw/HOWTO/Firewall-HOWTO.html - - More information can also be found in the IP-Masquerade mini-howto: [http:// -metalab.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html] http://metalab.unc.edu/mdw -/HOWTO/mini/IP-Masquerade.html - - More information on ipfwadm (the tool that lets you change settings on your -firewall, can be found at it's home page: [http://www.xos.nl/linux/ipfwadm/] -http://www.xos.nl/linux/ipfwadm/ - - If you have no experience with firewalls, and plan to set up one for more -than just a simple security policy, the Firewalls book by O'Reilly and -Associates or other online firewall document is mandatory reading. Check out -[http://www.ora.com] http://www.ora.com for more information. The National -Institute of Standards and Technology have put together an excellent document -on firewalls. Although dated 1995, it is still quite good. You can find it at -[http://csrc.nist.gov/nistpubs/800-10/main.html] http://csrc.nist.gov/ -nistpubs/800-10/main.html. Also of interest: - - - -  *  The Freefire Project -- a list of freely-available firewall tools, - available at [http://sites.inka.de/sites/lina/freefire-l/index_en.html] - http://sites.inka.de/sites/lina/freefire-l/index_en.html - -  *  SunWorld Firewall Design -- written by the authors of the O'Reilly - book, this provides a rough introduction to the different firewall types. - It's available at [http://www.sunworld.com/swol-01-1996/ - swol-01-firewall.html] http://www.sunworld.com/swol-01-1996/ - swol-01-firewall.html - -  *  Mason - the automated firewall builder for Linux. This is a firewall - script that learns as you do the things you need to do on your network! - More info at: [http://www.pobox.com/~wstearns/mason/] http:// - www.pobox.com/~wstearns/mason/ - - ------------------------------------------------------------------------------ -8.12. IP Chains - Linux Kernel 2.2.x Firewalling - - Linux IP Firewalling Chains is an update to the 2.0 Linux firewalling code -for the 2.2 kernel. It has many more features than previous implementations, -including: - -  *  More flexible packet manipulations - -  *  More complex accounting - -  *  Simple policy changes possible atomically - -  *  Fragments can be explicitly blocked, denied, etc. - -  *  Logs suspicious packets. - -  *  Can handle protocols other than ICMP/TCP/UDP. - - - If you are currently using ipfwadm on your 2.0 kernel, there are scripts -available to convert the ipfwadm command format to the format ipchains uses. - - Be sure to read the IP Chains HOWTO for further information. It is available -at [http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html] http:// -www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html ------------------------------------------------------------------------------ - -8.13. Netfilter - Linux Kernel 2.4.x Firewalling - - In yet another set of advancements to the kernel IP packet filtering code, -netfilter allows users to set up, maintain, and inspect the packet filtering -rules in the new 2.4 kernel. - - The netfilter subsystem is a complete rewrite of previous packet filtering -implementations including ipchains and ipfwadm. Netfilter provides a large -number of improvements, and it has now become an even more mature and robust -solution for protecting corporate networks. - - -iptables -is the command-line interface used to manipulate the firewall tables within -the kernel. - - Netfilter provides a raw framework for manipulating packets as they traverse -through various parts of the kernel. Part of this framework includes support -for masquerading, standard packet filtering, and now more complete network -address translation. It even includes improved support for load balancing -requests for a particular service among a group of servers behind the -firewall. - - The stateful inspection features are especially powerful. Stateful -inspection provides the ability to track and control the flow of -communication passing through the filter. The ability to keep track of state -and context information about a session makes rules simpler and tries to -interpret higher-level protocols. - - Additionally, small modules can be developed to perform additional specific -functions, such as passing packets to programs in userspace for processing -then reinjecting back into the normal packet flow. The ability to develop -these programs in userspace reduces the level of complexity that was -previously associated with having to make changes directly at the kernel -level. - - Other IP Tables references include: - - - -  *  [http://www.linuxsecurity.com/feature_stories/feature_story-94.html] - Oskar Andreasson IP Tables Tutorial -- Oskar Andreasson speaks with - LinuxSecurity.com about his comprehensive IP Tables tutorial and how this - document can be used to build a robust firewall for your organization. - -  *  [http://www.linuxsecurity.com/feature_stories/feature_story-93.html] Hal - Burgiss Introduces Linux Security Quick-Start Guides -- Hal Burgiss has - written two authoritative guides on securing Linux, including managing - firewalling. - -  *  [http://netfilter.samba.org] Netfilter Homepage -- The netfilter/ - iptables homepage. - -  *  [http://www.linuxsecurity.com/feature_stories/kernel-netfilter.html] - Linux Kernel 2.4 Firewalling Matures: netfilter -- This LinuxSecurity.com - article describes the basics of packet filtering, how to get started - using iptables, and a list of the new features available in the latest - generation of firewalling for Linux. - - ------------------------------------------------------------------------------ -8.14. VPNs - Virtual Private Networks - - VPN's are a way to establish a "virtual" network on top of some -already-existing network. This virtual network often is encrypted and passes -traffic only to and from some known entities that have joined the network. -VPNs are often used to connect someone working at home over the public -Internet to an internal company network. - - If you are running a Linux masquerading firewall and need to pass MS PPTP -(Microsoft's VPN point-to-point product) packets, there is a Linux kernel -patch out to do just that. See: [ftp://ftp.rubyriver.com/pub/jhardin/ -masquerade/ip_masq_vpn.html] ip-masq-vpn. - - There are several Linux VPN solutions available: - -  *  vpnd. See the [http://sunsite.dk/vpnd/] http://sunsite.dk/vpnd/. - -  *  Free S/Wan, available at [http://www.xs4all.nl/~freeswan/] http:// - www.xs4all.nl/~freeswan/ - -  *  ssh can be used to construct a VPN. See the VPN mini-howto for more - information. - -  *  vps (virtual private server) at [http://www.strongcrypto.com] http:// - www.strongcrypto.com. - -  *  yawipin at [mailto:http://yavipin.sourceforge.net] http:// - yavipin.sourceforge.net - - - See also the section on IPSEC for pointers and more information. ------------------------------------------------------------------------------ - -9. Security Preparation (before you go on-line) - - Ok, so you have checked over your system, and determined it's as secure as -feasible, and you're ready to put it online. There are a few things you -should now do in order to prepare for an intrusion, so you can quickly -disable the intruder, and get back up and running. ------------------------------------------------------------------------------ - -9.1. Make a Full Backup of Your Machine - - Discussion of backup methods and storage is beyond the scope of this -document, but here are a few words relating to backups and security: - - If you have less than 650mb of data to store on a partition, a CD-R copy of -your data is a good way to go (as it's hard to tamper with later, and if -stored properly can last a long time), you will of course need at least 650MB -of space to make the image. Tapes and other re-writable media should be -write-protected as soon as your backup is complete, and then verified to -prevent tampering. Make sure you store your backups in a secure off-line -area. A good backup will ensure that you have a known good point to restore -your system from. ------------------------------------------------------------------------------ - -9.2. Choosing a Good Backup Schedule - - A six-tape cycle is easy to maintain. This includes four tapes for during -the week, one tape for even Fridays, and one tape for odd Fridays. Perform an -incremental backup every day, and a full backup on the appropriate Friday -tape. If you make some particularly important changes or add some important -data to your system, a full backup might well be in order. ------------------------------------------------------------------------------ - -9.3. Testing your backups - - You should do periodic tests of your backups to make sure they are working -as you might expect them to. Restores of files and checking against the real -data, sizes and listings of backups, and reading old backups should be done -on a regular basis. ------------------------------------------------------------------------------ - -9.4. Backup Your RPM or Debian File Database - - In the event of an intrusion, you can use your RPM database like you would -use tripwire, but only if you can be sure it too hasn't been modified. You -should copy the RPM database to a floppy, and keep this copy off-line at all -times. The Debian distribution likely has something similar. - - The files /var/lib/rpm/fileindex.rpm and /var/lib/rpm/packages.rpm most -likely won't fit on a single floppy. But if compressed, each should fit on a -seperate floppy. - - Now, when your system is compromised, you can use the command: - - - root# rpm -Va -to verify each file on the system. See the rpm man page, as there are a few -other options that can be included to make it less verbose. Keep in mind you -must also be sure your RPM binary has not been compromised. - - This means that every time a new RPM is added to the system, the RPM -database will need to be rearchived. You will have to decide the advantages -versus drawbacks. ------------------------------------------------------------------------------ - -9.5. Keep Track of Your System Accounting Data - - It is very important that the information that comes from syslog not be -compromised. Making the files in /var/log readable and writable by only a -limited number of users is a good start. - - Be sure to keep an eye on what gets written there, especially under the auth -facility. Multiple login failures, for example, can indicate an attempted -break-in. - - Where to look for your log file will depend on your distribution. In a Linux -system that conforms to the "Linux Filesystem Standard", such as Red Hat, you -will want to look in /var/log and check messages, mail.log, and others. - - You can find out where your distribution is logging to by looking at your / -etc/syslog.conf file. This is the file that tells syslogd (the system logging -daemon) where to log various messages. - - You might also want to configure your log-rotating script or daemon to keep -logs around longer so you have time to examine them. Take a look at the -logrotate package on recent Red Hat distributions. Other distributions likely -have a similar process. - - If your log files have been tampered with, see if you can determine when the -tampering started, and what sort of things appeared to be tampered with. Are -there large periods of time that cannot be accounted for? Checking backup -tapes (if you have any) for untampered log files is a good idea. - - Intruders typically modify log files in order to cover their tracks, but -they should still be checked for strange happenings. You may notice the -intruder attempting to gain entrance, or exploit a program in order to obtain -the root account. You might see log entries before the intruder has time to -modify them. - - You should also be sure to separate the auth facility from other log data, -including attempts to switch users using su, login attempts, and other user -accounting information. - - If possible, configure syslog to send a copy of the most important data to a -secure system. This will prevent an intruder from covering his tracks by -deleting his login/su/ftp/etc attempts. See the syslog.conf man page, and -refer to the @ option. - - There are several more advanced syslogd programs out there. Take a look at -[http://www.core-sdi.com/ssyslog/] http://www.core-sdi.com/ssyslog/ for -Secure Syslog. Secure Syslog allows you to encrypt your syslog entries and -make sure no one has tampered with them. - - Another syslogd with more features is [http://www.balabit.hu/en/downloads/ -syslog-ng/] syslog-ng. It allows you a lot more flexibility in your logging -and also can has your remote syslog streams to prevent tampering. - - Finally, log files are much less useful when no one is reading them. Take -some time out every once in a while to look over your log files, and get a -feeling for what they look like on a normal day. Knowing this can help make -unusual things stand out. ------------------------------------------------------------------------------ - -9.6. Apply All New System Updates. - - Most Linux users install from a CD-ROM. Due to the fast-paced nature of -security fixes, new (fixed) programs are always being released. Before you -connect your machine to the network, it's a good idea to check with your -distribution's ftp site and get all the updated packages since you received -your distribution CD-ROM. Many times these packages contain important -security fixes, so it's a good idea to get them installed. ------------------------------------------------------------------------------ - -10. What To Do During and After a Breakin - - So you have followed some of the advice here (or elsewhere) and have -detected a break-in? The first thing to do is to remain calm. Hasty actions -can cause more harm than the attacker would have. ------------------------------------------------------------------------------ - -10.1. Security Compromise Underway. - - Spotting a security compromise under way can be a tense undertaking. How you -react can have large consequences. - - If the compromise you are seeing is a physical one, odds are you have -spotted someone who has broken into your home, office or lab. You should -notify your local authorities. In a lab, you might have spotted someone -trying to open a case or reboot a machine. Depending on your authority and -procedures, you might ask them to stop, or contact your local security -people. - - If you have detected a local user trying to compromise your security, the -first thing to do is confirm they are in fact who you think they are. Check -the site they are logging in from. Is it the site they normally log in from? -No? Then use a non-electronic means of getting in touch. For instance, call -them on the phone or walk over to their office/house and talk to them. If -they agree that they are on, you can ask them to explain what they were doing -or tell them to cease doing it. If they are not on, and have no idea what you -are talking about, odds are this incident requires further investigation. -Look into such incidents , and have lots of information before making any -accusations. - - If you have detected a network compromise, the first thing to do (if you are -able) is to disconnect your network. If they are connected via modem, unplug -the modem cable; if they are connected via Ethernet, unplug the Ethernet -cable. This will prevent them from doing any further damage, and they will -probably see it as a network problem rather than detection. - - If you are unable to disconnect the network (if you have a busy site, or you -do not have physical control of your machines), the next best step is to use -something like tcp_wrappers or ipfwadm to deny access from the intruder's -site. - - If you can't deny all people from the same site as the intruder, locking the -user's account will have to do. Note that locking an account is not an easy -thing. You have to keep in mind .rhosts files, FTP access, and a host of -possible backdoors. - - After you have done one of the above (disconnected the network, denied -access from their site, and/or disabled their account), you need to kill all -their user processes and log them off. - - You should monitor your site well for the next few minutes, as the attacker -will try to get back in. Perhaps using a different account, and/or from a -different network address. ------------------------------------------------------------------------------ - -10.2. Security Compromise has already happened - - So you have either detected a compromise that has already happened or you -have detected it and locked (hopefully) the offending attacker out of your -system. Now what? ------------------------------------------------------------------------------ - -10.2.1. Closing the Hole - - If you are able to determine what means the attacker used to get into your -system, you should try to close that hole. For instance, perhaps you see -several FTP entries just before the user logged in. Disable the FTP service -and check and see if there is an updated version, or if any of the lists know -of a fix. - - Check all your log files, and make a visit to your security lists and pages -and see if there are any new common exploits you can fix. You can find -Caldera security fixes at [http://www.caldera.com/tech-ref/security/] http:// -www.caldera.com/tech-ref/security/. Red Hat has not yet separated their -security fixes from bug fixes, but their distribution errata is available at -[http://www.redhat.com/errata] http://www.redhat.com/errata - - Debian now has a security mailing list and web page. See: [http:// -www.debian.org/security/] http://www.debian.org/security/ for more -information. - - It is very likely that if one vendor has released a security update, that -most other Linux vendors will as well. - - There is now a Linux security auditing project. They are methodically going -through all the user-space utilities and looking for possible security -exploits and overflows. From their announcement: - - ""We are attempting a systematic audit of Linux sources with a view to being -as secure as OpenBSD. We have already uncovered (and fixed) some problems, -but more help is welcome. The list is unmoderated and also a useful resource -for general security discussions. The list address is: -security-audit@ferret.lmh.ox.ac.uk To subscribe, send a mail to: -security-audit-subscribe@ferret.lmh.ox.ac.uk"" - - If you don't lock the attacker out, they will likely be back. Not just back -on your machine, but back somewhere on your network. If they were running a -packet sniffer, odds are good they have access to other local machines. ------------------------------------------------------------------------------ - -10.2.2. Assessing the Damage - - The first thing is to assess the damage. What has been compromised? If you -are running an integrity checker like Tripwire, you can use it to perform an -integrity check; it should help to tell you what has been compromised. If -not, you will have to look around at all your important data. - - Since Linux systems are getting easier and easier to install, you might -consider saving your config files, wiping your disk(s), reinstalling, then -restoring your user files and your config files from backups. This will -ensure that you have a new, clean system. If you have to restore files from -the compromised system, be especially cautious of any binaries that you -restore, as they may be Trojan horses placed there by the intruder. - - Re-installation should be considered mandatory upon an intruder obtaining -root access. Additionally, you'd like to keep any evidence there is, so -having a spare disk in the safe may make sense. - - Then you have to worry about how long ago the compromise happened, and -whether the backups hold any damaged work. More on backups later. ------------------------------------------------------------------------------ - -10.2.3. Backups, Backups, Backups! - - Having regular backups is a godsend for security matters. If your system is -compromised, you can restore the data you need from backups. Of course, some -data is valuable to the attacker too, and they will not only destroy it, they -will steal it and have their own copies; but at least you will still have the -data. - - You should check several backups back into the past before restoring a file -that has been tampered with. The intruder could have compromised your files -long ago, and you could have made many successful backups of the compromised -file! - - Of course, there are also a raft of security concerns with backups. Make -sure you are storing them in a secure place. Know who has access to them. (If -an attacker can get your backups, they can have access to all your data -without you ever knowing it.) ------------------------------------------------------------------------------ - -10.2.4. Tracking Down the Intruder. - - Ok, you have locked the intruder out, and recovered your system, but you're -not quite done yet. While it is unlikely that most intruders will ever be -caught, you should report the attack. - - You should report the attack to the admin contact at the site from which the -attacker attacked your system. You can look up this contact with whois or the -Internic database. You might send them an email with all applicable log -entries and dates and times. If you spotted anything else distinctive about -your intruder, you might mention that too. After sending the email, you -should (if you are so inclined) follow up with a phone call. If that admin in -turn spots your attacker, they might be able to talk to the admin of the site -where they are coming from and so on. - - Good crackers often use many intermediate systems, some (or many) of which -may not even know they have been compromised. Trying to track a cracker back -to their home system can be difficult. Being polite to the admins you talk to -can go a long way to getting help from them. - - You should also notify any security organizations you are a part of ([http:/ -/www.cert.org/] CERT or similar), as well as your Linux system vendor. ------------------------------------------------------------------------------ - -11. Security Sources - - There are a LOT of good sites out there for Unix security in general and -Linux security specifically. It's very important to subscribe to one (or -more) of the security mailing lists and keep current on security fixes. Most -of these lists are very low volume, and very informative. ------------------------------------------------------------------------------ - -11.1. LinuxSecurity.com References - - The LinuxSecurity.com web site has numerous Linux and open source security -references written by the LinuxSecurity staff and people collectively around -the world. - - - -  *  [http://www.linuxsecurity.com/vuln-newsletter.html] Linux Advisory Watch - -- A comprehensive newsletter that outlines the security vulnerabilities - that have been announced throughout the week. It includes pointers to - updated packages and descriptions of each vulnerability. - -  *  [http://www.linuxsecurity.com/newsletter.html] Linux Security Week -- - The purpose of this document is to provide our readers with a quick - summary of each week's most relevant Linux security headlines. - -  *  [http://www.linuxsecurity.com/general/mailinglists.html] Linux Security - Discussion List -- This mailing list is for general security-related - questions and comments. - -  *  [http://www.linuxsecurity.com/general/mailinglists.html] Linux Security - Newsletters -- Subscription information for all newsletters. - -  *  [http://www.linuxsecurity.com/docs/colsfaq.html] comp.os.linux.security - FAQ -- Frequently Asked Questions with answers for the - comp.os.linux.security newsgroup. - -  *  [http://www.linuxsecurity.com/docs/] Linux Security Documentation -- A - great starting point for information pertaining to Linux and Open Source - security. - - ------------------------------------------------------------------------------ -11.2. FTP Sites - - CERT is the Computer Emergency Response Team. They often send out alerts of -current attacks and fixes. See [ftp://ftp.cert.org] ftp://ftp.cert.org for -more information. - - ZEDZ (formerly Replay) ([http://www.zedz.net] http://www.zedz.net) has -archives of many security programs. Since they are outside the US, they don't -need to obey US crypto restrictions. - - Matt Blaze is the author of CFS and a great security advocate. Matt's -archive is available at [ftp://ftp.research.att.com/pub/mab] ftp:// -ftp.research.att.com/pub/mab - - tue.nl is a great security FTP site in the Netherlands. [ftp:// -ftp.win.tue.nl/pub/security/] ftp.win.tue.nl ------------------------------------------------------------------------------ - -11.3. Web Sites - - - -  *  The Hacker FAQ is a FAQ about hackers: [http://www.solon.com/~seebs/faqs - /hacker.html] The Hacker FAQ - -  *  The COAST archive has a large number of Unix security programs and - information: [http://www.cs.purdue.edu/coast/] COAST - -  *  SuSe Security Page: [http://www.suse.de/security/] http://www.suse.de/ - security/ - -  *  Rootshell.com is a great site for seeing what exploits are currently - being used by crackers: [http://www.rootshell.com/] http:// - www.rootshell.com/ - -  *  BUGTRAQ puts out advisories on security issues: [http://www.netspace.org - /lsv-archive/bugtraq.html] BUGTRAQ archives - -  *  CERT, the Computer Emergency Response Team, puts out advisories on - common attacks on Unix platforms: [http://www.cert.org/] CERT home - -  *  Dan Farmer is the author of SATAN and many other security tools. His - home site has some interesting security survey information, as well as - security tools: [http://www.trouble.org] http://www.trouble.org - -  *  The Linux security WWW is a good site for Linux security information: - [http://www.aoy.com/Linux/Security/] Linux Security WWW - -  *  Infilsec has a vulnerability engine that can tell you what - vulnerabilities affect a specific platform: [http://www.infilsec.com/ - vulnerabilities/] http://www.infilsec.com/vulnerabilities/ - -  *  CIAC sends out periodic security bulletins on common exploits: [http:// - ciac.llnl.gov/cgi-bin/index/bulletins] http://ciac.llnl.gov/cgi-bin/index - /bulletins - -  *  A good starting point for Linux Pluggable Authentication modules can be - found at [http://www.kernel.org/pub/linux/libs/pam/] http:// - www.kernel.org/pub/linux/libs/pam/. - -  *  The Debian project has a web page for their security fixes and - information. It is at [http://www.debian.com/security/] http:// - www.debian.com/security/. - -  *  WWW Security FAQ, written by Lincoln Stein, is a great web security - reference. Find it at [http://www.w3.org/Security/Faq/ - www-security-faq.html] http://www.w3.org/Security/Faq/ - www-security-faq.html - - ------------------------------------------------------------------------------ -11.4. Mailing Lists - - Bugtraq: To subscribe to bugtraq, send mail to listserv@netspace.org -containing the message body subscribe bugtraq. (see links above for -archives). - - CIAC: Send e-mail to majordomo@tholia.llnl.gov. In the BODY (not subject) of -the message put (either or both): subscribe ciac-bulletin - - Red Hat has a number of mailing lists, the most important of which is the -redhat-announce list. You can read about security (and other) fixes as soon -as they come out. Send email to redhat-announce-list-request@redhat.com with -the Subject Subscribe See [https://listman.redhat.com/mailman/listinfo/] -https://listman.redhat.com/mailman/listinfo/ for more info and archives. - - The Debian project has a security mailing list that covers their security -fixes. See [http://www.debian.com/security/] http://www.debian.com/security/ -for more information. ------------------------------------------------------------------------------ - -11.5. Books - Printed Reading Material - - There are a number of good security books out there. This section lists a -few of them. In addition to the security specific books, security is covered -in a number of other books on system administration. - - - -  *  Building Internet Firewalls By D. Brent Chapman & Elizabeth D. Zwicky, - 1st Edition September 1995, ISBN: 1-56592-124-0 - -  *  Practical UNIX & Internet Security, 2nd Edition By Simson Garfinkel & - Gene Spafford, 2nd Edition April 1996, ISBN: 1-56592-148-8 - -  *  Computer Security Basics By Deborah Russell & G.T. Gangemi, Sr., 1st - Edition July 1991, ISBN: 0-937175-71-4 - -  *  Linux Network Administrator's Guide By Olaf Kirch, 1st Edition January - 1995, ISBN: 1-56592-087-2 - -  *  PGP: Pretty Good Privacy By Simson Garfinkel, 1st Edition December 1994, - ISBN: 1-56592-098-8 - -  *  Computer Crime A Crimefighter's Handbook By David Icove, Karl Seger & - William VonStorch (Consulting Editor Eugene H. Spafford), 1st Edition - August 1995, ISBN: 1-56592-086-4 - -  *  Linux Security By John S. Flowers, New Riders; ISBN: 0735700354, March - 1999 - -  *  Maximum Linux Security : A Hacker's Guide to Protecting Your Linux - Server and Network, Anonymous, Paperback - 829 pages, Sams; ISBN: - 0672313413, July 1999 - -  *  Intrusion Detection By Terry Escamilla, Paperback - 416 pages (September - 1998), John Wiley and Sons; ISBN: 0471290009 - -  *  Fighting Computer Crime, Donn Parker, Paperback - 526 pages (September - 1998), John Wiley and Sons; ISBN: 0471163783 - - ------------------------------------------------------------------------------ -12. Glossary - - Included below are several of the most frequently used terms in computer -security. A comprehensive dictionary of computer security terms is available -in the [http://www.linuxsecurity.com/dictionary/] LinuxSecurity.com -Dictionary - - - -  *  authentication: The process of knowing that the data received is the - same as the data that was sent, and that the claimed sender is in fact - the actual sender. - -  *  bastion Host: A computer system that must be highly secured because it - is vulnerable to attack, usually because it is exposed to the Internet - and is a main point of contact for users of internal networks. It gets - its name from the highly fortified projects on the outer walls of - medieval castles. Bastions overlook critical areas of defense, usually - having strong walls, room for extra troops, and the occasional useful tub - of boiling hot oil for discouraging attackers. - -  *  buffer overflow: Common coding style is to never allocate large enough - buffers, and to not check for overflows. When such buffers overflow, the - executing program (daemon or set-uid program) can be tricked in doing - some other things. Generally this works by overwriting a function's - return address on the stack to point to another location. - -  *  denial of service: An attack that consumes the resources on your - computer for things it was not intended to be doing, thus preventing - normal use of your network resources for legitimate purposes. - -  *  dual-homed Host: A general-purpose computer system that has at least two - network interfaces. - -  *  firewall: A component or set of components that restricts access between - a protected network and the Internet, or between other sets of networks. - -  *  host: A computer system attached to a network. - -  *  IP spoofing: IP Spoofing is a complex technical attack that is made up - of several components. It is a security exploit that works by tricking - computers in a trust relationship into thinking that you are someone that - you really aren't. There is an extensive paper written by daemon9, route, - and infinity in the Volume Seven, Issue Forty-Eight issue of Phrack - Magazine. - -  *  non-repudiation: The property of a receiver being able to prove that the - sender of some data did in fact send the data even though the sender - might later deny ever having sent it. - -  *  packet: The fundamental unit of communication on the Internet. - -  *  packet filtering: The action a device takes to selectively control the - flow of data to and from a network. Packet filters allow or block - packets, usually while routing them from one network to another (most - often from the Internet to an internal network, and vice-versa). To - accomplish packet filtering, you set up rules that specify what types of - packets (those to or from a particular IP address or port) are to be - allowed and what types are to be blocked. - -  *  perimeter network: A network added between a protected network and an - external network, in order to provide an additional layer of security. A - perimeter network is sometimes called a DMZ. - -  *  proxy server: A program that deals with external servers on behalf of - internal clients. Proxy clients talk to proxy servers, which relay - approved client requests to real servers, and relay answers back to - clients. - -  *  superuser: An informal name for root. - - ------------------------------------------------------------------------------ -13. Frequently Asked Questions - - - - 1. Is it more secure to compile driver support directly into the kernel, - instead of making it a module? - - Answer: Some people think it is better to disable the ability to load - device drivers using modules, because an intruder could load a Trojan - module or a module that could affect system security. - - However, in order to load modules, you must be root. The module object - files are also only writable by root. This means the intruder would need - root access to insert a module. If the intruder gains root access, there - are more serious things to worry about than whether he will load a - module. - - Modules are for dynamically loading support for a particular device that - may be infrequently used. On server machines, or firewalls for instance, - this is very unlikely to happen. For this reason, it would make more - sense to compile support directly into the kernel for machines acting as - a server. Modules are also slower than support compiled directly in the - kernel. - - 2. Why does logging in as root from a remote machine always fail? - - Answer: See Section 4.2. This is done intentionally to prevent remote - users from attempting to connect via telnet to your machine as root, - which is a serious security vulnerability, because then the root password - would be transmitted, in clear text, across the network. Don't forget: - potential intruders have time on their side, and can run automated - programs to find your password. Additionally, this is done to keep a - clear record of who logged in, not just root. - - 3. How do I enable shadow passwords on my Linux box? - - Answer: - - To enable shadow passwords, run pwconv as root, and /etc/shadow should - now exist, and be used by applications. If you are using RH 4.2 or above, - the PAM modules will automatically adapt to the change from using normal - /etc/passwd to shadow passwords without any other change. - - Some background: shadow passwords is a mechanism for storing your - password in a file other than the normal /etc/passwd file. This has - several advantages. The first one is that the shadow file, /etc/shadow, - is only readable by root, unlike /etc/passwd, which must remain readable - by everyone. The other advantage is that as the administrator, you can - enable or disable accounts without everyone knowing the status of other - users' accounts. - - The /etc/passwd file is then used to store user and group names, used by - programs like /bin/ls to map the user ID to the proper user name in a - directory listing. - - The /etc/shadow file then only contains the user name and his/her - password, and perhaps accounting information, like when the account - expires, etc. - - To enable shadow passwords, run pwconv as root, and /etc/shadow should - now exist, and be used by applications. Since you are using RH 4.2 or - above, the PAM modules will automatically adapt to the change from using - normal /etc/passwd to shadow passwords without any other change. - - Since you're interested in securing your passwords, perhaps you would - also be interested in generating good passwords to begin with. For this - you can use the pam_cracklib module, which is part of PAM. It runs your - password against the Crack libraries to help you decide if it is - too-easily guessable by password-cracking programs. - - 4. How can I enable the Apache SSL extensions? - - Answer: - - - - a. Get SSLeay 0.8.0 or later from [ftp://ftp.psy.uq.oz.au/pub/Crypto/ - SSL] ?? - - b. Build and test and install it! - - c. Get Apache source - - d. Get Apache SSLeay extensions from [ftp://ftp.ox.ac.uk/pub/crypto/SSL - /] here - - e. Unpack it in the apache source directory and patch Apache as per the - README. - - f. Configure and build it. - - - You might also try [http://www.zedz.net] ZEDZ net which has many - pre-built packages, and is located outside of the United States. - - 5. How can I manipulate user accounts, and still retain security? - - Answer: most distributions contain a great number of tools to change the - properties of user accounts. - - - -   +  The pwconv and unpwconv programs can be used to convert between - shadow and non-shadowed passwords. - -   +  The pwck and grpck programs can be used to verify proper - organization of the passwd and group files. - -   +  The useradd, usermod, and userdel programs can be used to add, - delete and modify user accounts. The groupadd, groupmod, and groupdel - programs will do the same for groups. - -   +  Group passwords can be created using gpasswd. - - - All these programs are "shadow-aware" -- that is, if you enable shadow - they will use /etc/shadow for password information, otherwise they won't. - - See the respective man pages for further information. - - 6. How can I password-protect specific HTML documents using Apache? - - I bet you didn't know about [http://www.apacheweek.com] http:// - www.apacheweek.org, did you? - - You can find information on user authentication at [http:// - www.apacheweek.com/features/userauth] http://www.apacheweek.com/features/ - userauth as well as other web server security tips from [http:// - www.apache.org/docs/misc/security_tips.html] http://www.apache.org/docs/ - misc/security_tips.html - - ------------------------------------------------------------------------------ -14. Conclusion - - By subscribing to the security alert mailing lists, and keeping current, you -can do a lot towards securing your machine. If you pay attention to your log -files and run something like tripwire regularly, you can do even more. - - A reasonable level of computer security is not difficult to maintain on a -home machine. More effort is required on business machines, but Linux can -indeed be a secure platform. Due to the nature of Linux development, security -fixes often come out much faster than they do on commercial operating -systems, making Linux an ideal platform when security is a requirement. ------------------------------------------------------------------------------ - -15. Acknowledgments - - Information here is collected from many sources. Thanks to the following who -either indirectly or directly have contributed: - - -Rob Riggs -[mailto:rob@DevilsThumb.com] rob@DevilsThumb.com - - S. Coffin [mailto:scoffin@netcom.com] scoffin@netcom.com - - Viktor Przebinda [mailto:viktor@CRYSTAL.MATH.ou.edu] -viktor@CRYSTAL.MATH.ou.edu - - Roelof Osinga [mailto:roelof@eboa.com] roelof@eboa.com - - Kyle Hasselbacher [mailto:kyle@carefree.quux.soltec.net] -kyle@carefree.quux.soltc.net - - David S. Jackson [mailto:dsj@dsj.net] dsj@dsj.net - - Todd G. Ruskell [mailto:ruskell@boulder.nist.gov] ruskell@boulder.nist.gov - - Rogier Wolff [mailto:R.E.Wolff@BitWizard.nl] R.E.Wolff@BitWizard.nl - - Antonomasia [mailto:ant@notatla.demon.co.uk] ant@notatla.demon.co.uk - - Nic Bellamy [mailto:sky@wibble.net] sky@wibble.net - - Eric Hanchrow [mailto:offby1@blarg.net] offby1@blarg.net - - Robert J. Berger[mailto:rberger@ibd.com] rberger@ibd.com - - Ulrich Alpers [mailto:lurchi@cdrom.uni-stuttgart.de] -lurchi@cdrom.uni-stuttgart.de - - David Noha [mailto:dave@c-c-s.com] dave@c-c-s.com - - Pavel Epifanov. [mailto:epv@ibm.net] epv@ibm.net - - Joe Germuska. [mailto:joe@germuska.com] joe@germuska.com - - Franklin S. Werren [mailto:fswerren@bagpipes.net] fswerren@bagpipes.net - - Paul Rusty Russell [mailto:Paul.Russell@rustcorp.com.au] < -Paul.Russell@rustcorp.com.au> - - Christine Gaunt [mailto:cgaunt@umich.edu] - - lin [mailto:bhewitt@refmntutl01.afsc.noaa.gov] -bhewitt@refmntutl01.afsc.noaa.gov - - A. Steinmetz [mailto:astmail@yahoo.com] astmail@yahoo.com - - Jun Morimoto [mailto:morimoto@xantia.citroen.org] -morimoto@xantia.citroen.org - - Xiaotian Sun [mailto:sunx@newton.me.berkeley.edu] -sunx@newton.me.berkeley.edu - - Eric Hanchrow [mailto:offby1@blarg.net] offby1@blarg.net - - Camille Begnis [mailto:camille@mandrakesoft.com] camille@mandrakesoft.com - - Neil D [mailto:neild@sympatico.ca] neild@sympatico.ca - - Michael Tandy [mailto:Michael.Tandy@BTInternet.com] -Michael.Tandy@BTInternet.com - - Tony Foiani [mailto:tkil@scrye.com] tkil@scrye.com - - Matt Johnston [mailto:mattj@flashmail.com] mattj@flashmail.com - - Geoff Billin [mailto:gbillin@turbonet.com] gbillin@turbonet.com - - Hal Burgiss [mailto:hburgiss@bellsouth.net] hburgiss@bellsouth.net - - Ian Macdonald [mailto:ian@linuxcare.com] ian@linuxcare.com - - M.Kiesel [mailto:m.kiesel@iname.com] m.kiesel@iname.com - - Mario Kratzer [mailto:kratzer@mathematik.uni-marburg.de] -kratzer@mathematik.uni-marburg.de - - Othmar Pasteka [mailto:pasteka@kabsi.at] pasteka@kabsi.at - - Robert M [mailto:rom@romab.com] rom@romab.com - - Cinnamon Lowe [mailto:clowe@cinci.rr.com] clowe@cinci.rr.com - - Rob McMeekin [mailto:blind_mordecai@yahoo.com] blind_mordecai@yahoo.com - - Gunnar Ritter [mailto:g-r@bigfoot.de] g-r@bigfoot.de - - Frank Lichtenheld[mailto:frank@lichtenheld.de] frank@lichtenheld.de - - Björn Lotz[mailto:blotz@suse.de] blotz@suse.de - - Othon Marcelo Nunes Batista[mailto:othonb@superig.com.br] -othonb@superig.com.br - - The following have translated this HOWTO into various other languages! - - A special thank you to all of them for help spreading the Linux word... - - Polish: Ziemek Borowski [mailto:ziembor@FAQ-bot.ZiemBor.Waw.PL] -ziembor@FAQ-bot.ZiemBor.Waw.PL - - Japanese: FUJIWARA Teruyoshi [mailto:fjwr@mtj.biglobe.ne.jp] -fjwr@mtj.biglobe.ne.jp - - Indonesian: Tedi Heriyanto [mailto:22941219@students.ukdw.ac.id] -22941219@students.ukdw.ac.id - - Korean: Bume Chang [mailto:Boxcar0001@aol.com] Boxcar0001@aol.com - - Spanish: Juan Carlos Fernandez [mailto:piwiman@visionnetware.com] -piwiman@visionnetware.com - - Dutch: "Nine Matthijssen" [mailto:nine@matthijssen.nl] nine@matthijssen.nl - - Norwegian: ketil@vestby.com [mailto:ketil@vestby.com] ketil@vestby.com - - Turkish: tufan karadere [mailto:tufank@metu.edu.tr] tufank@metu.edu.tr - - -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] -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. - ------------------------------------------------------------------------------ -Table of Contents -1. Introduction -2. Background - 2.1. History of Unix, Linux, and Open Source / Free Software - 2.2. Security Principles - 2.3. Why do Programmers Write Insecure Code? - 2.4. Is Open Source Good for Security? - 2.5. Types of Secure Programs - 2.6. Paranoia is a Virtue - 2.7. Why Did I Write This Document? - 2.8. Sources of Design and Implementation Guidelines - 2.9. Other Sources of Security Information - 2.10. Document Conventions - - -3. Summary of Linux and Unix Security Features - 3.1. Processes - 3.2. Files - 3.3. System V IPC - 3.4. Sockets and Network Connections - 3.5. Signals - 3.6. Quotas and Limits - 3.7. Dynamically Linked Libraries - 3.8. Audit - 3.9. PAM - 3.10. Specialized Security Extensions for Unix-like Systems - - -4. Security Requirements - 4.1. Common Criteria Introduction - 4.2. Security Environment and Objectives - 4.3. Security Functionality Requirements - 4.4. Security Assurance Measure Requirements - - -5. Validate All Input - 5.1. Command line - 5.2. Environment Variables - 5.3. File Descriptors - 5.4. File Names - 5.5. File Contents - 5.6. Web-Based Application Inputs (Especially CGI Scripts) - 5.7. Other Inputs - 5.8. Human Language (Locale) Selection - 5.9. Character Encoding - 5.10. Prevent Cross-site Malicious Content on Input - 5.11. Filter HTML/URIs That May Be Re-presented - 5.12. Forbid HTTP GET To Perform Non-Queries - 5.13. Counter SPAM - 5.14. Limit Valid Input Time and Load Level - - -6. Avoid Buffer Overflow - 6.1. Dangers in C/C++ - 6.2. Library Solutions in C/C++ - 6.3. Compilation Solutions in C/C++ - 6.4. Other Languages - - -7. Structure Program Internals and Approach - 7.1. Follow Good Software Engineering Principles for Secure Programs - 7.2. Secure the Interface - 7.3. Separate Data and Control - 7.4. Minimize Privileges - 7.5. Minimize the Functionality of a Component - 7.6. Avoid Creating Setuid/Setgid Scripts - 7.7. Configure Safely and Use Safe Defaults - 7.8. Load Initialization Values Safely - 7.9. Fail Safe - 7.10. Avoid Race Conditions - 7.11. Trust Only Trustworthy Channels - 7.12. Set up a Trusted Path - 7.13. Use Internal Consistency-Checking Code - 7.14. Self-limit Resources - 7.15. Prevent Cross-Site (XSS) Malicious Content - 7.16. Foil Semantic Attacks - 7.17. Be Careful with Data Types - - -8. Carefully Call Out to Other Resources - 8.1. Call Only Safe Library Routines - 8.2. Limit Call-outs to Valid Values - 8.3. Handle Metacharacters - 8.4. Call Only Interfaces Intended for Programmers - 8.5. Check All System Call Returns - 8.6. Avoid Using vfork(2) - 8.7. Counter Web Bugs When Retrieving Embedded Content - 8.8. Hide Sensitive Information - - -9. Send Information Back Judiciously - 9.1. Minimize Feedback - 9.2. Don't Include Comments - 9.3. Handle Full/Unresponsive Output - 9.4. Control Data Formatting (Format Strings/Formatation) - 9.5. Control Character Encoding in Output - 9.6. Prevent Include/Configuration File Access - - -10. Language-Specific Issues - 10.1. C/C++ - 10.2. Perl - 10.3. Python - 10.4. Shell Scripting Languages (sh and csh Derivatives) - 10.5. Ada - 10.6. Java - 10.7. Tcl - 10.8. PHP - - -11. Special Topics - 11.1. Passwords - 11.2. Authenticating on the Web - 11.3. Random Numbers - 11.4. Specially Protect Secrets (Passwords and Keys) in User Memory - 11.5. Cryptographic Algorithms and Protocols - 11.6. Using PAM - 11.7. Tools - 11.8. Windows CE - 11.9. Write Audit Records - 11.10. Physical Emissions - 11.11. Miscellaneous - - -12. Conclusion -13. Bibliography -A. History -B. Acknowledgements -C. About the Documentation License -D. GNU Free Documentation License -E. Endorsements -F. About the Author - -List of Tables -5-1. Legal UTF-8 Sequences - -List of Figures -1-1. Abstract View of a Program - ------------------------------------------------------------------------------ -Chapter 1. Introduction - -  A wise man attacks the city of the - mighty and pulls down the stronghold - in which they trust. -  Proverbs 21:22 (NIV) - -This book describes a set of guidelines for writing secure programs on Linux -and Unix systems. For purposes of this book, a ``secure program'' is a -program that sits on a security boundary, taking input from a source that -does not have the same access rights as the program. Such programs include -application programs used as viewers of remote data, web applications -(including CGI scripts), network servers, and setuid/setgid programs. This -book does not address modifying the operating system kernel itself, although -many of the principles discussed here do apply. These guidelines were -developed as a survey of ``lessons learned'' from various sources on how to -create such programs (along with additional observations by the author), -reorganized into a set of larger principles. This book includes specific -guidance for a number of languages, including C, C++, Java, Perl, PHP, -Python, Tcl, and Ada95. - -You can find the master copy of this book at [http://www.dwheeler.com/ -secure-programs] http://www.dwheeler.com/secure-programs. This book is also -part of the Linux Documentation Project (LDP) at [http://www.tldp.org] http:/ -/www.tldp.org It's also mirrored in several other places. Please note that -these mirrors, including the LDP copy and/or the copy in your distribution, -may be older than the master copy. I'd like to hear comments on this book, -but please do not send comments until you've checked to make sure that your -comment is valid for the latest version. - -This book does not cover assurance measures, software engineering processes, -and quality assurance approaches, which are important but widely discussed -elsewhere. Such measures include testing, peer review, configuration -management, and formal methods. Documents specifically identifying sets of -development assurance measures for security issues include the Common -Criteria (CC, [CC 1999]) and the Systems Security Engineering Capability -Maturity Model [SSE-CMM 1999]. Inspections and other peer review techniques -are discussed in [Wheeler 1996]. This book does briefly discuss ideas from -the CC, but only as an organizational aid to discuss security requirements. -More general sets of software engineering processes are defined in documents -such as the Software Engineering Institute's Capability Maturity Model for -Software (SW-CMM) [Paulk 1993a, 1993b] and ISO 12207 [ISO 12207]. General -international standards for quality systems are defined in ISO 9000 and ISO -9001 [ISO 9000, 9001]. - -This book does not discuss how to configure a system (or network) to be -secure in a given environment. This is clearly necessary for secure use of a -given program, but a great many other documents discuss secure -configurations. An excellent general book on configuring Unix-like systems to -be secure is Garfinkel [1996]. Other books for securing Unix-like systems -include Anonymous [1998]. You can also find information on configuring -Unix-like systems at web sites such as [http://www.unixtools.com/ -security.html] http://www.unixtools.com/security.html. Information on -configuring a Linux system to be secure is available in a wide variety of -documents including Fenzi [1999], Seifried [1999], Wreski [1998], Swan -[2001], and Anonymous [1999]. Geodsoft [2001] describes how to harden -OpenBSD, and many of its suggestions are useful for any Unix-like system. -Information on auditing existing Unix-like systems are discussed in Mookhey -[2002]. For Linux systems (and eventually other Unix-like systems), you may -want to examine the Bastille Hardening System, which attempts to ``harden'' -or ``tighten'' the Linux operating system. You can learn more about Bastille -at [http://www.bastille-linux.org] http://www.bastille-linux.org; it is -available for free under the General Public License (GPL). Other hardening -systems include [http://www.grsecurity.net] grsecurity. For Windows 2000, you -might want to look at Cox [2000]. The U.S. National Security Agency (NSA) -maintains a set of security recommendation guides at [http:// -nsa1.www.conxion.com] http://nsa1.www.conxion.com, including the ``60 Minute -Network Security Guide.'' If you're trying to establish a public key -infrastructure (PKI) using open source tools, you might want to look at the -[http://ospkibook.sourceforge.net] Open Source PKI Book. More about firewalls -and Internet security is found in [Cheswick 1994]. - -Configuring a computer is only part of Security Management, a larger area -that also covers how to deal with viruses, what kind of organizational -security policy is needed, business continuity plans, and so on. There are -international standards and guidance for security management. ISO 13335 is a -five-part technical report giving guidance on security management [ISO -13335]. ISO/IEC 17799:2000 defines a code of practice [ISO 17799]; its stated -purpose is to give high-level and general ``recommendations for information -security management for use by those who are responsible for initiating, -implementing or maintaining security in their organization.'' The document -specifically identifies itself as "a starting point for developing -organization specific guidance." It also states that not all of the guidance -and controls it contains may be applicable, and that additional controls not -contained may be required. Even more importantly, they are intended to be -broad guidelines covering a number of areas. and not intended to give -definitive details or "how-tos". It's worth noting that the original signing -of ISO/IEC 17799:2000 was controversial; Belgium, Canada, France, Germany, -Italy, Japan and the US voted against its adoption. However, it appears that -these votes were primarily a protest on parliamentary procedure, not on the -content of the document, and certainly people are welcome to use ISO 17799 if -they find it helpful. More information about ISO 17799 can be found in NIST's -[http://csrc.nist.gov/publications/secpubs/otherpubs/reviso-faq.pdf] ISO/IEC -17799:2000 FAQ. ISO 17799 is highly related to BS 7799 part 1 and 2; more -information about BS 7799 can be found at [http://www.xisec.com/faq.htm] -http://www.xisec.com/faq.htm. ISO 17799 is currently under revision. It's -important to note that none of these standards (ISO 13335, ISO 17799, or BS -7799 parts 1 and 2) are intended to be a detailed set of technical guidelines -for software developers; they are all intended to provide broad guidelines in -a number of areas. This is important, because software developers who simply -only follow (for example) ISO 17799 will generally not produce secure -software - developers need much, much, much more detail than ISO 17799 -provides. - -The Commonly Accepted Security Practices & Recommendations (CASPR) project at -[http://www.caspr.org] http://www.caspr.org is trying to distill information -security knowledge into a series of papers available to all (under the GNU -FDL license, so that future document derivatives will continue to be -available to all). Clearly, security management needs to include keeping with -patches as vulnerabilities are found and fixed. Beattie [2002] provides an -interesting analysis on how to determine when to apply patches contrasting -risk of a bad patch to the risk of intrusion (e.g., under certain conditions, -patches are optimally applied 10 or 30 days after they are released). - -If you're interested in the current state of vulnerabilities, there are other -resources available to use. The CVE at http://cve.mitre.org gives a standard -identifier for each (widespread) vulnerability. The paper [http:// -securitytracker.com/learn/securitytracker-stats-2002.pdf] SecurityTracker -Statistics analyzes vulnerabilities to determine what were the most common -vulnerabilities. The Internet Storm Center at http://isc.incidents.org/ shows -the prominence of various Internet attacks around the world. - -This book assumes that the reader understands computer security issues in -general, the general security model of Unix-like systems, networking (in -particular TCP/IP based networks), and the C programming language. This book -does include some information about the Linux and Unix programming model for -security. If you need more information on how TCP/IP based networks and -protocols work, including their security protocols, consult general works on -TCP/IP such as [Murhammer 1998]. - -When I first began writing this document, there were many short articles but -no books on writing secure programs. There are now two other books on writing -secure programs. One is ``Building Secure Software'' by John Viega and Gary -McGraw [Viega 2002]; this is a very good book that discusses a number of -important security issues, but it omits a large number of important security -problems that are instead covered here. Basically, this book selects several -important topics and covers them well, but at the cost of omitting many other -important topics. The Viega book has a little more information for Unix-like -systems than for Windows systems, but much of it is independent of the kind -of system. The other book is ``Writing Secure Code'' by Michael Howard and -David LeBlanc [Howard 2002]. The title of this other book is misleading; the -book is solely about writing secure programs for Windows, and is basically -worthless if you are writing programs for any other system. This shouldn't be -surprising; it's published by Microsoft press, and its copyright is owned by -Microsoft. If you are trying to write secure programs for Microsoft's Windows -systems, it's a good book. Another useful source of secure programming -guidance is the The Open Web Application Security Project (OWASP) Guide to -Building Secure Web Applications and Web Services; it has more on process, -and less specifics than this book, but it has useful material in it. - -This book covers all Unix-like systems, including Linux and the various -strains of Unix, and it particularly stresses Linux and provides details -about Linux specifically. There's some material specifically on Windows CE, -and in fact much of this material is not limited to a particular operating -system. If you know relevant information not already included here, please -let me know. - -This book is copyright (C) 1999-2002 David A. Wheeler and is covered by the -GNU Free Documentation License (GFDL); see Appendix C and Appendix D for more -information. - -Chapter 2 discusses the background of Unix, Linux, and security. Chapter 3 -describes the general Unix and Linux security model, giving an overview of -the security attributes and operations of processes, filesystem objects, and -so on. This is followed by the meat of this book, a set of design and -implementation guidelines for developing applications on Linux and Unix -systems. The book ends with conclusions in Chapter 12, followed by a lengthy -bibliography and appendixes. - -The design and implementation guidelines are divided into categories which I -believe emphasize the programmer's viewpoint. Programs accept inputs, process -data, call out to other resources, and produce output, as shown in Figure 1-1 -; notionally all security guidelines fit into one of these categories. I've -subdivided ``process data'' into structuring program internals and approach, -avoiding buffer overflows (which in some cases can also be considered an -input issue), language-specific information, and special topics. The chapters -are ordered to make the material easier to follow. Thus, the book chapters -giving guidelines discuss validating all input (Chapter 5), avoiding buffer -overflows (Chapter 6), structuring program internals and approach (Chapter 7 -), carefully calling out to other resources (Chapter 8), judiciously sending -information back (Chapter 9), language-specific information (Chapter 10), and -finally information on special topics such as how to acquire random numbers ( -Chapter 11). - - -Figure 1-1. Abstract View of a Program - -[program] ------------------------------------------------------------------------------ - -Chapter 2. Background - -  I issued an order and a search was - made, and it was found that this city - has a long history of revolt against - kings and has been a place of - rebellion and sedition. -  Ezra 4:19 (NIV) ------------------------------------------------------------------------------ - -2.1. History of Unix, Linux, and Open Source / Free Software - -2.1.1. Unix - -In 1969-1970, Kenneth Thompson, Dennis Ritchie, and others at AT&T Bell Labs -began developing a small operating system on a little-used PDP-7. The -operating system was soon christened Unix, a pun on an earlier operating -system project called MULTICS. In 1972-1973 the system was rewritten in the -programming language C, an unusual step that was visionary: due to this -decision, Unix was the first widely-used operating system that could switch -from and outlive its original hardware. Other innovations were added to Unix -as well, in part due to synergies between Bell Labs and the academic -community. In 1979, the ``seventh edition'' (V7) version of Unix was -released, the grandfather of all extant Unix systems. - -After this point, the history of Unix becomes somewhat convoluted. The -academic community, led by Berkeley, developed a variant called the Berkeley -Software Distribution (BSD), while AT&T continued developing Unix under the -names ``System III'' and later ``System V''. In the late 1980's through early -1990's the ``wars'' between these two major strains raged. After many years -each variant adopted many of the key features of the other. Commercially, -System V won the ``standards wars'' (getting most of its interfaces into the -formal standards), and most hardware vendors switched to AT&T's System V. -However, System V ended up incorporating many BSD innovations, so the -resulting system was more a merger of the two branches. The BSD branch did -not die, but instead became widely used for research, for PC hardware, and -for single-purpose servers (e.g., many web sites use a BSD derivative). - -The result was many different versions of Unix, all based on the original -seventh edition. Most versions of Unix were proprietary and maintained by -their respective hardware vendor, for example, Sun Solaris is a variant of -System V. Three versions of the BSD branch of Unix ended up as open source: -FreeBSD (concentrating on ease-of-installation for PC-type hardware), NetBSD -(concentrating on many different CPU architectures), and a variant of NetBSD, -OpenBSD (concentrating on security). More general information about Unix -history can be found at [http://www.datametrics.com/tech/unix/uxhistry/ -brf-hist.htm] http://www.datametrics.com/tech/unix/uxhistry/brf-hist.htm, -[http://perso.wanadoo.fr/levenez/unix] http://perso.wanadoo.fr/levenez/unix, -and [http://www.crackmonkey.org/unix.html] http://www.crackmonkey.org/ -unix.html. Much more information about the BSD history can be found in -[McKusick 1999] and [ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/ -share/misc/bsd-family-tree] ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current -/src/share/misc/bsd-family-tree. - -A slightly old but interesting advocacy piece that presents arguments for -using Unix-like systems (instead of Microsoft's products) is [http:// -web.archive.org/web/20010801155417/www.unix-vs-nt.org/kirch] John Kirch's -paper ``Microsoft Windows NT Server 4.0 versus UNIX''. ------------------------------------------------------------------------------ - -2.1.2. Free Software Foundation - -In 1984 Richard Stallman's Free Software Foundation (FSF) began the GNU -project, a project to create a free version of the Unix operating system. By -free, Stallman meant software that could be freely used, read, modified, and -redistributed. The FSF successfully built a vast number of useful components, -including a C compiler (gcc), an impressive text editor (emacs), and a host -of fundamental tools. However, in the 1990's the FSF was having trouble -developing the operating system kernel [FSF 1998]; without a kernel their -dream of a completely free operating system would not be realized. ------------------------------------------------------------------------------ - -2.1.3. Linux - -In 1991 Linus Torvalds began developing an operating system kernel, which he -named ``Linux'' [Torvalds 1999]. This kernel could be combined with the FSF -material and other components (in particular some of the BSD components and -MIT's X-windows software) to produce a freely-modifiable and very useful -operating system. This book will term the kernel itself the ``Linux kernel'' -and an entire combination as ``Linux''. Note that many use the term ``GNU/ -Linux'' instead for this combination. - -In the Linux community, different organizations have combined the available -components differently. Each combination is called a ``distribution'', and -the organizations that develop distributions are called ``distributors''. -Common distributions include Red Hat, Mandrake, SuSE, Caldera, Corel, and -Debian. There are differences between the various distributions, but all -distributions are based on the same foundation: the Linux kernel and the GNU -glibc libraries. Since both are covered by ``copyleft'' style licenses, -changes to these foundations generally must be made available to all, a -unifying force between the Linux distributions at their foundation that does -not exist between the BSD and AT&T-derived Unix systems. This book is not -specific to any Linux distribution; when it discusses Linux it presumes Linux -kernel version 2.2 or greater and the C library glibc 2.1 or greater, valid -assumptions for essentially all current major Linux distributions. ------------------------------------------------------------------------------ - -2.1.4. Open Source / Free Software - -Increased interest in software that is freely shared has made it increasingly -necessary to define and explain it. A widely used term is ``open source -software'', which is further defined in [OSI 1999]. Eric Raymond [1997, 1998] -wrote several seminal articles examining its various development processes. -Another widely-used term is ``free software'', where the ``free'' is short -for ``freedom'': the usual explanation is ``free speech, not free beer.'' -Neither phrase is perfect. The term ``free software'' is often confused with -programs whose executables are given away at no charge, but whose source code -cannot be viewed, modified, or redistributed. Conversely, the term ``open -source'' is sometime (ab)used to mean software whose source code is visible, -but for which there are limitations on use, modification, or redistribution. -This book uses the term ``open source'' for its usual meaning, that is, -software which has its source code freely available for use, viewing, -modification, and redistribution; a more detailed definition is contained in -the [http://www.opensource.org/osd.html] Open Source Definition. In some -cases, a difference in motive is suggested; those preferring the term ``free -software'' wish to strongly emphasize the need for freedom, while those using -the term may have other motives (e.g., higher reliability) or simply wish to -appear less strident. For information on this definition of free software, -and the motivations behind it, can be found at [http://www.fsf.org] http:// -www.fsf.org. - -Those interested in reading advocacy pieces for open source software and free -software should see [http://www.opensource.org] http://www.opensource.org and -[http://www.fsf.org] http://www.fsf.org. There are other documents which -examine such software, for example, Miller [1995] found that the open source -software were noticeably more reliable than proprietary software (using their -measurement technique, which measured resistance to crashing due to random -input). ------------------------------------------------------------------------------ - -2.1.5. Comparing Linux and Unix - -This book uses the term ``Unix-like'' to describe systems intentionally like -Unix. In particular, the term ``Unix-like'' includes all major Unix variants -and Linux distributions. Note that many people simply use the term ``Unix'' -to describe these systems instead. Originally, the term ``Unix'' meant a -particular product developed by AT&T. Today, the Open Group owns the Unix -trademark, and it defines Unix as ``the worldwide Single UNIX -Specification''. - -Linux is not derived from Unix source code, but its interfaces are -intentionally like Unix. Therefore, Unix lessons learned generally apply to -both, including information on security. Most of the information in this book -applies to any Unix-like system. Linux-specific information has been -intentionally added to enable those using Linux to take advantage of Linux's -capabilities. - -Unix-like systems share a number of security mechanisms, though there are -subtle differences and not all systems have all mechanisms available. All -include user and group ids (uids and gids) for each process and a filesystem -with read, write, and execute permissions (for user, group, and other). See -Thompson [1974] and Bach [1986] for general information on Unix systems, -including their basic security mechanisms. Chapter 3 summarizes key security -features of Unix and Linux. ------------------------------------------------------------------------------ - -2.2. Security Principles - -There are many general security principles which you should be familiar with; -one good place for general information on information security is the -Information Assurance Technical Framework (IATF) [NSA 2000]. NIST has -identified high-level ``generally accepted principles and practices'' -[Swanson 1996]. You could also look at a general textbook on computer -security, such as [Pfleeger 1997]. NIST Special Publication 800-27 describes -a number of good engineering principles (although, since they're abstract, -they're insufficient for actually building secure programs - hence this -book); you can get a copy at [http://csrc.nist.gov/publications/nistpubs/ -800-27/sp800-27.pdf] http://csrc.nist.gov/publications/nistpubs/800-27/ -sp800-27.pdf. A few security principles are summarized here. - -Often computer security objectives (or goals) are described in terms of three -overall objectives: - -  * Confidentiality (also known as secrecy), meaning that the computing - system's assets can be read only by authorized parties. - -  * Integrity, meaning that the assets can only be modified or deleted by - authorized parties in authorized ways. - -  * Availability, meaning that the assets are accessible to the authorized - parties in a timely manner (as determined by the systems requirements). - The failure to meet this goal is called a denial of service. - - -Some people define additional major security objectives, while others lump -those additional goals as special cases of these three. For example, some -separately identify non-repudiation as an objective; this is the ability to -``prove'' that a sender sent or receiver received a message (or both), even -if the sender or receiver wishes to deny it later. Privacy is sometimes -addressed separately from confidentiality; some define this as protecting the -confidentiality of a user (e.g., their identity) instead of the data. Most -objectives require identification and authentication, which is sometimes -listed as a separate objective. Often auditing (also called accountability) -is identified as a desirable security objective. Sometimes ``access control'' -and ``authenticity'' are listed separately as well. For example, The U.S. -Department of Defense (DoD), in DoD directive 3600.1 defines ``information -assurance'' as ``information operations (IO) that protect and defend -information and information systems by ensuring their availability, -integrity, authentication, confidentiality, and nonrepudiation. This includes -providing for restoration of information systems by incorporating protection, -detection, and reaction capabilities.'' - -In any case, it is important to identify your program's overall security -objectives, no matter how you group them together, so that you'll know when -you've met them. - -Sometimes these objectives are a response to a known set of threats, and -sometimes some of these objectives are required by law. For example, for U.S. -banks and other financial institutions, there's a new privacy law called the -``Gramm-Leach-Bliley'' (GLB) Act. This law mandates disclosure of personal -information shared and means of securing that data, requires disclosure of -personal information that will be shared with third parties, and directs -institutions to give customers a chance to opt out of data sharing. [Jones -2000] - -There is sometimes conflict between security and some other general system/ -software engineering principles. Security can sometimes interfere with ``ease -of use'', for example, installing a secure configuration may take more effort -than a ``trivial'' installation that works but is insecure. Often, this -apparent conflict can be resolved, for example, by re-thinking a problem it's -often possible to make a secure system also easy to use. There's also -sometimes a conflict between security and abstraction (information hiding); -for example, some high-level library routines may be implemented securely or -not, but their specifications won't tell you. In the end, if your application -must be secure, you must do things yourself if you can't be sure otherwise - -yes, the library should be fixed, but it's your users who will be hurt by -your poor choice of library routines. - -A good general security principle is ``defense in depth''; you should have -numerous defense mechanisms (``layers'') in place, designed so that an -attacker has to defeat multiple mechanisms to perform a successful attack. ------------------------------------------------------------------------------ - -2.3. Why do Programmers Write Insecure Code? - -Many programmers don't intend to write insecure code - but do anyway. Here -are a number of purported reasons for this. Most of these were collected and -summarized by Aleph One on Bugtraq (in a posting on December 17, 1998): - -  * There is no curriculum that addresses computer security in most schools. - Even when there is a computer security curriculum, they often don't - discuss how to write secure programs as a whole. Many such curriculum - only study certain areas such as cryptography or protocols. These are - important, but they often fail to discuss common real-world issues such - as buffer overflows, string formatting, and input checking. I believe - this is one of the most important problems; even those programmers who go - through colleges and universities are very unlikely to learn how to write - secure programs, yet we depend on those very people to write secure - programs. - -  * Programming books/classes do not teach secure/safe programming - techniques. Indeed, until recently there were no books on how to write - secure programs at all (this book is one of those few). - -  * No one uses formal verification methods. - -  * C is an unsafe language, and the standard C library string functions are - unsafe. This is particularly important because C is so widely used - the - ``simple'' ways of using C permit dangerous exploits. - -  * Programmers do not think ``multi-user.'' - -  * Programmers are human, and humans are lazy. Thus, programmers will often - use the ``easy'' approach instead of a secure approach - and once it - works, they often fail to fix it later. - -  * Most programmers are simply not good programmers. - -  * Most programmers are not security people; they simply don't often think - like an attacker does. - -  * Most security people are not programmers. This was a statement made by - some Bugtraq contributors, but it's not clear that this claim is really - true. - -  * Most computer security models are terrible. - -  * There is lots of ``broken'' legacy software. Fixing this software (to - remove security faults or to make it work with more restrictive security - policies) is difficult. - -  * Consumers don't care about security. (Personally, I have hope that - consumers are beginning to care about security; a computer system that is - constantly exploited is neither useful nor user-friendly. Also, many - consumers are unaware that there's even a problem, assume that it can't - happen to them, or think that that things cannot be made better.) - -  * Security costs extra development time. - -  * Security costs in terms of additional testing (red teams, etc.). - - ------------------------------------------------------------------------------ -2.4. Is Open Source Good for Security? - -There's been a lot of debate by security practitioners about the impact of -open source approaches on security. One of the key issues is that open source -exposes the source code to examination by everyone, both the attackers and -defenders, and reasonable people disagree about the ultimate impact of this -situation. (Note - you can get the latest version of this essay by going to -the main website for this book, [http://www.dwheeler.com/secure-programs] -http://www.dwheeler.com/secure-programs. ------------------------------------------------------------------------------ - -2.4.1. View of Various Experts - -First, let's exampine what security experts have to say. - -Bruce Schneier is a well-known expert on computer security and cryptography. -He argues that smart engineers should ``demand open source code for anything -related to security'' [Schneier 1999], and he also discusses some of the -preconditions which must be met to make open source software secure. Vincent -Rijmen, a developer of the winning Advanced Encryption Standard (AES) -encryption algorithm, believes that the open source nature of Linux provides -a superior vehicle to making security vulnerabilities easier to spot and fix, -``Not only because more people can look at it, but, more importantly, because -the model forces people to write more clear code, and to adhere to standards. -This in turn facilitates security review'' [Rijmen 2000]. - -Elias Levy (Aleph1) is the former moderator of one of the most popular -security discussion groups - Bugtraq. He discusses some of the problems in -making open source software secure in his article "Is Open Source Really More -Secure than Closed?". His summary is: - - - So does all this mean Open Source Software is no better than closed - source software when it comes to security vulnerabilities? No. Open - Source Software certainly does have the potential to be more secure than - its closed source counterpart. But make no mistake, simply being open - source is no guarantee of security. - -Whitfield Diffie is the co-inventor of public-key cryptography (the basis of -all Internet security) and chief security officer and senior staff engineer -at Sun Microsystems. In his 2003 article [http://zdnet.com.com/ -2100-1107-980938.html] Risky business: Keeping security a secret, he argues -that proprietary vendor's claims that their software is more secure because -it's secret is nonsense. He identifies and then counters two main claims made -by proprietary vendors: (1) that release of code benefits attackers more than -anyone else because a lot of hostile eyes can also look at open-source code, -and that (2) a few expert eyes are better than several random ones. He first -notes that while giving programmers access to a piece of software doesn't -guarantee they will study it carefully, there is a group of programmers who -can be expected to care deeply: Those who either use the software personally -or work for an enterprise that depends on it. "In fact, auditing the programs -on which an enterprise depends for its own security is a natural function of -the enterprise's own information-security organization." He then counters the -second argument, noting that "As for the notion that open source's usefulness -to opponents outweighs the advantages to users, that argument flies in the -face of one of the most important principles in security: A secret that -cannot be readily changed should be regarded as a vulnerability." He closes -noting that - - - "It's simply unrealistic to depend on secrecy for security in computer - software. You may be able to keep the exact workings of the program out - of general circulation, but can you prevent the code from being - reverse-engineered by serious opponents? Probably not." - - - -John Viega's article [http://dev-opensourceit.earthweb.com/news/ -000526_security.html] "The Myth of Open Source Security" also discusses -issues, and summarizes things this way: - - - Open source software projects can be more secure than closed source - projects. However, the very things that can make open source programs - secure -- the availability of the source code, and the fact that large - numbers of users are available to look for and fix security holes -- can - also lull people into a false sense of security. - -[http://www.linuxworld.com/linuxworld/lw-1998-11/lw-11-ramparts.html] Michael -H. Warfield's "Musings on open source security" is very positive about the -impact of open source software on security. In contrast, Fred Schneider -doesn't believe that open source helps security, saying ``there is no reason -to believe that the many eyes inspecting (open) source code would be -successful in identifying bugs that allow system security to be compromised'' -and claiming that ``bugs in the code are not the dominant means of attack'' -[Schneider 2000]. He also claims that open source rules out control of the -construction process, though in practice there is such control - all major -open source programs have one or a few official versions with ``owners'' with -reputations at stake. Peter G. Neumann discusses ``open-box'' software (in -which source code is available, possibly only under certain conditions), -saying ``Will open-box software really improve system security? My answer is -not by itself, although the potential is considerable'' [Neumann 2000]. -TruSecure Corporation, under sponsorship by Red Hat (an open source company), -has developed a paper on why they believe open source is more effective for -security [TruSecure 2001]. [http://www-106.ibm.com/developerworks/linux/ -library/l-oss.html?open&I=252,t=gr,p=SeclmpOS] Natalie Walker Whitlock's IBM -DeveloperWorks article discusses the pros and cons as well. Brian Witten, -Carl Landwehr, and Micahel Caloyannides [Witten 2001] published in IEEE -Software an article tentatively concluding that having source code available -should work in the favor of system security; they note: - - - ``We can draw four additional conclusions from this discussion. First, - access to source code lets users improve system security -- if they have - the capability and resources to do so. Second, limited tests indicate - that for some cases, open source life cycles produce systems that are - less vulnerable to nonmalicious faults. Third, a survey of three - operating systems indicates that one open source operating system - experienced less exposure in the form of known but unpatched - vulnerabilities over a 12-month period than was experienced by either of - two proprietary counterparts. Last, closed and proprietary system - development models face disincentives toward fielding and supporting more - secure systems as long as less secure systems are more profitable. - Notwithstanding these conclusions, arguments in this important matter are - in their formative stages and in dire need of metrics that can reflect - security delivered to the customer.'' - -Scott A. Hissam and Daniel Plakosh's [http://www.ics.uci.edu/~wscacchi/Papers -/New/IEE_hissam.pdf] ``Trust and Vulnerability in Open Source Software'' -discuss the pluses and minuses of open source software. As with other papers, -they note that just because the software is open to review, it should not -automatically follow that such a review has actually been performed. Indeed, -they note that this is a general problem for all software, open or closed - -it is often questionable if many people examine any given piece of software. -One interesting point is that they demonstrate that attackers can learn about -a vulnerability in a closed source program (Windows) from patches made to an -OSS/FS program (Linux). In this example, Linux developers fixed a -vulnerability before attackers tried to attack it, and attackers correctly -surmised that a similar problem might be still be in Windows (and it was). -Unless OSS/FS programs are forbidden, this kind of learning is difficult to -prevent. Therefore, the existance of an OSS/FS program can reveal the -vulnerabilities of both the OSS/FS and proprietary program performing the -same function - but at in this example, the OSS/FS program was fixed first. ------------------------------------------------------------------------------ - -2.4.2. Why Closing the Source Doesn't Halt Attacks - -It's been argued that a system without source code is more secure because, -since there's less information available for an attacker, it should be harder -for an attacker to find the vulnerabilities. This argument has a number of -weaknesses, however, because although source code is extremely important when -trying to add new capabilities to a program, attackers generally don't need -source code to find a vulnerability. - -First, it's important to distinguish between ``destructive'' acts and -``constructive'' acts. In the real world, it is much easier to destroy a car -than to build one. In the software world, it is much easier to find and -exploit a vulnerability than to add new significant new functionality to that -software. Attackers have many advantages against defenders because of this -difference. Software developers must try to have no security-relevant -mistakes anywhere in their code, while attackers only need to find one. -Developers are primarily paid to get their programs to work... attackers -don't need to make the program work, they only need to find a single -weakness. And as I'll describe in a moment, it takes less information to -attack a program than to modify one. - -Generally attackers (against both open and closed programs) start by knowing -about the general kinds of security problems programs have. There's no point -in hiding this information; it's already out, and in any case, defenders need -that kind of information to defend themselves. Attackers then use techniques -to try to find those problems; I'll group the techniques into ``dynamic'' -techniques (where you run the program) and ``static'' techniques (where you -examine the program's code - be it source code or machine code). - -In ``dynamic'' approaches, an attacker runs the program, sending it data -(often problematic data), and sees if the programs' response indicates a -common vulnerability. Open and closed programs have no difference here, since -the attacker isn't looking at code. Attackers may also look at the code, the -``static'' approach. For open source software, they'll probably look at the -source code and search it for patterns. For closed source software, they -might search the machine code (usually presented in assembly language format -to simplify the task) for essentially the same patterns. They might also use -tools called ``decompilers'' that turn the machine code back into source code -and then search the source code for the vulnerable patterns (the same way -they would search for vulnerabilities in open source software). See Flake -[2001] for one discussion of how closed code can still be examined for -security vulnerabilities (e.g., using disassemblers). This point is -important: even if an attacker wanted to use source code to find a -vulnerability, a closed source program has no advantage, because the attacker -can use a disassembler to re-create the source code of the product. - -Non-developers might ask ``if decompilers can create source code from machine -code, then why do developers say they need source code instead of just -machine code?'' The problem is that although developers don't need source -code to find security problems, developers do need source code to make -substantial improvements to the program. Although decompilers can turn -machine code back into a ``source code'' of sorts, the resulting source code -is extremely hard to modify. Typically most understandable names are lost, so -instead of variables like ``grand_total'' you get ``x123123'', instead of -methods like ``display_warning'' you get ``f123124'', and the code itself may -have spatterings of assembly in it. Also, _ALL_ comments and design -information are lost. This isn't a serious problem for finding security -problems, because generally you're searching for patterns indicating -vulnerabilities, not for internal variable or method names. Thus, decompilers -can be useful for finding ways to attack programs, but aren't helpful for -updating programs. - -Thus, developers will say ``source code is vital'' when they intend to add -functionality), but the fact that the source code for closed source programs -is hidden doesn't protect the program very much. ------------------------------------------------------------------------------ - -2.4.3. Why Keeping Vulnerabilities Secret Doesn't Make Them Go Away - -Sometimes it's noted that a vulnerability that exists but is unknown can't be -exploited, so the system ``practically secure.'' In theory this is true, but -the problem is that once someone finds the vulnerability, the finder may just -exploit the vulnerability instead of helping to fix it. Having unknown -vulnerabilities doesn't really make the vulnerabilities go away; it simply -means that the vulnerabilities are a time bomb, with no way to know when -they'll be exploited. Fundamentally, the problem of someone exploiting a -vulnerability they discover is a problem for both open and closed source -systems. - -One related claim sometimes made (though not as directly related to OSS/FS) -is that people should not post warnings about vulnerabilities and discuss -them. This sounds good in theory, but the problem is that attackers already -distribute information about vulnerabilities through a large number of -channels. In short, such approaches would leave defenders vulnerable, while -doing nothing to inhibit attackers. In the past, companies actively tried to -prevent disclosure of vulnerabilities, but experience showed that, in -general, companies didn't fix vulnerabilities until they were widely known to -their users (who could then insist that the vulnerabilities be fixed). This -is all part of the argument for ``full disclosure.'' Gartner Group has a -blunt commentary in a CNET.com article titled ``Commentary: Hype is the real -issue - Tech News.'' They stated: - - - The comments of Microsoft's Scott Culp, manager of the company's security - response center, echo a common refrain in a long, ongoing battle over - information. Discussions of morality regarding the distribution of - information go way back and are very familiar. Several centuries ago, for - example, the church tried to squelch Copernicus' and Galileo's theory of - the sun being at the center of the solar system... Culp's attempt to - blame "information security professionals" for the recent spate of - vulnerabilities in Microsoft products is at best disingenuous. Perhaps, - it also represents an attempt to deflect criticism from the company that - built those products... [The] efforts of all parties contribute to a - continuous process of improvement. The more widely vulnerabilities become - known, the more quickly they get fixed. - - ------------------------------------------------------------------------------ - -2.4.4. How OSS/FS Counters Trojan Horses - -It's sometimes argued that open source programs, because there's no enforced -control by a single company, permit people to insert Trojan Horses and other -malicious code. Trojan horses can be inserted into open source code, true, -but they can also be inserted into proprietary code. A disgruntled or bribed -employee can insert malicious code, and in many organizations it's much less -likely to be found than in an open source program. After all, no one outside -the organization can review the source code, and few companies review their -code internally (or, even if they do, few can be assured that the reviewed -code is actually what is used). And the notion that a closed-source company -can be sued later has little evidence; nearly all licenses disclaim all -warranties, and courts have generally not held software development companies -liable. - -Borland's InterBase server is an interesting case in point. Some time between -1992 and 1994, Borland inserted an intentional ``back door'' into their -database server, ``InterBase''. This back door allowed any local or remote -user to manipulate any database object and install arbitrary programs, and in -some cases could lead to controlling the machine as ``root''. This -vulnerability stayed in the product for at least 6 years - no one else could -review the product, and Borland had no incentive to remove the vulnerability. -Then Borland released its source code on July 2000. The "Firebird" project -began working with the source code, and uncovered this serious security -problem with InterBase in December 2000. By January 2001 the CERT announced -the existence of this back door as CERT advisory CA-2001-01. What's -discouraging is that the backdoor can be easily found simply by looking at an -ASCII dump of the program (a common cracker trick). Once this problem was -found by open source developers reviewing the code, it was patched quickly. -You could argue that, by keeping the password unknown, the program stayed -safe, and that opening the source made the program less secure. I think this -is nonsense, since ASCII dumps are trivial to do and well-known as a standard -attack technique, and not all attackers have sudden urges to announce -vulnerabilities - in fact, there's no way to be certain that this -vulnerability has not been exploited many times. It's clear that after the -source was opened, the source code was reviewed over time, and the -vulnerabilities found and fixed. One way to characterize this is to say that -the original code was vulnerable, its vulnerabilities became easier to -exploit when it was first made open source, and then finally these -vulnerabilities were fixed. ------------------------------------------------------------------------------ - -2.4.5. Other Advantages - -The advantages of having source code open extends not just to software that -is being attacked, but also extends to vulnerability assessment scanners. -Vulnerability assessment scanners intentionally look for vulnerabilities in -configured systems. A recent Network Computing evaluation found that the best -scanner (which, among other things, found the most legitimate -vulnerabilities) was Nessus, an open source scanner [Forristal 2001]. ------------------------------------------------------------------------------ - -2.4.6. Bottom Line - -So, what's the bottom line? I personally believe that when a program began as -closed source and is then first made open source, it often starts less secure -for any users (through exposure of vulnerabilities), and over time (say a few -years) it has the potential to be much more secure than a closed program. If -the program began as open source software, the public scrutiny is more likely -to improve its security before it's ready for use by significant numbers of -users, but there are several caveats to this statement (it's not an ironclad -rule). Just making a program open source doesn't suddenly make a program -secure, and just because a program is open source does not guarantee -security: - -  * First, people have to actually review the code. This is one of the key - points of debate - will people really review code in an open source - project? All sorts of factors can reduce the amount of review: being a - niche or rarely-used product (where there are few potential reviewers), - having few developers, and use of a rarely-used computer language. - Clearly, a program that has a single developer and no other contributors - of any kind doesn't have this kind of review. On the other hand, a - program that has a primary author and many other people who occasionally - examine the code and contribute suggests that there are others reviewing - the code (at least to create contributions). In general, if there are - more reviewers, there's generally a higher likelihood that someone will - identify a flaw - this is the basis of the ``many eyeballs'' theory. Note - that, for example, the OpenBSD project continuously examines programs for - security flaws, so the components in its innermost parts have certainly - undergone a lengthy review. Since OSS/FS discussions are often held - publicly, this level of review is something that potential users can - judge for themselves. - - One factor that can particularly reduce review likelihood is not actually - being open source. Some vendors like to posture their ``disclosed - source'' (also called ``source available'') programs as being open - source, but since the program owner has extensive exclusive rights, - others will have far less incentive to work ``for free'' for the owner on - the code. Even open source licenses which have unusually asymmetric - rights (such as the MPL) have this problem. After all, people are less - likely to voluntarily participate if someone else will have rights to - their results that they don't have (as Bruce Perens says, ``who wants to - be someone else's unpaid employee?''). In particular, since the reviewers - with the most incentive tend to be people trying to modify the program, - this disincentive to participate reduces the number of ``eyeballs''. - Elias Levy made this mistake in his article about open source security; - his examples of software that had been broken into (e.g., TIS's Gauntlet) - were not, at the time, open source. - -  * Second, at least some of the people developing and reviewing the code - must know how to write secure programs. Hopefully the existence of this - book will help. Clearly, it doesn't matter if there are ``many eyeballs'' - if none of the eyeballs know what to look for. Note that it's not - necessary for everyone to know how to write secure programs, as long as - those who do know how are examining the code changes. - -  * Third, once found, these problems need to be fixed quickly and their - fixes distributed. Open source systems tend to fix the problems quickly, - but the distribution is not always smooth. For example, the OpenBSD - developers do an excellent job of reviewing code for security flaws - but - they don't always report the identified problems back to the original - developer. Thus, it's quite possible for there to be a fixed version in - one system, but for the flaw to remain in another. I believe this problem - is lessening over time, since no one ``downstream'' likes to repeatedly - fix the same problem. Of course, ensuring that security patches are - actually installed on end-user systems is a problem for both open source - and closed source software. - - -Another advantage of open source is that, if you find a problem, you can fix -it immediately. This really doesn't have any counterpart in closed source. - -In short, the effect on security of open source software is still a major -debate in the security community, though a large number of prominent experts -believe that it has great potential to be more secure. ------------------------------------------------------------------------------ - -2.5. Types of Secure Programs - -Many different types of programs may need to be secure programs (as the term -is defined in this book). Some common types are: - -  * Application programs used as viewers of remote data. Programs used as - viewers (such as word processors or file format viewers) are often asked - to view data sent remotely by an untrusted user (this request may be - automatically invoked by a web browser). Clearly, the untrusted user's - input should not be allowed to cause the application to run arbitrary - programs. It's usually unwise to support initialization macros (run when - the data is displayed); if you must, then you must create a secure - sandbox (a complex and error-prone task that almost never succeeds, which - is why you shouldn't support macros in the first place). Be careful of - issues such as buffer overflow, discussed in Chapter 6, which might allow - an untrusted user to force the viewer to run an arbitrary program. - -  * Application programs used by the administrator (root). Such programs - shouldn't trust information that can be controlled by non-administrators. - -  * Local servers (also called daemons). - -  * Network-accessible servers (sometimes called network daemons). - -  * Web-based applications (including CGI scripts). These are a special case - of network-accessible servers, but they're so common they deserve their - own category. Such programs are invoked indirectly via a web server, - which filters out some attacks but nevertheless leaves many attacks that - must be withstood. - -  * Applets (i.e., programs downloaded to the client for automatic - execution). This is something Java is especially famous for, though other - languages (such as Python) support mobile code as well. There are several - security viewpoints here; the implementer of the applet infrastructure on - the client side has to make sure that the only operations allowed are - ``safe'' ones, and the writer of an applet has to deal with the problem - of hostile hosts (in other words, you can't normally trust the client). - There is some research attempting to deal with running applets on hostile - hosts, but frankly I'm skeptical of the value of these approaches and - this subject is exotic enough that I don't cover it further here. - -  * setuid/setgid programs. These programs are invoked by a local user and, - when executed, are immediately granted the privileges of the program's - owner and/or owner's group. In many ways these are the hardest programs - to secure, because so many of their inputs are under the control of the - untrusted user and some of those inputs are not obvious. - - - - -This book merges the issues of these different types of program into a single -set. The disadvantage of this approach is that some of the issues identified -here don't apply to all types of programs. In particular, setuid/setgid -programs have many surprising inputs and several of the guidelines here only -apply to them. However, things are not so clear-cut, because a particular -program may cut across these boundaries (e.g., a CGI script may be setuid or -setgid, or be configured in a way that has the same effect), and some -programs are divided into several executables each of which can be considered -a different ``type'' of program. The advantage of considering all of these -program types together is that we can consider all issues without trying to -apply an inappropriate category to a program. As will be seen, many of the -principles apply to all programs that need to be secured. - -There is a slight bias in this book toward programs written in C, with some -notes on other languages such as C++, Perl, PHP, Python, Ada95, and Java. -This is because C is the most common language for implementing secure -programs on Unix-like systems (other than CGI scripts, which tend to use -languages such as Perl, PHP, or Python). Also, most other languages' -implementations call the C library. This is not to imply that C is somehow -the ``best'' language for this purpose, and most of the principles described -here apply regardless of the programming language used. ------------------------------------------------------------------------------ - -2.6. Paranoia is a Virtue - -The primary difficulty in writing secure programs is that writing them -requires a different mind-set, in short, a paranoid mind-set. The reason is -that the impact of errors (also called defects or bugs) can be profoundly -different. - -Normal non-secure programs have many errors. While these errors are -undesirable, these errors usually involve rare or unlikely situations, and if -a user should stumble upon one they will try to avoid using the tool that way -in the future. - -In secure programs, the situation is reversed. Certain users will -intentionally search out and cause rare or unlikely situations, in the hope -that such attacks will give them unwarranted privileges. As a result, when -writing secure programs, paranoia is a virtue. ------------------------------------------------------------------------------ - -2.7. Why Did I Write This Document? - -One question I've been asked is ``why did you write this book''? Here's my -answer: Over the last several years I've noticed that many developers for -Linux and Unix seem to keep falling into the same security pitfalls, again -and again. Auditors were slowly catching problems, but it would have been -better if the problems weren't put into the code in the first place. I -believe that part of the problem was that there wasn't a single, obvious -place where developers could go and get information on how to avoid known -pitfalls. The information was publicly available, but it was often hard to -find, out-of-date, incomplete, or had other problems. Most such information -didn't particularly discuss Linux at all, even though it was becoming widely -used! That leads up to the answer: I developed this book in the hope that -future software developers won't repeat past mistakes, resulting in more -secure systems. You can see a larger discussion of this at [http:// -www.linuxsecurity.com/feature_stories/feature_story-6.html] http:// -www.linuxsecurity.com/feature_stories/feature_story-6.html. - -A related question that could be asked is ``why did you write your own book -instead of just referring to other documents''? There are several answers: - -  * Much of this information was scattered about; placing the critical - information in one organized document makes it easier to use. - -  * Some of this information is not written for the programmer, but is - written for an administrator or user. - -  * Much of the available information emphasizes portable constructs - (constructs that work on all Unix-like systems), and failed to discuss - Linux at all. It's often best to avoid Linux-unique abilities for - portability's sake, but sometimes the Linux-unique abilities can really - aid security. Even if non-Linux portability is desired, you may want to - support the Linux-unique abilities when running on Linux. And, by - emphasizing Linux, I can include references to information that is - helpful to someone targeting Linux that is not necessarily true for - others. - - - ------------------------------------------------------------------------------ - -2.8. Sources of Design and Implementation Guidelines - -Several documents help describe how to write secure programs (or, -alternatively, how to find security problems in existing programs), and were -the basis for the guidelines highlighted in the rest of this book. - -For general-purpose servers and setuid/setgid programs, there are a number of -valuable documents (though some are difficult to find without having a -reference to them). - -Matt Bishop [1996, 1997] has developed several extremely valuable papers and -presentations on the topic, and in fact he has a web page dedicated to the -topic at [http://olympus.cs.ucdavis.edu/~bishop/secprog.html] http:// -olympus.cs.ucdavis.edu/~bishop/secprog.html. AUSCERT has released a -programming checklist [ftp://ftp.auscert.org.au/pub/auscert/papers/ -secure_programming_checklist] [AUSCERT 1996], based in part on chapter 23 of -Garfinkel and Spafford's book discussing how to write secure SUID and network -programs [http://www.oreilly.com/catalog/puis] [Garfinkel 1996]. [http:// -www.sunworld.com/swol-04-1998/swol-04-security.html] Galvin [1998a] described -a simple process and checklist for developing secure programs; he later -updated the checklist in [http://www.sunworld.com/sunworldonline/swol-08-1998 -/swol-08-security.html] Galvin [1998b]. [http://www.pobox.com/~kragen/ -security-holes.html] Sitaker [1999] presents a list of issues for the ``Linux -security audit'' team to search for. [http://www.homeport.org/~adam/ -review.html] Shostack [1999] defines another checklist for reviewing -security-sensitive code. The NCSA [http://www.ncsa.uiuc.edu/General/Grid/ACES -/security/programming] [NCSA] provides a set of terse but useful secure -programming guidelines. Other useful information sources include the Secure -Unix Programming FAQ [http://www.whitefang.com/sup/] [Al-Herbish 1999], the -Security-Audit's Frequently Asked Questions [http://lsap.org/faq.txt] [Graham -1999], and [http://www.clark.net/pub/mjr/pubs/pdf/] Ranum [1998]. Some -recommendations must be taken with caution, for example, the BSD setuid(7) -man page [http://www.homeport.org/~adam/setuid.7.html] [Unknown] recommends -the use of access(3) without noting the dangerous race conditions that -usually accompany it. Wood [1985] has some useful but dated advice in its -``Security for Programmers'' chapter. [http://www.research.att.com/~smb/ -talks] Bellovin [1994] includes useful guidelines and some specific examples, -such as how to restructure an ftpd implementation to be simpler and more -secure. FreeBSD provides some guidelines [http://www.freebsd.org/security/ -security.html] FreeBSD [1999] [http://developer.gnome.org/doc/guides/ -programming-guidelines/book1.html] [Quintero 1999] is primarily concerned -with GNOME programming guidelines, but it includes a section on security -considerations. [http://www.fish.com/security/murphy.html] [Venema 1996] -provides a detailed discussion (with examples) of some common errors when -programming secure programs (widely-known or predictable passwords, burning -yourself with malicious data, secrets in user-accessible data, and depending -on other programs). [http://www.fish.com/security/maldata.html] [Sibert 1996] -describes threats arising from malicious data. Michael Bacarella's article -[http://m.bacarella.com/papers/secsoft/html] The Peon's Guide To Secure -System Development provides a nice short set of guidelines. - -There are many documents giving security guidelines for programs using the -Common Gateway Interface (CGI) to interface with the web. These include -[http://www.csclub.uwaterloo.ca/u/mlvanbie/cgisec] Van Biesbrouck [1996], -[http://language.perl.com/CPAN/doc/FAQs/cgi/perl-cgi-faq.html] Gundavaram -[unknown], [http://webreview.com/wr/pub/97/08/08/bookshelf] [Garfinkle 1997] -[http://www.eekim.com/pubs/cgibook] Kim [1996], [http://www.go2net.com/people -/paulp/cgi-security/safe-cgi.txt] Phillips [1995], [http://www.w3.org/ -Security/Faq/www-security-faq.html] Stein [1999], [http://members.home.net/ -razvan.peteanu] [Peteanu 2000], and [http://advosys.ca/tips/ -web-security.html] [Advosys 2000]. - -There are many documents specific to a language, which are further discussed -in the language-specific sections of this book. For example, the Perl -distribution includes [http://www.perl.com/pub/doc/manual/html/pod/ -perlsec.html] perlsec(1), which describes how to use Perl more securely. The -Secure Internet Programming site at [http://www.cs.princeton.edu/sip] http:// -www.cs.princeton.edu/sip is interested in computer security issues in -general, but focuses on mobile code systems such as Java, ActiveX, and -JavaScript; Ed Felten (one of its principles) co-wrote a book on securing -Java ([http://www.securingjava.com] [McGraw 1999]) which is discussed in -Section 10.6. Sun's security code guidelines provide some guidelines -primarily for Java and C; it is available at [http://java.sun.com/security/ -seccodeguide.html] http://java.sun.com/security/seccodeguide.html. - -Yoder [1998] contains a collection of patterns to be used when dealing with -application security. It's not really a specific set of guidelines, but a set -of commonly-used patterns for programming that you may find useful. The -Schmoo group maintains a web page linking to information on how to write -secure code at [http://www.shmoo.com/securecode] http://www.shmoo.com/ -securecode. - -There are many documents describing the issue from the other direction (i.e., -``how to crack a system''). One example is McClure [1999], and there's -countless amounts of material from that vantage point on the Internet. There -are also more general documents on computer architectures on how attacks must -be developed to exploit them, e.g., [LSD 2001]. The Honeynet Project has been -collecting information (including statistics) on how attackers actually -perform their attacks; see their website at [http://project.honeynet.org] -http://project.honeynet.org for more information. - -There's also a large body of information on vulnerabilities already -identified in existing programs. This can be a useful set of examples of -``what not to do,'' though it takes effort to extract more general guidelines -from the large body of specific examples. There are mailing lists that -discuss security issues; one of the most well-known is [http:// -SecurityFocus.com/forums/bugtraq/faq.html] Bugtraq, which among other things -develops a list of vulnerabilities. The CERT Coordination Center (CERT/CC) is -a major reporting center for Internet security problems which reports on -vulnerabilities. The CERT/CC occasionally produces advisories that provide a -description of a serious security problem and its impact, along with -instructions on how to obtain a patch or details of a workaround; for more -information see [http://www.cert.org] http://www.cert.org. Note that -originally the CERT was a small computer emergency response team, but -officially ``CERT'' doesn't stand for anything now. The Department of -Energy's Computer Incident Advisory Capability (CIAC) also reports on -vulnerabilities. These different groups may identify the same vulnerabilities -but use different names. To resolve this problem, MITRE supports the Common -Vulnerabilities and Exposures (CVE) list which creates a single unique -identifier (``name'') for all publicly known vulnerabilities and security -exposures identified by others; see [http://www.cve.mitre.org] http:// -www.cve.mitre.org. NIST's ICAT is a searchable catalog of computer -vulnerabilities, categorizing each CVE vulnerability so that they can be -searched and compared later; see [http://csrc.nist.gov/icat] http:// -csrc.nist.gov/icat. - -This book is a summary of what I believe are the most useful and important -guidelines. My goal is a book that a good programmer can just read and then -be fairly well prepared to implement a secure program. No single document can -really meet this goal, but I believe the attempt is worthwhile. My objective -is to strike a balance somewhere between a ``complete list of all possible -guidelines'' (that would be unending and unreadable) and the various -``short'' lists available on-line that are nice and short but omit a large -number of critical issues. When in doubt, I include the guidance; I believe -in that case it's better to make the information available to everyone in -this ``one stop shop'' document. The organization presented here is my own -(every list has its own, different structure), and some of the guidelines -(especially the Linux-unique ones, such as those on capabilities and the -FSUID value) are also my own. Reading all of the referenced documents listed -above as well is highly recommended, though I realize that for many it's -impractical. ------------------------------------------------------------------------------ - -2.9. Other Sources of Security Information - -There are a vast number of web sites and mailing lists dedicated to security -issues. Here are some other sources of security information: - -  * [http://www.securityfocus.com] Securityfocus.com has a wealth of general - security-related news and information, and hosts a number of - security-related mailing lists. See their website for information on how - to subscribe and view their archives. A few of the most relevant mailing - lists on SecurityFocus are: - -   + The ``Bugtraq'' mailing list is, as noted above, a ``full disclosure - moderated mailing list for the detailed discussion and announcement - of computer security vulnerabilities: what they are, how to exploit - them, and how to fix them.'' - -   + The ``secprog'' mailing list is a moderated mailing list for the - discussion of secure software development methodologies and - techniques. I specifically monitor this list, and I coordinate with - its moderator to ensure that resolutions reached in SECPROG (if I - agree with them) are incorporated into this document. - -   + The ``vuln-dev'' mailing list discusses potential or undeveloped - holes. - - -  * IBM's ``developerWorks: Security'' has a library of interesting articles. - You can learn more from [http://www.ibm.com/developer/security] http:// - www.ibm.com/developer/security. - -  * For Linux-specific security information, a good source is [http:// - www.linuxsecurity.com] LinuxSecurity.com. If you're interested in - auditing Linux code, places to see include the Linux Security-Audit - Project FAQ and [http://www.lkap.org] Linux Kernel Auditing Project are - dedicated to auditing Linux code for security issues. - - -Of course, if you're securing specific systems, you should sign up to their -security mailing lists (e.g., Microsoft's, Red Hat's, etc.) so you can be -warned of any security updates. ------------------------------------------------------------------------------ - -2.10. Document Conventions - -System manual pages are referenced in the format name(number), where number -is the section number of the manual. The pointer value that means ``does not -point anywhere'' is called NULL; C compilers will convert the integer 0 to -the value NULL in most circumstances where a pointer is needed, but note that -nothing in the C standard requires that NULL actually be implemented by a -series of all-zero bits. C and C++ treat the character '\0' (ASCII 0) -specially, and this value is referred to as NIL in this book (this is usually -called ``NUL'', but ``NUL'' and ``NULL'' sound identical). Function and -method names always use the correct case, even if that means that some -sentences must begin with a lower case letter. I use the term ``Unix-like'' -to mean Unix, Linux, or other systems whose underlying models are very -similar to Unix; I can't say POSIX, because there are systems such as Windows -2000 that implement portions of POSIX yet have vastly different security -models. - -An attacker is called an ``attacker'', ``cracker'', or ``adversary'', and not -a ``hacker''. Some journalists mistakenly use the word ``hacker'' instead of -``attacker''; this book avoids this misuse, because many Linux and Unix -developers refer to themselves as ``hackers'' in the traditional non-evil -sense of the term. To many Linux and Unix developers, the term ``hacker'' -continues to mean simply an expert or enthusiast, particularly regarding -computers. It is true that some hackers commit malicious or intrusive -actions, but many other hackers do not, and it's unfair to claim that all -hackers perform malicious activities. Many other glossaries and books note -that not all hackers are attackers. For example, the Industry Advisory -Council's Information Assurance (IA) Special Interest Group (SIG)'s [http:// -www.iaconline.org/sig_infoassure.html] Information Assurance Glossary defines -hacker as ``A person who delights in having an intimate understanding of the -internal workings of computers and computer networks. The term is misused in -a negative context where `cracker' should be used.'' The Jargon File has a -[http://www.catb.org/~esr/jargon/html/entry/hacker.html] long and complicate -definition for hacker, starting with ``A person who enjoys exploring the -details of programmable systems and how to stretch their capabilities, as -opposed to most users, who prefer to learn only the minimum necessary.''; it -notes although some people use the term to mean ``A malicious meddler who -tries to discover sensitive information by poking around'', it also states -that this definition is deprecated and that the correct term for this sense -is ``cracker''. - -This book uses the ``new'' or ``logical'' quoting system, instead of the -traditional American quoting system: quoted information does not include any -trailing punctuation if the punctuation is not part of the material being -quoted. While this may cause a minor loss of typographical beauty, the -traditional American system causes extraneous characters to be placed inside -the quotes. These extraneous characters have no effect on prose but can be -disastrous in code or computer commands. I use standard American (not -British) spelling; I've yet to meet an English speaker on any continent who -has trouble with this. ------------------------------------------------------------------------------ - -Chapter 3. Summary of Linux and Unix Security Features - -  Discretion will protect you, and - understanding will guard you. -  Proverbs 2:11 (NIV) - -Before discussing guidelines on how to use Linux or Unix security features, -it's useful to know what those features are from a programmer's viewpoint. -This section briefly describes those features that are widely available on -nearly all Unix-like systems. However, note that there is considerable -variation between different versions of Unix-like systems, and not all -systems have the abilities described here. This chapter also notes some -extensions or features specific to Linux; Linux distributions tend to be -fairly similar to each other from the point-of-view of programming for -security, because they all use essentially the same kernel and C library (and -the GPL-based licenses encourage rapid dissemination of any innovations). It -also notes some of the security-relevant differences between different Unix -implementations, but please note that this isn't an exhaustive list. This -chapter doesn't discuss issues such as implementations of mandatory access -control (MAC) which many Unix-like systems do not implement. If you already -know what those features are, please feel free to skip this section. - -Many programming guides skim briefly over the security-relevant portions of -Linux or Unix and skip important information. In particular, they often -discuss ``how to use'' something in general terms but gloss over the security -attributes that affect their use. Conversely, there's a great deal of -detailed information in the manual pages about individual functions, but the -manual pages sometimes obscure key security issues with detailed discussions -on how to use each individual function. This section tries to bridge that -gap; it gives an overview of the security mechanisms in Linux that are likely -to be used by a programmer, but concentrating specifically on the security -ramifications. This section has more depth than the typical programming -guides, focusing specifically on security-related matters, and points to -references where you can get more details. - -First, the basics. Linux and Unix are fundamentally divided into two parts: -the kernel and ``user space''. Most programs execute in user space (on top of -the kernel). Linux supports the concept of ``kernel modules'', which is -simply the ability to dynamically load code into the kernel, but note that it -still has this fundamental division. Some other systems (such as the HURD) -are ``microkernel'' based systems; they have a small kernel with more limited -functionality, and a set of ``user'' programs that implement the lower-level -functions traditionally implemented by the kernel. - -Some Unix-like systems have been extensively modified to support strong -security, in particular to support U.S. Department of Defense requirements -for Mandatory Access Control (level B1 or higher). This version of this book -doesn't cover these systems or issues; I hope to expand to that in a future -version. More detailed information on some of them is available elsewhere, -for example, details on SGI's ``Trusted IRIX/B'' are available in NSA's Final -Evaluation Reports (FERs). - -When users log in, their usernames are mapped to integers marking their -``UID'' (for ``user id'') and the ``GID''s (for ``group id'') that they are a -member of. UID 0 is a special privileged user (role) traditionally called -``root''; on most Unix-like systems (including Unix) root can overrule most -security checks and is used to administrate the system. On some Unix systems, -GID 0 is also special and permits unrestricted access to resources at the -group level [Gay 2000, 228]; this isn't true on other systems (such as -Linux), but even in those systems group 0 is essentially all-powerful because -so many special system files are owned by group 0. Processes are the only -``subjects'' in terms of security (that is, only processes are active -objects). Processes can access various data objects, in particular filesystem -objects (FSOs), System V Interprocess Communication (IPC) objects, and -network ports. Processes can also set signals. Other security-relevant topics -include quotas and limits, libraries, auditing, and PAM. The next few -subsections detail this. ------------------------------------------------------------------------------ - -3.1. Processes - -In Unix-like systems, user-level activities are implemented by running -processes. Most Unix systems support a ``thread'' as a separate concept; -threads share memory inside a process, and the system scheduler actually -schedules threads. Linux does this differently (and in my opinion uses a -better approach): there is no essential difference between a thread and a -process. Instead, in Linux, when a process creates another process it can -choose what resources are shared (e.g., memory can be shared). The Linux -kernel then performs optimizations to get thread-level speeds; see clone(2) -for more information. It's worth noting that the Linux kernel developers tend -to use the word ``task'', not ``thread'' or ``process'', but the external -documentation tends to use the word process (so I'll use the term ``process'' -here). When programming a multi-threaded application, it's usually better to -use one of the standard thread libraries that hide these differences. Not -only does this make threading more portable, but some libraries provide an -additional level of indirection, by implementing more than one -application-level thread as a single operating system thread; this can -provide some improved performance on some systems for some applications. ------------------------------------------------------------------------------ - -3.1.1. Process Attributes - -Here are typical attributes associated with each process in a Unix-like -system: - -  * RUID, RGID - real UID and GID of the user on whose behalf the process is - running - -  * EUID, EGID - effective UID and GID used for privilege checks (except for - the filesystem) - -  * SUID, SGID - Saved UID and GID; used to support switching permissions - ``on and off'' as discussed below. Not all Unix-like systems support - this, but the vast majority do (including Linux and Solaris); if you want - to check if a given system implements this option in the POSIX standard, - you can use sysconf(2) to determine if _POSIX_SAVED_IDS is in effect. - -  * supplemental groups - a list of groups (GIDs) in which this user has - membership. In the original version 7 Unix, this didn't exist - processes - were only a member of one group at a time, and a special command had to - be executed to change that group. BSD added support for a list of groups - in each process, which is more flexible, and this addition is now widely - implemented (including by Linux and Solaris). - -  * umask - a set of bits determining the default access control settings - when a new filesystem object is created; see umask(2). - -  * scheduling parameters - each process has a scheduling policy, and those - with the default policy SCHED_OTHER have the additional parameters nice, - priority, and counter. See sched_setscheduler(2) for more information. - -  * limits - per-process resource limits (see below). - -  * filesystem root - the process' idea of where the root filesystem ("/") - begins; see chroot(2). - - - - -Here are less-common attributes associated with processes: - -  * FSUID, FSGID - UID and GID used for filesystem access checks; this is - usually equal to the EUID and EGID respectively. This is a Linux-unique - attribute. - -  * capabilities - POSIX capability information; there are actually three - sets of capabilities on a process: the effective, inheritable, and - permitted capabilities. See below for more information on POSIX - capabilities. Linux kernel version 2.2 and greater support this; some - other Unix-like systems do too, but it's not as widespread. - - - - -In Linux, if you really need to know exactly what attributes are associated -with each process, the most definitive source is the Linux source code, in -particular /usr/include/linux/sched.h's definition of task_struct. - -The portable way to create new processes it use the fork(2) call. BSD -introduced a variant called vfork(2) as an optimization technique. The bottom -line with vfork(2) is simple: don't use it if you can avoid it. See Section -8.6 for more information. - -Linux supports the Linux-unique clone(2) call. This call works like fork(2), -but allows specification of which resources should be shared (e.g., memory, -file descriptors, etc.). Various BSD systems implement an rfork() system call -(originally developed in Plan9); it has different semantics but the same -general idea (it also creates a process with tighter control over what is -shared). Portable programs shouldn't use these calls directly, if possible; -as noted earlier, they should instead rely on threading libraries that use -such calls to implement threads. - -This book is not a full tutorial on writing programs, so I will skip -widely-available information handling processes. You can see the -documentation for wait(2), exit(2), and so on for more information. ------------------------------------------------------------------------------ - -3.1.2. POSIX Capabilities - -POSIX capabilities are sets of bits that permit splitting of the privileges -typically held by root into a larger set of more specific privileges. POSIX -capabilities are defined by a draft IEEE standard; they're not unique to -Linux but they're not universally supported by other Unix-like systems -either. Linux kernel 2.0 did not support POSIX capabilities, while version -2.2 added support for POSIX capabilities to processes. When Linux -documentation (including this one) says ``requires root privilege'', in -nearly all cases it really means ``requires a capability'' as documented in -the capability documentation. If you need to know the specific capability -required, look it up in the capability documentation. - -In Linux, the eventual intent is to permit capabilities to be attached to -files in the filesystem; as of this writing, however, this is not yet -supported. There is support for transferring capabilities, but this is -disabled by default. Linux version 2.2.11 added a feature that makes -capabilities more directly useful, called the ``capability bounding set''. -The capability bounding set is a list of capabilities that are allowed to be -held by any process on the system (otherwise, only the special init process -can hold it). If a capability does not appear in the bounding set, it may not -be exercised by any process, no matter how privileged. This feature can be -used to, for example, disable kernel module loading. A sample tool that takes -advantage of this is LCAP at [http://pweb.netcom.com/~spoon/lcap/] http:// -pweb.netcom.com/~spoon/lcap/. - -More information about POSIX capabilities is available at [ftp:// -linux.kernel.org/pub/linux/libs/security/linux-privs] ftp://linux.kernel.org/ -pub/linux/libs/security/linux-privs. ------------------------------------------------------------------------------ - -3.1.3. Process Creation and Manipulation - -Processes may be created using fork(2), the non-recommended vfork(2), or the -Linux-unique clone(2); all of these system calls duplicate the existing -process, creating two processes out of it. A process can execute a different -program by calling execve(2), or various front-ends to it (for example, see -exec(3), system(3), and popen(3)). - -When a program is executed, and its file has its setuid or setgid bit set, -the process' EUID or EGID (respectively) is usually set to the file's value. -This functionality was the source of an old Unix security weakness when used -to support setuid or setgid scripts, due to a race condition. Between the -time the kernel opens the file to see which interpreter to run, and when the -(now-set-id) interpreter turns around and reopens the file to interpret it, -an attacker might change the file (directly or via symbolic links). - -Different Unix-like systems handle the security issue for setuid scripts in -different ways. Some systems, such as Linux, completely ignore the setuid and -setgid bits when executing scripts, which is clearly a safe approach. Most -modern releases of SysVr4 and BSD 4.4 use a different approach to avoid the -kernel race condition. On these systems, when the kernel passes the name of -the set-id script to open to the interpreter, rather than using a pathname -(which would permit the race condition) it instead passes the filename /dev/ -fd/3. This is a special file already opened on the script, so that there can -be no race condition for attackers to exploit. Even on these systems I -recommend against using the setuid/setgid shell scripts language for secure -programs, as discussed below. - -In some cases a process can affect the various UID and GID values; see setuid -(2), seteuid(2), setreuid(2), and the Linux-unique setfsuid(2). In particular -the saved user id (SUID) attribute is there to permit trusted programs to -temporarily switch UIDs. Unix-like systems supporting the SUID use the -following rules: If the RUID is changed, or the EUID is set to a value not -equal to the RUID, the SUID is set to the new EUID. Unprivileged users can -set their EUID from their SUID, the RUID to the EUID, and the EUID to the -RUID. - -The Linux-unique FSUID process attribute is intended to permit programs like -the NFS server to limit themselves to only the filesystem rights of some -given UID without giving that UID permission to send signals to the process. -Whenever the EUID is changed, the FSUID is changed to the new EUID value; the -FSUID value can be set separately using setfsuid(2), a Linux-unique call. -Note that non-root callers can only set FSUID to the current RUID, EUID, -SEUID, or current FSUID values. ------------------------------------------------------------------------------ - -3.2. Files - -On all Unix-like systems, the primary repository of information is the file -tree, rooted at ``/''. The file tree is a hierarchical set of directories, -each of which may contain filesystem objects (FSOs). - -In Linux, filesystem objects (FSOs) may be ordinary files, directories, -symbolic links, named pipes (also called first-in first-outs or FIFOs), -sockets (see below), character special (device) files, or block special -(device) files (in Linux, this list is given in the find(1) command). Other -Unix-like systems have an identical or similar list of FSO types. - -Filesystem objects are collected on filesystems, which can be mounted and -unmounted on directories in the file tree. A filesystem type (e.g., ext2 and -FAT) is a specific set of conventions for arranging data on the disk to -optimize speed, reliability, and so on; many people use the term -``filesystem'' as a synonym for the filesystem type. ------------------------------------------------------------------------------ - -3.2.1. Filesystem Object Attributes - -Different Unix-like systems support different filesystem types. Filesystems -may have slightly different sets of access control attributes and access -controls can be affected by options selected at mount time. On Linux, the -ext2 filesystems is currently the most popular filesystem, but Linux supports -a vast number of filesystems. Most Unix-like systems tend to support multiple -filesystems too. - -Most filesystems on Unix-like systems store at least the following: - -  * owning UID and GID - identifies the ``owner'' of the filesystem object. - Only the owner or root can change the access control attributes unless - otherwise noted. - -  * permission bits - read, write, execute bits for each of user (owner), - group, and other. For ordinary files, read, write, and execute have their - typical meanings. In directories, the ``read'' permission is necessary to - display a directory's contents, while the ``execute'' permission is - sometimes called ``search'' permission and is necessary to actually enter - the directory to use its contents. In a directory ``write'' permission on - a directory permits adding, removing, and renaming files in that - directory; if you only want to permit adding, set the sticky bit noted - below. Note that the permission values of symbolic links are never used; - it's only the values of their containing directories and the linked-to - file that matter. - -  * ``sticky'' bit - when set on a directory, unlinks (removes) and renames - of files in that directory are limited to the file owner, the directory - owner, or root privileges. This is a very common Unix extension and is - specified in the Open Group's Single Unix Specification version 2. Old - versions of Unix called this the ``save program text'' bit and used this - to indicate executable files that should stay in memory. Systems that did - this ensured that only root could set this bit (otherwise users could - have crashed systems by forcing ``everything'' into memory). In Linux, - this bit has no effect on ordinary files and ordinary users can modify - this bit on the files they own: Linux's virtual memory management makes - this old use irrelevant. - -  * setuid, setgid - when set on an executable file, executing the file will - set the process' effective UID or effective GID to the value of the - file's owning UID or GID (respectively). All Unix-like systems support - this. In Linux and System V systems, when setgid is set on a file that - does not have any execute privileges, this indicates a file that is - subject to mandatory locking during access (if the filesystem is mounted - to support mandatory locking); this overload of meaning surprises many - and is not universal across Unix-like systems. In fact, the Open Group's - Single Unix Specification version 2 for chmod(3) permits systems to - ignore requests to turn on setgid for files that aren't executable if - such a setting has no meaning. In Linux and Solaris, when setgid is set - on a directory, files created in the directory will have their GID - automatically reset to that of the directory's GID. The purpose of this - approach is to support ``project directories'': users can save files into - such specially-set directories and the group owner automatically changes. - However, setting the setgid bit on directories is not specified by - standards such as the Single Unix Specification [Open Group 1997]. - -  * timestamps - access and modification times are stored for each filesystem - object. However, the owner is allowed to set these values arbitrarily - (see touch(1)), so be careful about trusting this information. All - Unix-like systems support this. - - - - -The following attributes are Linux-unique extensions on the ext2 filesystem, -though many other filesystems have similar functionality: - -  * immutable bit - no changes to the filesystem object are allowed; only - root can set or clear this bit. This is only supported by ext2 and is not - portable across all Unix systems (or even all Linux filesystems). - -  * append-only bit - only appending to the filesystem object are allowed; - only root can set or clear this bit. This is only supported by ext2 and - is not portable across all Unix systems (or even all Linux filesystems). - - - - -Other common extensions include some sort of bit indicating ``cannot delete -this file''. - -Many of these values can be influenced at mount time, so that, for example, -certain bits can be treated as though they had a certain value (regardless of -their values on the media). See mount(1) for more information about this. -These bits are useful, but be aware that some of these are intended to -simplify ease-of-use and aren't really sufficient to prevent certain actions. -For example, on Linux, mounting with ``noexec'' will disable execution of -programs on that file system; as noted in the manual, it's intended for -mounting filesystems containing binaries for incompatible systems. On Linux, -this option won't completely prevent someone from running the files; they can -copy the files somewhere else to run them, or even use the command ``/lib/ -ld-linux.so.2'' to run the file directly. - -Some filesystems don't support some of these access control values; again, -see mount(1) for how these filesystems are handled. In particular, many -Unix-like systems support MS-DOS disks, which by default support very few of -these attributes (and there's not standard way to define these attributes). -In that case, Unix-like systems emulate the standard attributes (possibly -implementing them through special on-disk files), and these attributes are -generally influenced by the mount(1) command. - -It's important to note that, for adding and removing files, only the -permission bits and owner of the file's directory really matter unless the -Unix-like system supports more complex schemes (such as POSIX ACLs). Unless -the system has other extensions, and stock Linux 2.2 doesn't, a file that has -no permissions in its permission bits can still be removed if its containing -directory permits it. Also, if an ancestor directory permits its children to -be changed by some user or group, then any of that directory's descendants -can be replaced by that user or group. - -The draft IEEE POSIX standard on security defines a technique for true ACLs -that support a list of users and groups with their permissions. -Unfortunately, this is not widely supported nor supported exactly the same -way across Unix-like systems. Stock Linux 2.2, for example, has neither ACLs -nor POSIX capability values in the filesystem. - -It's worth noting that in Linux, the Linux ext2 filesystem by default -reserves a small amount of space for the root user. This is a partial defense -against denial-of-service attacks; even if a user fills a disk that is shared -with the root user, the root user has a little space left over (e.g., for -critical functions). The default is 5% of the filesystem space; see mke2fs -(8), in particular its ``-m'' option. ------------------------------------------------------------------------------ - -3.2.2. Creation Time Initial Values - -At creation time, the following rules apply. On most Unix systems, when a new -filesystem object is created via creat(2) or open(2), the FSO UID is set to -the process' EUID and the FSO's GID is set to the process' EGID. Linux works -slightly differently due to its FSUID extensions; the FSO's UID is set to the -process' FSUID, and the FSO GID is set to the process' FSGUID; if the -containing directory's setgid bit is set or the filesystem's ``GRPID'' flag -is set, the FSO GID is actually set to the GID of the containing directory. -Many systems, including Sun Solaris and Linux, also support the setgid -directory extensions. As noted earlier, this special case supports -``project'' directories: to make a ``project'' directory, create a special -group for the project, create a directory for the project owned by that -group, then make the directory setgid: files placed there are automatically -owned by the project. Similarly, if a new subdirectory is created inside a -directory with the setgid bit set (and the filesystem GRPID isn't set), the -new subdirectory will also have its setgid bit set (so that project -subdirectories will ``do the right thing''.); in all other cases the setgid -is clear for a new file. This is the rationale for the ``user-private group'' -scheme (used by Red Hat Linux and some others). In this scheme, every user is -a member of a ``private'' group with just themselves as members, so their -defaults can permit the group to read and write any file (since they're the -only member of the group). Thus, when the file's group membership is -transferred this way, read and write privileges are transferred too. FSO -basic access control values (read, write, execute) are computed from -(requested values & ~ umask of process). New files always start with a clear -sticky bit and clear setuid bit. ------------------------------------------------------------------------------ - -3.2.3. Changing Access Control Attributes - -You can set most of these values with chmod(2), fchmod(2), or chmod(1) but -see also chown(1), and chgrp(1). In Linux, some of the Linux-unique -attributes are manipulated using chattr(1). - -Note that in Linux, only root can change the owner of a given file. Some -Unix-like systems allow ordinary users to transfer ownership of their files -to another, but this causes complications and is forbidden by Linux. For -example, if you're trying to limit disk usage, allowing such operations would -allow users to claim that large files actually belonged to some other -``victim''. ------------------------------------------------------------------------------ - -3.2.4. Using Access Control Attributes - -Under Linux and most Unix-like systems, reading and writing attribute values -are only checked when the file is opened; they are not re-checked on every -read or write. Still, a large number of calls do check these attributes, -since the filesystem is so central to Unix-like systems. Calls that check -these attributes include open(2), creat(2), link(2), unlink(2), rename(2), -mknod(2), symlink(2), and socket(2). ------------------------------------------------------------------------------ - -3.2.5. Filesystem Hierarchy - -Over the years conventions have been built on ``what files to place where''. -Where possible, please follow conventional use when placing information in -the hierarchy. For example, place global configuration information in /etc. -The Filesystem Hierarchy Standard (FHS) tries to define these conventions in -a logical manner, and is widely used by Linux systems. The FHS is an update -to the previous Linux Filesystem Structure standard (FSSTND), incorporating -lessons learned and approaches from Linux, BSD, and System V systems. See -[http://www.pathname.com/fhs] http://www.pathname.com/fhs for more -information about the FHS. A summary of these conventions is in hier(5) for -Linux and hier(7) for Solaris. Sometimes different conventions disagree; -where possible, make these situations configurable at compile or installation -time. - -I should note that the FHS has been adopted by the [http://www.linuxbase.org] -Linux Standard Base which is developing and promoting a set of standards to -increase compatibility among Linux distributions and to enable software -applications to run on any compliant Linux system. ------------------------------------------------------------------------------ - -3.3. System V IPC - -Many Unix-like systems, including Linux and System V systems, support System -V interprocess communication (IPC) objects. Indeed System V IPC is required -by the Open Group's Single UNIX Specification, Version 2 [Open Group 1997]. -System V IPC objects can be one of three kinds: System V message queues, -semaphore sets, and shared memory segments. Each such object has the -following attributes: - -  * read and write permissions for each of creator, creator group, and - others. - -  * creator UID and GID - UID and GID of the creator of the object. - -  * owning UID and GID - UID and GID of the owner of the object (initially - equal to the creator UID). - - - - -When accessing such objects, the rules are as follows: - -  * if the process has root privileges, the access is granted. - -  * if the process' EUID is the owner or creator UID of the object, then the - appropriate creator permission bit is checked to see if access is - granted. - -  * if the process' EGID is the owner or creator GID of the object, or one of - the process' groups is the owning or creating GID of the object, then the - appropriate creator group permission bit is checked for access. - -  * otherwise, the appropriate ``other'' permission bit is checked for - access. - - - - -Note that root, or a process with the EUID of either the owner or creator, -can set the owning UID and owning GID and/or remove the object. More -information is available in ipc(5). ------------------------------------------------------------------------------ - -3.4. Sockets and Network Connections - -Sockets are used for communication, particularly over a network. Sockets were -originally developed by the BSD branch of Unix systems, but they are -generally portable to other Unix-like systems: Linux and System V variants -support sockets as well, and socket support is required by the Open Group's -Single Unix Specification [Open Group 1997]. System V systems traditionally -used a different (incompatible) network communication interface, but it's -worth noting that systems like Solaris include support for sockets. Socket(2) -creates an endpoint for communication and returns a descriptor, in a manner -similar to open(2) for files. The parameters for socket specify the protocol -family and type, such as the Internet domain (TCP/IP version 4), Novell's -IPX, or the ``Unix domain''. A server then typically calls bind(2), listen -(2), and accept(2) or select(2). A client typically calls bind(2) (though -that may be omitted) and connect(2). See these routine's respective man pages -for more information. It can be difficult to understand how to use sockets -from their man pages; you might want to consult other papers such as Hall -"Beej" [1999] to learn how these calls are used together. - -The ``Unix domain sockets'' don't actually represent a network protocol; they -can only connect to sockets on the same machine. (at the time of this writing -for the standard Linux kernel). When used as a stream, they are fairly -similar to named pipes, but with significant advantages. In particular, Unix -domain socket is connection-oriented; each new connection to the socket -results in a new communication channel, a very different situation than with -named pipes. Because of this property, Unix domain sockets are often used -instead of named pipes to implement IPC for many important services. Just -like you can have unnamed pipes, you can have unnamed Unix domain sockets -using socketpair(2); unnamed Unix domain sockets are useful for IPC in a way -similar to unnamed pipes. - -There are several interesting security implications of Unix domain sockets. -First, although Unix domain sockets can appear in the filesystem and can have -stat(2) applied to them, you can't use open(2) to open them (you have to use -the socket(2) and friends interface). Second, Unix domain sockets can be used -to pass file descriptors between processes (not just the file's contents). -This odd capability, not available in any other IPC mechanism, has been used -to hack all sorts of schemes (the descriptors can basically be used as a -limited version of the ``capability'' in the computer science sense of the -term). File descriptors are sent using sendmsg(2), where the msg (message)'s -field msg_control points to an array of control message headers (field -msg_controllen must specify the number of bytes contained in the array). Each -control message is a struct cmsghdr followed by data, and for this purpose -you want the cmsg_type set to SCM_RIGHTS. A file descriptor is retrieved -through recvmsg(2) and then tracked down in the analogous way. Frankly, this -feature is quite baroque, but it's worth knowing about. - -Linux 2.2 and later supports an additional feature in Unix domain sockets: -you can acquire the peer's ``credentials'' (the pid, uid, and gid). Here's -some sample code: - /* fd= file descriptor of Unix domain socket connected - to the client you wish to identify */ - - struct ucred cr; - int cl=sizeof(cr); - - if (getsockopt(fd, SOL_SOCKET, SO_PEERCRED, &cr, &cl)==0) { - printf("Peer's pid=%d, uid=%d, gid=%d\n", - cr.pid, cr.uid, cr.gid); - -Standard Unix convention is that binding to TCP and UDP local port numbers -less than 1024 requires root privilege, while any process can bind to an -unbound port number of 1024 or greater. Linux follows this convention, more -specifically, Linux requires a process to have the capability -CAP_NET_BIND_SERVICE to bind to a port number less than 1024; this capability -is normally only held by processes with an EUID of 0. The adventurous can -check this in Linux by examining its Linux's source; in Linux 2.2.12, it's -file /usr/src/linux/net/ipv4/af_inet.c, function inet_bind(). ------------------------------------------------------------------------------ - -3.5. Signals - -Signals are a simple form of ``interruption'' in the Unix-like OS world, and -are an ancient part of Unix. A process can set a ``signal'' on another -process (say using kill(1) or kill(2)), and that other process would receive -and handle the signal asynchronously. For a process to have permission to -send an arbitrary signal to some other process, the sending process must -either have root privileges, or the real or effective user ID of the sending -process must equal the real or saved set-user-ID of the receiving process. -However, some signals can be sent in other ways. In particular, SIGURG can be -delivered over a network through the TCP/IP out-of-band (OOB) message. - -Although signals are an ancient part of Unix, they've had different semantics -in different implementations. Basically, they involve questions such as -``what happens when a signal occurs while handling another signal''? The -older Linux libc 5 used a different set of semantics for some signal -operations than the newer GNU libc libraries. Calling C library functions is -often unsafe within a signal handler, and even some system calls aren't safe; -you need to examine the documentation for each call you make to see if it -promises to be safe to call inside a signal. For more information, see the -glibc FAQ (on some systems a local copy is available at /usr/doc/glibc-*/ -FAQ). - -For new programs, just use the POSIX signal system (which in turn was based -on BSD work); this set is widely supported and doesn't have some of the -problems that some of the older signal systems did. The POSIX signal system -is based on using the sigset_t datatype, which can be manipulated through a -set of operations: sigemptyset(), sigfillset(), sigaddset(), sigdelset(), and -sigismember(). You can read about these in sigsetops(3). Then use sigaction -(2), sigprocmask(2), sigpending(2), and sigsuspend(2) to set up an manipulate -signal handling (see their man pages for more information). - -In general, make any signal handlers very short and simple, and look -carefully for race conditions. Signals, since they are by nature -asynchronous, can easily cause race conditions. - -A common convention exists for servers: if you receive SIGHUP, you should -close any log files, reopen and reread configuration files, and then re-open -the log files. This supports reconfiguration without halting the server and -log rotation without data loss. If you are writing a server where this -convention makes sense, please support it. - -Michal Zalewski [2001] has written an excellent tutorial on how signal -handlers are exploited, and has recommendations for how to eliminate signal -race problems. I encourage looking at his summary for more information; here -are my recommendations, which are similar to Michal's work: - -  * Where possible, have your signal handlers unconditionally set a specific - flag and do nothing else. - -  * If you must have more complex signal handlers, use only calls - specifically designated as being safe for use in signal handlers. In - particular, don't use malloc() or free() in C (which on most systems - aren't protected against signals), nor the many functions that depend on - them (such as the printf() family and syslog()). You could try to - ``wrap'' calls to insecure library calls with a check to a global flag - (to avoid re-entry), but I wouldn't recommend it. - -  * Block signal delivery during all non-atomic operations in the program, - and block signal delivery inside signal handlers. - - ------------------------------------------------------------------------------ -3.6. Quotas and Limits - -Many Unix-like systems have mechanisms to support filesystem quotas and -process resource limits. This certainly includes Linux. These mechanisms are -particularly useful for preventing denial of service attacks; by limiting the -resources available to each user, you can make it hard for a single user to -use up all the system resources. Be careful with terminology here, because -both filesystem quotas and process resource limits have ``hard'' and ``soft'' -limits but the terms mean slightly different things. - -You can define storage (filesystem) quota limits on each mountpoint for the -number of blocks of storage and/or the number of unique files (inodes) that -can be used, and you can set such limits for a given user or a given group. A -``hard'' quota limit is a never-to-exceed limit, while a ``soft'' quota can -be temporarily exceeded. See quota(1), quotactl(2), and quotaon(8). - -The rlimit mechanism supports a large number of process quotas, such as file -size, number of child processes, number of open files, and so on. There is a -``soft'' limit (also called the current limit) and a ``hard limit'' (also -called the upper limit). The soft limit cannot be exceeded at any time, but -through calls it can be raised up to the value of the hard limit. See -getrlimit(2), setrlimit(2), and getrusage(2), sysconf(3), and ulimit(1). Note -that there are several ways to set these limits, including the PAM module -pam_limits. ------------------------------------------------------------------------------ - -3.7. Dynamically Linked Libraries - -Practically all programs depend on libraries to execute. In most modern -Unix-like systems, including Linux, programs are by default compiled to use -dynamically linked libraries (DLLs). That way, you can update a library and -all the programs using that library will use the new (hopefully improved) -version if they can. - -Dynamically linked libraries are typically placed in one a few special -directories. The usual directories include /lib, /usr/lib, /lib/security for -PAM modules, /usr/X11R6/lib for X-windows, and /usr/local/lib. You should use -these standard conventions in your programs, in particular, except during -debugging you shouldn't use value computed from the current directory as a -source for dynamically linked libraries (an attacker may be able to add their -own choice ``library'' values). - -There are special conventions for naming libraries and having symbolic links -for them, with the result that you can update libraries and still support -programs that want to use old, non-backward-compatible versions of those -libraries. There are also ways to override specific libraries or even just -specific functions in a library when executing a particular program. This is -a real advantage of Unix-like systems over Windows-like systems; I believe -Unix-like systems have a much better system for handling library updates, one -reason that Unix and Linux systems are reputed to be more stable than -Windows-based systems. - -On GNU glibc-based systems, including all Linux systems, the list of -directories automatically searched during program start-up is stored in the -file /etc/ld.so.conf. Many Red Hat-derived distributions don't normally -include /usr/local/lib in the file /etc/ld.so.conf. I consider this a bug, -and adding /usr/local/lib to /etc/ld.so.conf is a common ``fix'' required to -run many programs on Red Hat-derived systems. If you want to just override a -few functions in a library, but keep the rest of the library, you can enter -the names of overriding libraries (.o files) in /etc/ld.so.preload; these -``preloading'' libraries will take precedence over the standard set. This -preloading file is typically used for emergency patches; a distribution -usually won't include such a file when delivered. Searching all of these -directories at program start-up would be too time-consuming, so a caching -arrangement is actually used. The program ldconfig(8) by default reads in the -file /etc/ld.so.conf, sets up the appropriate symbolic links in the dynamic -link directories (so they'll follow the standard conventions), and then -writes a cache to /etc/ld.so.cache that's then used by other programs. So, -ldconfig has to be run whenever a DLL is added, when a DLL is removed, or -when the set of DLL directories changes; running ldconfig is often one of the -steps performed by package managers when installing a library. On start-up, -then, a program uses the dynamic loader to read the file /etc/ld.so.cache and -then load the libraries it needs. - -Various environment variables can control this process, and in fact there are -environment variables that permit you to override this process (so, for -example, you can temporarily substitute a different library for this -particular execution). In Linux, the environment variable LD_LIBRARY_PATH is -a colon-separated set of directories where libraries are searched for first, -before the standard set of directories; this is useful when debugging a new -library or using a nonstandard library for special purposes, but be sure you -trust those who can control those directories. The variable LD_PRELOAD lists -object files with functions that override the standard set, just as /etc/ -ld.so.preload does. The variable LD_DEBUG, displays debugging information; if -set to ``all'', voluminous information about the dynamic linking process is -displayed while it's occurring. - -Permitting user control over dynamically linked libraries would be disastrous -for setuid/setgid programs if special measures weren't taken. Therefore, in -the GNU glibc implementation, if the program is setuid or setgid these -variables (and other similar variables) are ignored or greatly limited in -what they can do. The GNU glibc library determines if a program is setuid or -setgid by checking the program's credentials; if the UID and EUID differ, or -the GID and the EGID differ, the library presumes the program is setuid/ -setgid (or descended from one) and therefore greatly limits its abilities to -control linking. If you load the GNU glibc libraries, you can see this; see -especially the files elf/rtld.c and sysdeps/generic/dl-sysdep.c. This means -that if you cause the UID and GID to equal the EUID and EGID, and then call a -program, these variables will have full effect. Other Unix-like systems -handle the situation differently but for the same reason: a setuid/setgid -program should not be unduly affected by the environment variables set. Note -that graphical user interface toolkits generally do permit user control over -dynamically linked libraries, because executables that directly invoke -graphical user inteface toolkits should never, ever, be setuid (or have other -special privileges) at all. For more about how to develop secure GUI -applications, see Section 7.4.4. - -For Linux systems, you can get more information from my document, the Program -Library HOWTO. ------------------------------------------------------------------------------ - -3.8. Audit - -Different Unix-like systems handle auditing differently. In Linux, the most -common ``audit'' mechanism is syslogd(8), usually working in conjunction with -klogd(8). You might also want to look at wtmp(5), utmp(5), lastlog(8), and -acct(2). Some server programs (such as the Apache web server) also have their -own audit trail mechanisms. According to the FHS, audit logs should be stored -in /var/log or its subdirectories. ------------------------------------------------------------------------------ - -3.9. PAM - -Sun Solaris and nearly all Linux systems use the Pluggable Authentication -Modules (PAM) system for authentication. PAM permits run-time configuration -of authentication methods (e.g., use of passwords, smart cards, etc.). See -Section 11.6 for more information on using PAM. ------------------------------------------------------------------------------ - -3.10. Specialized Security Extensions for Unix-like Systems - -A vast amount of research and development has gone into extending Unix-like -systems to support security needs of various communities. For example, -several Unix-like systems have been extended to support the U.S. military's -desire for multilevel security. If you're developing software, you should try -to design your software so that it can work within these extensions. - -FreeBSD has a new system call, [http://docs.freebsd.org/44doc/papers/jail/ -jail.html] jail(2). The jail system call supports sub-partitioning an -environment into many virtual machines (in a sense, a ``super-chroot''); its -most popular use has been to provide virtual machine services for Internet -Service Provider environments. Inside a jail, all processes (even those owned -by root) have the the scope of their requests limited to the jail. When a -FreeBSD system is booted up after a fresh install, no processes will be in -jail. When a process is placed in a jail, it, and any descendants of that -process created will be in that jail. Once in a jail, access to the file -name-space is restricted in the style of chroot(2) (with typical chroot -escape routes blocked), the ability to bind network resources is limited to a -specific IP address, the ability to manipulate system resources and perform -privileged operations is sharply curtailed, and the ability to interact with -other processes is limited to only processes inside the same jail. Note that -each jail is bound to a single IP address; processes within the jail may not -make use of any other IP address for outgoing or incoming connections. - -Some extensions available in Linux, such as POSIX capabilities and special -mount-time options, have already been discussed. Here are a few of these -efforts for Linux systems for creating restricted execution environments; -there are many different approaches. The U.S. National Security Agency (NSA) -has developed [http://www.nsa.gov/selinux] Security-Enhanced Linux (Flask), -which supports defining a security policy in a specialized language and then -enforces that policy. The [http://medusa.fornax.sk] Medusa DS9 extends Linux -by supporting, at the kernel level, a user-space authorization server. [http: -//www.lids.org] LIDS protects files and processes, allowing administrators to -``lock down'' their system. The ``Rule Set Based Access Control'' system, -[http://www.rsbac.de] RSBAC is based on the Generalized Framework for Access -Control (GFAC) by Abrams and LaPadula and provides a flexible system of -access control based on several kernel modules. [http://subterfugue.org] -Subterfugue is a framework for ``observing and playing with the reality of -software''; it can intercept system calls and change their parameters and/or -change their return values to implement sandboxes, tracers, and so on; it -runs under Linux 2.4 with no changes (it doesn't require any kernel -modifications). [http://www.cs.berkeley.edu/~daw/janus] Janus is a security -tool for sandboxing untrusted applications within a restricted execution -environment. Some have even used [http://user-mode-linux.sourceforge.net] -User-mode Linux, which implements ``Linux on Linux'', as a sandbox -implementation. Because there are so many different approaches to -implementing more sophisticated security models, Linus Torvalds has requested -that a generic approach be developed so different security policies can be -inserted; for more information about this, see [http://mail.wirex.com/mailman -/listinfo/linux-security-module] http://mail.wirex.com/mailman/listinfo/ -linux-security-module. - -There are many other extensions for security on various Unix-like systems, -but these are really outside the scope of this document. ------------------------------------------------------------------------------ - -Chapter 4. Security Requirements - -  You will know that your tent is - secure; you will take stock of your - property and find nothing missing. -  Job 5:24 (NIV) - -Before you can determine if a program is secure, you need to determine -exactly what its security requirements are. Thankfully, there's an -international standard for identifying and defining security requirements -that is useful for many such circumstances: the Common Criteria [CC 1999], -standardized as ISO/IEC 15408:1999. The CC is the culmination of decades of -work to identify information technology security requirements. There are -other schemes for defining security requirements and evaluating products to -see if products meet the requirements, such as NIST FIPS-140 for -cryptographic equipment, but these other schemes are generally focused on a -specialized area and won't be considered further here. - -This chapter briefly describes the Common Criteria (CC) and how to use its -concepts to help you informally identify security requirements and talk with -others about security requirements using standard terminology. The language -of the CC is more precise, but it's also more formal and harder to -understand; hopefully the text in this section will help you "get the jist". - -Note that, in some circumstances, software cannot be used unless it has -undergone a CC evaluation by an accredited laboratory. This includes certain -kinds of uses in the U.S. Department of Defense (as specified by NSTISSP -Number 11, which requires that before some products can be used they must be -evaluated or enter evaluation), and in the future such a requirement may also -include some kinds of uses for software in the U.S. federal government. This -section doesn't provide enough information if you plan to actually go through -a CC evaluation by an accredited laboratory. If you plan to go through a -formal evaluation, you need to read the real CC, examine various websites to -really understand the basics of the CC, and eventually contract a lab -accredited to do a CC evaluation. ------------------------------------------------------------------------------ - -4.1. Common Criteria Introduction - -First, some general information about the CC will help understand how to -apply its concepts. The CC's official name is "The Common Criteria for -Information Technology Security Evaluation", though it's normally just called -the Common Criteria. The CC document has three parts: the introduction (that -describes the CC overall), security functional requirements (that lists -various kinds of security functions that products might want to include), and -security assurance requirements (that lists various methods of assuring that -a product is secure). There is also a related document, the "Common -Evaluation Methodology" (CEM), that guides evaluators how to apply the CC -when doing formal evaluations (in particular, it amplifies what the CC means -in certain cases). - -Although the CC is International Standard ISO/IEC 15408:1999, it is -outrageously expensive to order the CC from ISO. Hopefully someday ISO will -follow the lead of other standards organizations such as the IETF and the -W3C, which freely redistribute standards. Not surprisingly, IETF and W3C -standards are followed more often than many ISO standards, in part because -ISO's fees for standards simply make them inaccessible to most developers. (I -don't mind authors being paid for their work, but ISO doesn't fund most of -the standards development work - indeed, many of the developers of ISO -documents are volunteers - so ISO's indefensible fees only line their own -pockets and don't actually aid the authors or users at all.) Thankfully, the -CC developers anticipated this problem and have made sure that the CC's -technical content is freely available to all; you can download the CC's -technical content from [http://csrc.nist.gov/cc/ccv20/ccv2list.htm] http:// -csrc.nist.gov/cc/ccv20/ccv2list.htm Even those doing formal evaluation -processes usually use these editions of the CC, and not the ISO versions; -there's simply no good reason to pay ISO for them. - -Although it can be used in other ways, the CC is typically used to create two -kinds of documents, a ``Protection Profile'' (PP) or a ``Security Target'' -(ST). A ``protection profile'' (PP) is a document created by group of users -(for example, a consumer group or large organization) that identifies the -desired security properties of a product. Basically, a PP is a list of user -security requirements, described in a very specific way defined by the CC. If -you're building a product similar to other existing products, it's quite -possible that there are one or more PPs that define what some users believe -are necessary for that kind of product (e.g., an operating system or -firewall). A ``security target'' (ST) is a document that identifies what a -product actually does, or a subset of it, that is security-relevant. An ST -doesn't need to meet the requirements of any particular PP, but an ST could -meet the requirements of one or more PPs. - -Both PPs and STs can go through a formal evaluation. An evaluation of a PP -simply ensures that the PP meets various documentation rules and sanity -checks. An ST evaluation involves not just examining the ST document, but -more importantly it involves evaluating an actual system (called the ``target -of evaluation'', or TOE). The purpose of an ST evaluation is to ensure that, -to the level of the assurance requirements specified by the ST, the actual -product (the TOE) meets the ST's security functional requirements. Customers -can then compare evaluated STs to PPs describing what they want. Through this -comparison, consumers can determine if the products meet their requirements - -and if not, where the limitations are. - -To create a PP or ST, you go through a process of identifying the security -environment, namely, your assumptions, threats, and relevant organizational -security policies (if any). From the security environment, you derive the -security objectives for the product or product type. Finally, the security -requirements are selected so that they meet the objectives. There are two -kinds of security requirements: functional requirements (what a product has -to be able to do), and assurance requirements (measures to inspire confidence -that the objectives have been met). Actually creating a PP or ST is often not -a simple straight line as outlined here, but the final result needs to show a -clear relationship so that no critical point is easily overlooked. Even if -you don't plan to write an ST or PP, the ideas in the CC can still be -helpful; the process of identifying the security environment, objectives, and -requirements is still helpful in identifying what's really important. - -The vast majority of the CC's text is used to define standardized functional -requirements and assurance requirements. In essence, the majority of the CC -is a ``chinese menu'' of possible security requirements that someone might -want. PP authors pick from the various options to describe what they want, -and ST authors pick from the options to describe what they provide. - -Since many people might have difficulty identifying a reasonable set of -assurance requirements, so pre-created sets of assurance requirements called -``evaluation assurance levels'' (EALs) have been defined, ranging from 1 to -7. EAL 2 is simply a standard shorthand for the set of assurance requirements -defined for EAL 2. Products can add additional assurance measures, for -example, they might choose EAL 2 plus some additional assurance measures (if -the combination isn't enough to achieve a higher EAL level, such a -combination would be called "EAL 2 plus"). There are mutual recognition -agreements signed between many of the world's nations that will accept an -evaluation done by an accredited laboratory in the other countries as long as -all of the assurance measures taken were at the EAL 4 level or less. - -If you want to actually write an ST or PP, there's an open source software -program that can help you, called the ``CC Toolbox''. It can make sure that -dependencies between requirements are met, suggest common requirements, and -help you quickly develop a document, but it obviously can't do your thinking -for you. The specification of exactly what information must be in a PP or ST -are in CC part 1, annexes B and C respectively. - -If you do decide to have your product (or PP) evaluated by an accredited -laboratory, be prepared to spend money, spend time, and work throughout the -process. In particular, evaluations require paying an accredited lab to do -the evaluation, and higher levels of assurance become rapidly more expensive. -Simply believing your product is secure isn't good enough; evaluators will -require evidence to justify any claims made. Thus, evaluations require -documentation, and usually the available documentation has to be improved or -developed to meet CC requirements (especially at the higher assurance -levels). Every claim has to be justified to some level of confidence, so the -more claims made, the stronger the claims, and the more complicated the -design, the more expensive an evaluation is. Obviously, when flaws are found, -they will usually need to be fixed. Note that a laboratory is paid to -evaluate a product and determine the truth. If the product doesn't meet its -claims, then you basically have two choices: fix the product, or change -(reduce) the claims. - -It's important to discuss with customers what's desired before beginning a -formal ST evaluation; an ST that includes functional or assurance -requirements not truly needed by customers will be unnecessarily expensive to -evaluate, and an ST that omits necessary requirements may not be acceptable -to the customers (because that necessary piece won't have been evaluated). -PPs identify such requirements, but make sure that the PP accurately reflects -the customer's real requirements (perhaps the customer only wants a part of -the functionality or assurance in the PP, or has a different environment in -mind, or wants something else instead for the situations where your product -will be used). Note that an ST need not include every security feature in a -product; an ST only states what will be (or has been) evaluated. A product -that has a higher EAL rating is not necessarily more secure than a similar -product with a lower rating or no rating; the environment might be different, -the evaluation may have saved money and time by not evaluating the other -product at a higher level, or perhaps the evaluation missed something -important. Evaluations are not proofs; they simply impose a defined minimum -bar to gain confidence in the requirements or product. ------------------------------------------------------------------------------ - -4.2. Security Environment and Objectives - -The first step in defining a PP or ST is identify the ``security -environment''. This means that you have to consider the physical environment -(can attackers access the computer hardware?), the assets requiring -protection (files, databases, authorization credentials, and so on), and the -purpose of the TOE (what kind of product is it? what is the intended use?). - -In developing a PP or ST, you'd end up with a statement of assumptions (who -is trusted? is the network or platform benign?), threats (that the system or -its environment must counter), and organizational security policies (that the -system or its environment must meet). A threat is characterized in terms of a -threat agent (who might perform the attack?), a presumed attack method, any -vulnerabilities that are the basis for the attack, and what asset is under -attack. - -You'd then define a set of security objectives for the system and -environment, and show that those objectives counter the threats and satisfy -the policies. Even if you aren't creating a PP or ST, thinking about your -assumptions, threats, and possible policies can help you avoid foolish -decisions. For example, if the computer network you're using can be sniffed -(e.g., the Internet), then unencrypted passwords are a foolish idea in most -circumstances. - -For the CC, you'd then identify the functional and assurance requirements -that would be met by the TOE, and which ones would be met by the environment, -to meet those security objectives. These requirements would be selected from -the ``chinese menu'' of the CC's possible requirements, and the next sections -will briefly describe the major classes of requirements. In the CC, -requirements are grouped into classes, which are subdivided into families, -which are further subdivided into components; the details of all this are in -the CC itself if you need to know about this. A good diagram showing how this -works is in the CC part 1, figure 4.5, which I cannot reproduce here. - -Again, if you're not intending for your product to undergo a CC evaluation, -it's still good to briefly determine this kind of information and informally -write include that information in your documentation (e.g., the man page or -whatever your documentation is). ------------------------------------------------------------------------------ - -4.3. Security Functionality Requirements - -This section briefly describes the CC security functionality requirements (by -CC class), primarily to give you an idea of the kinds of security -requirements you might want in your software. If you want more detail about -the CC's requirements, see CC part 2. Here are the major classes of CC -security requirements, along with the 3-letter CC abbreviation for that -class: - -  * Security Audit (FAU). Perhaps you'll need to recognize, record, store, - and analyze security-relevant activities. You'll need to identify what - you want to make auditable, since often you can't leave all possible - auditing capabilities enabled. Also, consider what to do when there's no - room left for auditing - if you stop the system, an attacker may - intentionally do things to be logged and thus stop the system. - -  * Communication/Non-repudiation (FCO). This class is poorly named in the - CC; officially it's called communication, but the real meaning is - non-repudiation. Is it important that an originator cannot deny having - sent a message, or that a recipient cannot deny having received it? There - are limits to how well technology itself can support non-repudiation - (e.g., a user might be able to give their private key away ahead of time - if they wanted to be able to repudiate something later), but nevertheless - for some applications supporting non-repudiation capabilities is very - useful. - -  * Cryptographic Support (FCS). If you're using cryptography, what - operations use cryptography, what algorithms and key sizes are you using, - and how are you managing their keys (including distribution and - destruction)? - -  * User Data Protection (FDP). This class specifies requirement for - protecting user data, and is a big class in the CC with many families - inside it. The basic idea is that you should specify a policy for data - (access control or information flow rules), develop various means to - implement the policy, possibly support off-line storage, import, and - export, and provide integrity when transferring user data between TOEs. - One often-forgotten issue is residual information protection - is it - acceptable if an attacker can later recover ``deleted'' data? - -  * Identification and authentication (FIA). Generally you don't just want a - user to report who they are (identification) - you need to verify their - identity, a process called authentication. Passwords are the most common - mechanism for authentication. It's often useful to limit the number of - authentication attempts (if you can) and limit the feedback during - authentication (e.g., displaying asterisks instead of the actual - password). Certainly, limit what a user can do before authenticating; in - many cases, don't let the user do anything without authenticating. There - may be many issues controlling when a session can start, but in the CC - world this is handled by the "TOE access" (FTA) class described below - instead. - -  * Security Management (FMT). Many systems will require some sort of - management (e.g., to control who can do what), generally by those who are - given a more trusted role (e.g., administrator). Be sure you think - through what those special operations are, and ensure that only those - with the trusted roles can invoke them. You want to limit trust; ideally, - even more trusted roles should be limited in what they can do. - -  * Privacy (FPR). Do you need to support anonymity, pseudonymity, - unlinkability, or unobservability? If so, are there conditions where you - want or don't want these (e.g., should an administrator be able to - determine the real identity of someone hiding behind a pseudonym?). Note - that these can seriously conflict with non-repudiation, if you want those - too. If you're worried about sophisticated threats, these functions can - be hard to provide. - -  * Protection of the TOE Security Functions/Self-protection (FPT). Clearly, - if the TOE can be subverted, any security functions it provides aren't - worthwhile, and in many cases a TOE has to provide at least some - self-protection. Perhaps you should "test the underlying abstract - machine" - i.e., test that the underlying components meet your - assumptions, or have the product run self-tests (say during start-up, - periodically, or on request). You should probably "fail secure", at least - under certain conditions; determine what those conditions are. Consider - phyical protection of the TOE. You may want some sort of secure recovery - function after a failure. It's often useful to have replay detection - (detect when an attacker is trying to replay older actions) and counter - it. Usually a TOE must make sure that any access checks are always - invoked and actually succeed before performing a restricted action. - -  * Resource Utilization (FRU). Perhaps you need to provide fault tolerance, - a priority of service scheme, or support resource allocation (such as a - quota system). - -  * TOE Access (FTA). There may be many issues controlling sessions. Perhaps - there should be a limit on the number of concurrent sessions (if you're - running a web service, would it make sense for the same user to be logged - in simultaneously, or from two different machines?). Perhaps you should - lock or terminate a session automatically (e.g., after a timeout), or let - users initiate a session lock. You might want to include a standard - warning banner. One surprisingly useful piece of information is - displaying, on login, information about the last session (e.g., the date/ - time and location of the last login) and the date/time of the last - unsuccessful attempt - this gives users information that can help them - detect interlopers. Perhaps sessions can only be established based on - other criteria (e.g., perhaps you can only use the program during - business hours). - -  * Trusted path/channels (FTP). A common trick used by attackers is to make - the screen appear to be something it isn't, e.g., run an ordinary program - that looks like a login screen or a forged web site. Thus, perhaps there - needs to be a "trusted path" - a way that users can ensure that they are - talking to the "real" program. - - - ------------------------------------------------------------------------------ - -4.4. Security Assurance Measure Requirements - -As noted above, the CC has a set of possible assurance requirements that can -be selected, and several predefined sets of assurance requirements (EAL -levels 1 through 7). Again, if you're actually going to go through a CC -evaluation, you should examine the CC documents; I'll skip describing the -measures involving reviewing official CC documents (evaluating PPs and STs). -Here are some assurance measures that can increase the confidence others have -in your software: - -  * Configuration management (ACM). At least, have unique a version - identifier for each TOE release, so that users will know what they have. - You gain more assurance if you have good automated tools to control your - software, and have separate version identifiers for each piece (typical - CM tools like CVS can do this, although CVS doesn't record changes as - atomic changes which is a weakness of it). The more that's under - configuration management, the better; don't just control your code, but - also control documentation, track all problem reports (especially - security-related ones), and all development tools. - -  * Delivery and operation (ADO). Your delivery mechanism should ideally let - users detect unauthorized modifications to prevent someone else - masquerading as the developer, and even better, prevent modification in - the first place. You should provide documentation on how to securely - install, generate, and start-up the TOE, possibly generating a log - describing how the TOE was generated. - -  * Development (ADV). These CC requirements deal with documentation - describing the TOE implementation, and that they need to be consistent - between each other (e.g., the information in the ST, functional - specification, high-level design, low-level design, and code, as well as - any models of the security policy). - -  * Guidance documents (AGD). Users and administrators of your product will - probably need some sort of guidance to help them use it correctly. It - doesn't need to be on paper; on-line help and "wizards" can help too. The - guidance should include warnings about actions that may be a problem in a - secure environemnt, and describe how to use the system securely. - -  * Life-cycle support (ALC). This includes development security (securing - the systems being used for development, including physical security), a - flaw remediation process (to track and correct all security flaws), and - selecting development tools wisely. - -  * Tests (ATE). Simply testing can help, but remember that you need to test - the security functions and not just general functions. You should check - if something is set to permit, it's permitted, and if it's forbidden, it - is no longer permitted. Of course, there may be clever ways to subvert - this, which is what vulnerability assessment is all about (described - next). - -  * Vulnerability Assessment (AVA). Doing a vulnerability analysis is useful, - where someone pretends to be an attacker and tries to find - vulnerabilities in the product using the available information, including - documentation (look for "don't do X" statements and see if an attacker - could exploit them) and publicly known past vulnerabilities of this or - similar products. This book describes various ways of countering known - vulnerabilities of previous products to problems such as replay attacks - (where known-good information is stored and retransmitted), buffer - overflow attacks, race conditions, and other issues that the rest of this - book describes. The user and administrator guidance documents should be - examined to ensure that misleading, unreasonable, or conflicting guidance - is removed, and that secrity procedures for all modes of operation have - been addressed. Specialized systems may need to worry about covert - channels; read the CC if you wish to learn more about covert channels. - -  * Maintenance of assurance (AMA). If you're not going through a CC - evaluation, you don't need a formal AMA process, but all software - undergoes change. What is your process to give all your users strong - confidence that future changes to your software will not create new - vulnerabilities? For example, you could establish a process where - multiple people review any proposed changes. - - ------------------------------------------------------------------------------ -Chapter 5. Validate All Input - -  Wisdom will save you from the ways of - wicked men, from men whose words are - perverse... -  Proverbs 2:12 (NIV) - -Some inputs are from untrustable users, so those inputs must be validated -(filtered) before being used. You should determine what is legal and reject -anything that does not match that definition. Do not do the reverse (identify -what is illegal and write code to reject those cases), because you are likely -to forget to handle an important case of illegal input. - -There is a good reason for identifying ``illegal'' values, though, and that's -as a set of tests (usually just executed in your head) to be sure that your -validation code is thorough. When I set up an input filter, I mentally attack -the filter to see if there are illegal values that could get through. -Depending on the input, here are a few examples of common ``illegal'' values -that your input filters may need to prevent: the empty string, ".", "..", ".. -/", anything starting with "/" or ".", anything with "/" or "&" inside it, -any control characters (especially NIL and newline), and/or any characters -with the ``high bit'' set (especially values decimal 254 and 255, and -character 133 is the Unicode Next-of-line character used by OS/390). Again, -your code should not be checking for ``bad'' values; you should do this check -mentally to be sure that your pattern ruthlessly limits input values to legal -values. If your pattern isn't sufficiently narrow, you need to carefully -re-examine the pattern to see if there are other problems. - -Limit the maximum character length (and minimum length if appropriate), and -be sure to not lose control when such lengths are exceeded (see Chapter 6 for -more about buffer overflows). - -Here are a few common data types, and things you should validate before using -them from an untrusted user: - -  * For strings, identify the legal characters or legal patterns (e.g., as a - regular expression) and reject anything not matching that form. There are - special problems when strings contain control characters (especially - linefeed or NIL) or metacharacters (especially shell metacharacters); it - is often best to ``escape'' such metacharacters immediately when the - input is received so that such characters are not accidentally sent. CERT - goes further and recommends escaping all characters that aren't in a list - of characters not needing escaping [CERT 1998, CMU 1998]. See Section 8.3 - for more information on metacharacters. Note that [http://www.w3.org/TR/ - 2001/NOTE-newline-20010314] line ending encodings vary on different - computers: Unix-based systems use character 0x0a (linefeed), CP/M and DOS - based systems (including Windows) use 0x0d 0x0a (carriage-return - linefeed, and some programs incorrectly reverse the order), the Apple - MacOS uses 0x0d (carriage return), and IBM OS/390 uses 0x85 (0x85) (next - line, sometimes called newline). - -  * Limit all numbers to the minimum (often zero) and maximum allowed values. - -  * A full email address checker is actually quite complicated, because there - are legacy formats that greatly complicate validation if you need to - support all of them; see mailaddr(7) and IETF RFC 822 [RFC 822] for more - information if such checking is necessary. Friedl [1997] developed a - regular expression to check if an email address is valid (according to - the specification); his ``short'' regular expression is 4,724 characters, - and his ``optimized'' expression (in appendix B) is 6,598 characters - long. And even that regular expression isn't perfect; it can't recognize - local email addresses, and it can't handle nested parentheses in comments - (as the specification permits). Often you can simplify and only permit - the ``common'' Internet address formats. - -  * Filenames should be checked; see Section 5.4 for more information on - filenames. - -  * URIs (including URLs) should be checked for validity. If you are directly - acting on a URI (i.e., you're implementing a web server or - web-server-like program and the URL is a request for your data), make - sure the URI is valid, and be especially careful of URIs that try to - ``escape'' the document root (the area of the filesystem that the server - is responding to). The most common ways to escape the document root are - via ``..'' or a symbolic link, so most servers check any ``..'' - directories themselves and ignore symbolic links unless specially - directed. Also remember to decode any encoding first (via URL encoding or - UTF-8 encoding), or an encoded ``..'' could slip through. URIs aren't - supposed to even include UTF-8 encoding, so the safest thing is to reject - any URIs that include characters with high bits set. - - If you are implementing a system that uses the URI/URL as data, you're - not home-free at all; you need to ensure that malicious users can't - insert URIs that will harm other users. See Section 5.11.4 for more - information about this. - -  * When accepting cookie values, make sure to check the the domain value for - any cookie you're using is the expected one. Otherwise, a (possibly - cracked) related site might be able to insert spoofed cookies. Here's an - example from IETF RFC 2965 of how failing to do this check could cause a - problem: - -   + User agent makes request to victim.cracker.edu, gets back cookie - session_id="1234" and sets the default domain victim.cracker.edu. - -   + User agent makes request to spoof.cracker.edu, gets back cookie - session-id="1111", with Domain=".cracker.edu". - -   + User agent makes request to victim.cracker.edu again, and passes: - Cookie: $Version="1"; session_id="1234", - $Version="1"; session_id="1111"; $Domain=".cracker.edu" - The server at victim.cracker.edu should detect that the second cookie - was not one it originated by noticing that the Domain attribute is - not for itself and ignore it. - - - -Unless you account for them, the legal character patterns must not include -characters or character sequences that have special meaning to either the -program internals or the eventual output: - -  * A character sequence may have special meaning to the program's internal - storage format. For example, if you store data (internally or externally) - in delimited strings, make sure that the delimiters are not permitted - data values. A number of programs store data in comma (,) or colon (:) - delimited text files; inserting the delimiters in the input can be a - problem unless the program accounts for it (i.e., by preventing it or - encoding it in some way). Other characters often causing these problems - include single and double quotes (used for surrounding strings) and the - less-than sign "<" (used in SGML, XML, and HTML to indicate a tag's - beginning; this is important if you store data in these formats). Most - data formats have an escape sequence to handle these cases; use it, or - filter such data on input. - -  * A character sequence may have special meaning if sent back out to a user. - A common example of this is permitting HTML tags in data input that will - later be posted to other readers (e.g., in a guestbook or ``reader - comment'' area). However, the problem is much more general. See Section - 7.15 for a general discussion on the topic, and see Section 5.11 for a - specific discussion about filtering HTML. - - -These tests should usually be centralized in one place so that the validity -tests can be easily examined for correctness later. - -Make sure that your validity test is actually correct; this is particularly a -problem when checking input that will be used by another program (such as a -filename, email address, or URL). Often these tests have subtle errors, -producing the so-called ``deputy problem'' (where the checking program makes -different assumptions than the program that actually uses the data). If -there's a relevant standard, look at it, but also search to see if the -program has extensions that you need to know about. - -While parsing user input, it's a good idea to temporarily drop all -privileges, or even create separate processes (with the parser having -permanently dropped privileges, and the other process performing security -checks against the parser requests). This is especially true if the parsing -task is complex (e.g., if you use a lex-like or yacc-like tool), or if the -programming language doesn't protect against buffer overflows (e.g., C and -C++). See Section 7.4 for more information on minimizing privileges. - -When using data for security decisions (e.g., ``let this user in''), be sure -to use trustworthy channels. For example, on a public Internet, don't just -use the machine IP address or port number as the sole way to authenticate -users, because in most environments this information can be set by the -(potentially malicious) user. See Section 7.11 for more information. - -The following subsections discuss different kinds of inputs to a program; -note that input includes process state such as environment variables, umask -values, and so on. Not all inputs are under the control of an untrusted user, -so you need only worry about those inputs that are. ------------------------------------------------------------------------------ - -5.1. Command line - -Many programs take input from the command line. A setuid/setgid program's -command line data is provided by an untrusted user, so a setuid/setgid -program must defend itself from potentially hostile command line values. -Attackers can send just about any kind of data through a command line -(through calls such as the execve(3) call). Therefore, setuid/setgid programs -must completely validate the command line inputs and must not trust the name -of the program reported by command line argument zero (an attacker can set it -to any value including NULL). ------------------------------------------------------------------------------ - -5.2. Environment Variables - -By default, environment variables are inherited from a process' parent. -However, when a program executes another program, the calling program can set -the environment variables to arbitrary values. This is dangerous to setuid/ -setgid programs, because their invoker can completely control the environment -variables they're given. Since they are usually inherited, this also applies -transitively; a secure program might call some other program and, without -special measures, would pass potentially dangerous environment variables -values on to the program it calls. The following subsections discuss -environment variables and what to do with them. ------------------------------------------------------------------------------ - -5.2.1. Some Environment Variables are Dangerous - -Some environment variables are dangerous because many libraries and programs -are controlled by environment variables in ways that are obscure, subtle, or -undocumented. For example, the IFS variable is used by the sh and bash shell -to determine which characters separate command line arguments. Since the -shell is invoked by several low-level calls (like system(3) and popen(3) in -C, or the back-tick operator in Perl), setting IFS to unusual values can -subvert apparently-safe calls. This behavior is documented in bash and sh, -but it's obscure; many long-time users only know about IFS because of its use -in breaking security, not because it's actually used very often for its -intended purpose. What is worse is that not all environment variables are -documented, and even if they are, those other programs may change and add -dangerous environment variables. Thus, the only real solution (described -below) is to select the ones you need and throw away the rest. ------------------------------------------------------------------------------ - -5.2.2. Environment Variable Storage Format is Dangerous - -Normally, programs should use the standard access routines to access -environment variables. For example, in C, you should get values using getenv -(3), set them using the POSIX standard routine putenv(3) or the BSD extension -setenv(3) and eliminate environment variables using unsetenv(3). I should -note here that setenv(3) is implemented in Linux, too. - -However, crackers need not be so nice; crackers can directly control the -environment variable data area passed to a program using execve(2). This -permits some nasty attacks, which can only be understood by understanding how -environment variables really work. In Linux, you can see environ(5) for a -summary how about environment variables really work. In short, environment -variables are internally stored as a pointer to an array of pointers to -characters; this array is stored in order and terminated by a NULL pointer -(so you'll know when the array ends). The pointers to characters, in turn, -each point to a NIL-terminated string value of the form ``NAME=value''. This -has several implications, for example, environment variable names can't -include the equal sign, and neither the name nor value can have embedded NIL -characters. However, a more dangerous implication of this format is that it -allows multiple entries with the same variable name, but with different -values (e.g., more than one value for SHELL). While typical command shells -prohibit doing this, a locally-executing cracker can create such a situation -using execve(2). - -The problem with this storage format (and the way it's set) is that a program -might check one of these values (to see if it's valid) but actually use a -different one. In Linux, the GNU glibc libraries try to shield programs from -this; glibc 2.1's implementation of getenv will always get the first matching -entry, setenv and putenv will always set the first matching entry, and -unsetenv will actually unset all of the matching entries (congratulations to -the GNU glibc implementers for implementing unsetenv this way!). However, -some programs go directly to the environ variable and iterate across all -environment variables; in this case, they might use the last matching entry -instead of the first one. As a result, if checks were made against the first -matching entry instead, but the actual value used is the last matching entry, -a cracker can use this fact to circumvent the protection routines. ------------------------------------------------------------------------------ - -5.2.3. The Solution - Extract and Erase - -For secure setuid/setgid programs, the short list of environment variables -needed as input (if any) should be carefully extracted. Then the entire -environment should be erased, followed by resetting a small set of necessary -environment variables to safe values. There really isn't a better way if you -make any calls to subordinate programs; there's no practical method of -listing ``all the dangerous values''. Even if you reviewed the source code of -every program you call directly or indirectly, someone may add new -undocumented environment variables after you write your code, and one of them -may be exploitable. - -The simple way to erase the environment in C/C++ is by setting the global -variable environ to NULL. The global variable environ is defined in ; C/C++ users will want to #include this header file. You will need to -manipulate this value before spawning threads, but that's rarely a problem, -since you want to do these manipulations very early in the program's -execution (usually before threads are spawned). - -The global variable environ's definition is defined in various standards; -it's not clear that the official standards condone directly changing its -value, but I'm unaware of any Unix-like system that has trouble with doing -this. I normally just modify the ``environ'' directly; manipulating such -low-level components is possibly non-portable, but it assures you that you -get a clean (and safe) environment. In the rare case where you need later -access to the entire set of variables, you could save the ``environ'' -variable's value somewhere, but this is rarely necessary; nearly all programs -need only a few values, and the rest can be dropped. - -Another way to clear the environment is to use the undocumented clearenv() -function. The function clearenv() has an odd history; it was supposed to be -defined in POSIX.1, but somehow never made it into that standard. However, -clearenv() is defined in POSIX.9 (the Fortran 77 bindings to POSIX), so there -is a quasi-official status for it. In Linux, clearenv() is defined in < -stdlib.h>, but before using #include to include it you must make sure that -__USE_MISC is #defined. A somewhat more ``official'' approach is to cause -__USE_MISC to be defined is to first #define either _SVID_SOURCE or -_BSD_SOURCE, and then #include - these are the official feature -test macros. - -One environment value you'll almost certainly re-add is PATH, the list of -directories to search for programs; PATH should not include the current -directory and usually be something simple like ``/bin:/usr/bin''. Typically -you'll also set IFS (to its default of `` \t\n'', where space is the first -character) and TZ (timezone). Linux won't die if you don't supply either IFS -or TZ, but some System V based systems have problems if you don't supply a TZ -value, and it's rumored that some shells need the IFS value set. In Linux, -see environ(5) for a list of common environment variables that you might want -to set. - -If you really need user-supplied values, check the values first (to ensure -that the values match a pattern for legal values and that they are within -some reasonable maximum length). Ideally there would be some standard trusted -file in /etc with the information for ``standard safe environment variable -values'', but at this time there's no standard file defined for this purpose. -For something similar, you might want to examine the PAM module pam_env on -those systems which have that module. If you allow users to set an arbitrary -environment variable, then you'll let them subvert restricted shells (more on -that below). - -If you're using a shell as your programming language, you can use the ``/usr/ -bin/env'' program with the ``-'' option (which erases all environment -variables of the program being run). Basically, you call /usr/bin/env, give -it the ``-'' option, follow that with the set of variables and their values -you wish to set (as name=value), and then follow that with the name of the -program to run and its arguments. You usually want to call the program using -the full pathname (/usr/bin/env) and not just as ``env'', in case a user has -created a dangerous PATH value. Note that GNU's env also accepts the options -"-i" and "--ignore-environment" as synonyms (they also erase the environment -of the program being started), but these aren't portable to other versions of -env. - -If you're programming a setuid/setgid program in a language that doesn't -allow you to reset the environment directly, one approach is to create a -``wrapper'' program. The wrapper sets the environment program to safe values, -and then calls the other program. Beware: make sure the wrapper will actually -invoke the intended program; if it's an interpreted program, make sure -there's no race condition possible that would allow the interpreter to load a -different program than the one that was granted the special setuid/setgid -privileges. ------------------------------------------------------------------------------ - -5.2.4. Don't Let Users Set Their Own Environment Variables - -If you allow users to set their own environment variables, then users will be -able to escape out of restricted accounts (these are accounts that are -supposed to only let the users run certain programs and not work as a -general-purpose machine). This includes letting users write or modify certain -files in their home directory (e.g., like .login), supporting conventions -that load in environment variables from files under the user's control (e.g., -openssh's .ssh/environment file), or supporting protocols that transfer -environment variables (e.g., the Telnet Environment Option; see CERT Advisory -CA-1995-14 for more). Restricted accounts should never be allowed to modify -or add any file directly contained in their home directory, and instead -should be given only a specific subdirectory that they are allowed to modify -(if they can modify any). - -ari posted a detailed discussion of this problem on Bugtraq on June 24, 2002: - - - Given the similarities with certain other security issues, i'm surprised - this hasn't been discussed earlier. If it has, people simply haven't paid - it enough attention. - - This problem is not necessarily ssh-specific, though most telnet daemons - that support environment passing should already be configured to remove - dangerous variables due to a similar (and more serious) issue back in '95 - (ref: [1]). I will give ssh-based examples here. - - Scenario one: Let's say admin bob has a host that he wants to give people - ftp access to. Bob doesn't want anyone to have the ability to actually - _log into_ his system, so instead of giving users normal shells, or even - no shells, bob gives them all (say) /usr/sbin/nologin, a program he wrote - himself in C to essentially log the attempt to syslog and exit, - effectively ending the user's session. As far as most people are - concerned, the user can't do much with this aside from, say, setting up - an encrypted tunnel. - - The thing is, bob's system uses dynamic libraries (as most do), and /usr/ - sbin/nologin is dynamically linked (as most such programs are). If a user - can set his environment variables (e.g. by uploading a '.ssh/environment' - file) and put some arbitrary file on the system (e.g. 'doevilstuff.so'), - he can bypass any functionality of /usr/sbin/nologin completely via - LD_PRELOAD (or another member of the LD_* environment family). - - The user can now gain a shell on the system (with his own privileges, of - course, barring any 'UseLogin' issues (ref: [2])), and administrator bob, - if he were aware of what just occurred, would be extremely unhappy. - - Granted, there are all kinds of interesting ways to (more or less) do - away with this problem. Bob could just grit his teeth and give the ftp - users a nonexistent shell, or he could statically compile nologin, - assuming his operating system comes with static libraries. Bob could - also, humorously, make his nologin program setuid and let the standard C - library take care of the situation. Then, of course, there are also the - ssh-specific access controls such as AllowGroup and AllowUsers. These may - appease the situation in this scenario, but it does not correct the - problem. - - ... Now, what happens if bob, instead of using /usr/sbin/nologin, wants - to use (for example) some BBS-type interface that he wrote up or - downloaded? It can be a script written in perl or tcl or python, or it - could be a compiled program; doesn't matter. Additionally, bob need not - be running an ftp server on this host; instead, perhaps bob uses nfs or - veritas to mount user home directories from a fileserver on his network; - this exact setup is (unfortunately) employed by many bastion hosts, - password management hosts and mail servers---to name a few. Perhaps bob - runs an ISP, and replaces the user's shell when he doesn't pay. With all - of these possible (and common) scenarios, bob's going to have a somewhat - more difficult time getting around the problem. - - ... Exploitation of the problem is simple. The circumvention code would - be compiled into a dynamic library and LD_PRELOAD=/path/to/evil.so should - be placed into ~user/.ssh/environment (a similar environment option may - be appended to public keys in the authohrized_keys file). If no - dynamically loadable programs are executed, this will have no effect. - - ISPs and universities (along with similarly affected organizations) - should compile their rejection (or otherwise restricted) binaries - statically (assuming your operating system comes with static - libraries)... - - Ideally, sshd (and all remote access programs that allow user-definable - environments) should strip any environment settings that libc ignores for - setuid programs. - ------------------------------------------------------------------------------ -5.3. File Descriptors - -A program is passed a set of ``open file descriptors'', that is, pre-opened -files. A setuid/setgid program must deal with the fact that the user gets to -select what files are open and to what (within their permission limits). A -setuid/setgid program must not assume that opening a new file will always -open into a fixed file descriptor id, or that the open will succeed at all. -It must also not assume that standard input (stdin), standard output -(stdout), and standard error (stderr) refer to a terminal or are even open. - -The rationale behind this is easy; since an attacker can open or close a file -descriptor before starting the program, the attacker could create an -unexpected situation. If the attacker closes the standard output, when the -program opens the next file it will be opened as though it were standard -output, and then it will send all standard output to that file as well. Some -C libraries will automatically open stdin, stdout, and stderr if they aren't -already open (to /dev/null), but this isn't true on all Unix-like systems. -Also, these libraries can't be completely depended on; for example, on some -systems it's possible to create a race condition that causes this automatic -opening to fail (and still run the program). ------------------------------------------------------------------------------ - -5.4. File Names - -The names of files can, in certain circumstances, cause serious problems. -This is especially a problem for secure programs that run on computers with -local untrusted users, but this isn't limited to that circumstance. Remote -users may be able to trick a program into creating undesirable filenames -(programs should prevent this, but not all do), or remote users may have -partially penetrated a system and try using this trick to penetrate the rest -of the system. - -Usually you will want to not include ``..'' (higher directory) as a legal -value from an untrusted user, though that depends on the circumstances. You -might also want to list only the characters you will permit, and forbidding -any filenames that don't match the list. It's best to prohibit any change in -directory, e.g., by not including ``/'' in the set of legal characters, if -you're taking data from an external user and transforming it into a filename. - -Often you shouldn't support ``globbing'', that is, expanding filenames using -``*'', ``?'', ``['' (matching ``]''), and possibly ``{'' (matching ``}''). -For example, the command ``ls *.png'' does a glob on ``*.png'' to list all -PNG files. The C fopen(3) command (for example) doesn't do globbing, but the -command shells perform globbing by default, and in C you can request globbing -using (for example) glob(3). If you don't need globbing, just use the calls -that don't do it where possible (e.g., fopen(3)) and/or disable them (e.g., -escape the globbing characters in a shell). Be especially careful if you want -to permit globbing. Globbing can be useful, but complex globs can take a -great deal of computing time. For example, on some ftp servers, performing a -few of these requests can easily cause a denial-of-service of the entire -machine: -ftp> ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../* -Trying to allow globbing, yet limit globbing patterns, is probably futile. -Instead, make sure that any such programs run as a separate process and use -process limits to limit the amount of CPU and other resources they can -consume. See Section 7.4.8 for more information on this approach, and see -Section 3.6 for more information on how to set these limits. - -Unix-like systems generally forbid including the NIL character in a filename -(since this marks the end of the name) and the '/' character (since this is -the directory separator). However, they often permit anything else, which is -a problem; it is easy to write programs that can be subverted by -cleverly-created filenames. - -Filenames that can especially cause problems include: - -  * Filenames with leading dashes (-). If passed to other programs, this may - cause the other programs to misinterpret the name as option settings. - Ideally, Unix-like systems shouldn't allow these filenames; they aren't - needed and create many unnecessary security problems. Unfortunately, - currently developers have to deal with them. Thus, whenever calling - another program with a filename, insert ``--'' before the filename - parameters (to stop option processing, if the program supports this - common request) or modify the filename (e.g., insert ``./'' in front of - the filename to keep the dash from being the lead character). - -  * Filenames with control characters. This especially includes newlines and - carriage returns (which are often confused as argument separators inside - shell scripts, or can split log entries into multiple entries) and the - ESCAPE character (which can interfere with terminal emulators, causing - them to perform undesired actions outside the user's control). Ideally, - Unix-like systems shouldn't allow these filenames either; they aren't - needed and create many unnecessary security problems. - -  * Filenames with spaces; these can sometimes confuse a shell into being - multiple arguments, with the other arguments causing problems. Since - other operating systems allow spaces in filenames (including Windows and - MacOS), for interoperability's sake this will probably always be - permitted. Please be careful in dealing with them, e.g., in the shell use - double-quotes around all filename parameters whenever calling another - program. You might want to forbid leading and trailing spaces at least; - these aren't as visible as when they occur in other places, and can - confuse human users. - -  * Invalid character encoding. For example, a program may believe that the - filename is UTF-8 encoded, but it may have an invalidly long UTF-8 - encoding. See Section 5.9.2 for more information. I'd like to see - agreement on the character encoding used for filenames (e.g., UTF-8), and - then have the operating system enforce the encoding (so that only legal - encodings are allowed), but that hasn't happened at this time. - -  * Another other character special to internal data formats, such as ``<'', - ``;'', quote characters, backslash, and so on. - - ------------------------------------------------------------------------------ -5.5. File Contents - -If a program takes directions from a file, it must not trust that file -specially unless only a trusted user can control its contents. Usually this -means that an untrusted user must not be able to modify the file, its -directory, or any of its ancestor directories. Otherwise, the file must be -treated as suspect. - -If the directions in the file are supposed to be from an untrusted user, then -make sure that the inputs from the file are protected as describe throughout -this book. In particular, check that values match the set of legal values, -and that buffers are not overflowed. ------------------------------------------------------------------------------ - -5.6. Web-Based Application Inputs (Especially CGI Scripts) - -Web-based applications (such as CGI scripts) run on some trusted server and -must get their input data somehow through the web. Since the input data -generally come from untrusted users, this input data must be validated. -Indeed, this information may have actually come from an untrusted third -party; see Section 7.15 for more information. For example, CGI scripts are -passed this information through a standard set of environment variables and -through standard input. The rest of this text will specifically discuss CGI, -because it's the most common technique for implementing dynamic web content, -but the general issues are the same for most other dynamic web content -techniques. - -One additional complication is that many CGI inputs are provided in so-called -``URL-encoded'' format, that is, some values are written in the format %HH -where HH is the hexadecimal code for that byte. You or your CGI library must -handle these inputs correctly by URL-decoding the input and then checking if -the resulting byte value is acceptable. You must correctly handle all values, -including problematic values such as %00 (NIL) and %0A (newline). Don't -decode inputs more than once, or input such as ``%2500'' will be mishandled -(the %25 would be translated to ``%'', and the resulting ``%00'' would be -erroneously translated to the NIL character). - -CGI scripts are commonly attacked by including special characters in their -inputs; see the comments above. - -Another form of data available to web-based applications are ``cookies.'' -Again, users can provide arbitrary cookie values, so they cannot be trusted -unless special precautions are taken. Also, cookies can be used to track -users, potentially invading user privacy. As a result, many users disable -cookies, so if possible your web application should be designed so that it -does not require the use of cookies (but see my later discussion for when you -must authenticate individual users). I encourage you to avoid or limit the -use of persistent cookies (cookies that last beyond a current session), -because they are easily abused. Indeed, U.S. agencies are currently forbidden -to use persistent cookies except in special circumstances, because of the -concern about invading user privacy; see the OMB guidance in memorandum -M-00-13 (June 22, 2000). Note that to use cookies, some browsers may insist -that you have a privacy profile (named p3p.xml on the root directory of the -server). - -Some HTML forms include client-side input checking to prevent some illegal -values; these are typically implemented using Javascript/ECMAscript or Java. -This checking can be helpful for the user, since it can happen -``immediately'' without requiring any network access. However, this kind of -input checking is useless for security, because attackers can send such -``illegal'' values directly to the web server without going through the -checks. It's not even hard to subvert this; you don't have to write a program -to send arbitrary data to a web application. In general, servers must perform -all their own input checking (of form data, cookies, and so on) because they -cannot trust clients to do this securely. In short, clients are generally not -``trustworthy channels''. See Section 7.11 for more information on -trustworthy channels. - -A brief discussion on input validation for those using Microsoft's Active -Server Pages (ASP) is available from Jerry Connolly at [http:// -heap.nologin.net/aspsec.html] http://heap.nologin.net/aspsec.html ------------------------------------------------------------------------------ - -5.7. Other Inputs - -Programs must ensure that all inputs are controlled; this is particularly -difficult for setuid/setgid programs because they have so many such inputs. -Other inputs programs must consider include the current directory, signals, -memory maps (mmaps), System V IPC, pending timers, resource limits, the -scheduling priority, and the umask (which determines the default permissions -of newly-created files). Consider explicitly changing directories (using -chdir(2)) to an appropriately fully named directory at program startup. ------------------------------------------------------------------------------ - -5.8. Human Language (Locale) Selection - -As more people have computers and the Internet available to them, there has -been increasing pressure for programs to support multiple human languages and -cultures. This combination of language and other cultural factors is usually -called a ``locale''. The process of modifying a program so it can support -multiple locales is called ``internationalization'' (i18n), and the process -of providing the information for a particular locale to a program is called -``localization'' (l10n). - -Overall, internationalization is a good thing, but this process provides -another opportunity for a security exploit. Since a potentially untrusted -user provides information on the desired locale, locale selection becomes -another input that, if not properly protected, can be exploited. ------------------------------------------------------------------------------ - -5.8.1. How Locales are Selected - -In locally-run programs (including setuid/setgid programs), locale -information is provided by an environment variable. Thus, like all other -environment variables, these values must be extracted and checked against -valid patterns before use. - -For web applications, this information can be obtained from the web browser -(via the Accept-Language request header). However, since not all web browsers -properly pass this information (and not all users configure their browsers -properly), this is used less often than you might think. Often, the language -requested in a web browser is simply passed in as a form value. Again, these -values must be checked for validity before use, as with any other form value. - -In either case, locale information is really just a special case of input -discussed in the previous sections. However, because this input is so rarely -considered, I'm discussing it separately. In particular, when combined with -format strings (discussed later), user-controlled strings can permit -attackers to force other programs to run arbitrary instructions, corrupt -data, and do other unfortunate actions. ------------------------------------------------------------------------------ - -5.8.2. Locale Support Mechanisms - -There are two major library interfaces for supporting locale-selected -messages on Unix-like systems, one called ``catgets'' and the other called -``gettext''. In the catgets approach, every string is assigned a unique -number, which is used as an index into a table of messages. In contrast, in -the gettext approach, a string (usually in English) is used to look up a -table that translates the original string. catgets(3) is an accepted standard -(via the X/Open Portability Guide, Volume 3 and Single Unix Specification), -so it's possible your program uses it. The ``gettext'' interface is not an -official standard, (though it was originally a UniForum proposal), but I -believe it's the more widely used interface (it's used by Sun and essentially -all GNU programs). - -In theory, catgets should be slightly faster, but this is at best marginal on -today's machines, and the bookkeeping effort to keep unique identifiers valid -in catgets() makes the gettext() interface much easier to use. I'd suggest -using gettext(), just because it's easier to use. However, don't take my word -for it; see GNU's documentation on gettext (info:gettext#catgets) for a -longer and more descriptive comparison. - -The catgets(3) call (and its associated catopen(3) call) in particular is -vulnerable to security problems, because the environment variable NLSPATH can -be used to control the filenames used to acquire internationalized messages. -The GNU C library ignores NLSPATH for setuid/setgid programs, which helps, -but that doesn't protect programs running on other implementations, nor other -programs (like CGI scripts) which don't ``appear'' to require such -protection. - -The widely-used ``gettext'' interface is at least not vulnerable to a -malicious NLSPATH setting to my knowledge. However, it appears likely to me -that malicious settings of LC_ALL or LC_MESSAGES could cause problems. Also, -if you use gettext's bindtextdomain() routine in its file cat-compat.c, that -does depend on NLSPATH. ------------------------------------------------------------------------------ - -5.8.3. Legal Values - -For the moment, if you must permit untrusted users to set information on -their desired locales, make sure the provided internationalization -information meets a narrow filter that only permits legitimate locale names. -For user programs (especially setuid/setgid programs), these values will come -in via NLSPATH, LANGUAGE, LANG, the old LINGUAS, LC_ALL, and the other LC_* -values (especially LC_MESSAGES, but also including LC_COLLATE, LC_CTYPE, -LC_MONETARY, LC_NUMERIC, and LC_TIME). For web applications, this -user-requested set of language information would be done via the -Accept-Language request header or a form value (the application should -indicate the actual language setting of the data being returned via the -Content-Language heading). You can check this value as part of your -environment variable filtering if your users can set your environment -variables (i.e., setuid/setgid programs) or as part of your input filtering -(e.g., for CGI scripts). The GNU C library "glibc" doesn't accept some values -of LANG for setuid/setgid programs (in particular anything with "/"), but -errors have been found in that filtering (e.g., Red Hat released an update to -fix this error in glibc on September 1, 2000). This kind of filtering isn't -required by any standard, so you're safer doing this filtering yourself. I -have not found any guidance on filtering language settings, so here are my -suggestions based on my own research into the issue. - -First, a few words about the legal values of these settings. Language -settings are generally set using the standard tags defined in IETF RFC 1766 -(which uses two-letter country codes as its basic tag, followed by an -optional subtag separated by a dash; I've found that environment variable -settings use the underscore instead). However, some find this insufficiently -flexible, so three-letter country codes may soon be used as well. Also, there -are two major not-quite compatible extended formats, the X/Open Format and -the CEN Format (European Community Standard); you'd like to permit both. -Typical values include ``C'' (the C locale), ``EN'' (English''), and -``FR_fr'' (French using the territory of France's conventions). Also, so many -people use nonstandard names that programs have had to develop ``alias'' -systems to cope with nonstandard names (for GNU gettext, see /usr/share/ -locale/locale.alias, and for X11, see /usr/lib/X11/locale/locale.alias; you -might need "aliases" instead of "alias"); they should usually be permitted as -well. Libraries like gettext() have to accept all these variants and find an -appropriate value, where possible. One source of further information is FSF -[1999]; another source is the li18nux.org web site. A filter should not -permit characters that aren't needed, in particular ``/'' (which might permit -escaping out of the trusted directories) and ``..'' (which might permit going -up one directory). Other dangerous characters in NLSPATH include ``%'' (which -indicates substitution) and ``:'' (which is the directory separator); the -documentation I have for other machines suggests that some implementations -may use them for other values, so it's safest to prohibit them. ------------------------------------------------------------------------------ - -5.8.4. Bottom Line - -In short, I suggest simply erasing or re-setting the NLSPATH, unless you have -a trusted user supplying the value. For the Accept-Language heading in HTTP -(if you use it), form values specifying the locale, and the environment -variables LANGUAGE, LANG, the old LINGUAS, LC_ALL, and the other LC_* values -listed above, filter the locales from untrusted users to permit null (empty) -values or to only permit values that match in total this regular expression -(note that I've recently added "="): - [A-Za-z][A-Za-z0-9_,+@\-\.=]* -I haven't found any legitimate locale which doesn't match this pattern, but -this pattern does appear to protect against locale attacks. Of course, -there's no guarantee that there are messages available in the requested -locale, but in such a case these routines will fall back to the default -messages (usually in English), which at least is not a security problem. - -If you wish to be really picky, and only patterns that match li18nux's locale -pattern, you can use this pattern instead: - ^[A-Za-z]+(_[A-Za-z]+)? - (\.[A-Z]+(\-[A-Z0-9]+)*)? - (\@[A-Za-z0-9]+(\=[A-Za-z0-9\-]+) - (,[A-Za-z0-9]+(\=[A-Za-z0-9\-]+))*)?$ -In both cases, these patterns use POSIX's extended (``modern'') regular -expression notation (see regex(3) and regex(7) on Unix-like systems). - -Of course, languages cannot be supported without a standard way to represent -their written symbols, which brings us to the issue of character encoding. ------------------------------------------------------------------------------ - -5.9. Character Encoding - -5.9.1. Introduction to Character Encoding - -For many years Americans have exchanged text using the ASCII character set; -since essentially all U.S. systems support ASCII, this permits easy exchange -of English text. Unfortunately, ASCII is completely inadequate in handling -the characters of nearly all other languages. For many years different -countries have adopted different techniques for exchanging text in different -languages, making it difficult to exchange data in an increasingly -interconnected world. - -More recently, ISO has developed ISO 10646, the ``Universal Mulitple-Octet -Coded Character Set (UCS). UCS is a coded character set which defines a -single 31-bit value for each of all of the world's characters. The first -65536 characters of the UCS (which thus fit into 16 bits) are termed the -``Basic Multilingual Plane'' (BMP), and the BMP is intended to cover nearly -all of today's spoken languages. The Unicode forum develops the Unicode -standard, which concentrates on the UCS and adds some additional conventions -to aid interoperability. Historically, Unicode and ISO 10646 were developed -by competing groups, but thankfully they realized that they needed to work -together and they now coordinate with each other. - -If you're writing new software that handles internationalized characters, you -should be using ISO 10646/Unicode as your basis for handling international -characters. However, you may need to process older documents in various older -(language-specific) character sets, in which case, you need to ensure that an -untrusted user cannot control the setting of another document's character set -(since this would significantly affect the document's interpretation). ------------------------------------------------------------------------------ - -5.9.2. Introduction to UTF-8 - -Most software is not designed to handle 16 bit or 32 bit characters, yet to -create a universal character set more than 8 bits was required. Therefore, a -special format called ``UTF-8'' was developed to encode these potentially -international characters in a format more easily handled by existing programs -and libraries. UTF-8 is defined, among other places, in IETF RFC 2279, so -it's a well-defined standard that can be freely read and used. UTF-8 is a -variable-width encoding; characters numbered 0 to 0x7f (127) encode to -themselves as a single byte, while characters with larger values are encoded -into 2 to 6 bytes of information (depending on their value). The encoding has -been specially designed to have the following nice properties (this -information is from the RFC and Linux utf-8 man page): - -  * The classical US ASCII characters (0 to 0x7f) encode as themselves, so - files and strings which contain only 7-bit ASCII characters have the same - encoding under both ASCII and UTF-8. This is fabulous for backward - compatibility with the many existing U.S. programs and data files. - -  * All UCS characters beyond 0x7f are encoded as a multibyte sequence - consisting only of bytes in the range 0x80 to 0xfd. This means that no - ASCII byte can appear as part of another character. Many other encodings - permit characters such as an embedded NIL, causing programs to fail. - -  * It's easy to convert between UTF-8 and a 2-byte or 4-byte fixed-width - representations of characters (these are called UCS-2 and UCS-4 - respectively). - -  * The lexicographic sorting order of UCS-4 strings is preserved, and the - Boyer-Moore fast search algorithm can be used directly with UTF-8 data. - -  * All possible 2^31 UCS codes can be encoded using UTF-8. - -  * The first byte of a multibyte sequence which represents a single - non-ASCII UCS character is always in the range 0xc0 to 0xfd and indicates - how long this multibyte sequence is. All further bytes in a multibyte - sequence are in the range 0x80 to 0xbf. This allows easy - resynchronization; if a byte is missing, it's easy to skip forward to the - ``next'' character, and it's always easy to skip forward and back to the - ``next'' or ``preceding'' character. - - -In short, the UTF-8 transformation format is becoming a dominant method for -exchanging international text information because it can support all of the -world's languages, yet it is backward compatible with U.S. ASCII files as -well as having other nice properties. For many purposes I recommend its use, -particularly when storing data in a ``text'' file. ------------------------------------------------------------------------------ - -5.9.3. UTF-8 Security Issues - -The reason to mention UTF-8 is that some byte sequences are not legal UTF-8, -and this might be an exploitable security hole. UTF-8 encoders are supposed -to use the ``shortest possible'' encoding, but naive decoders may accept -encodings that are longer than necessary. Indeed, earlier standards permitted -decoders to accept ``non-shortest form'' encodings. The problem here is that -this means that potentially dangerous input could be represented multiple -ways, and thus might defeat the security routines checking for dangerous -inputs. The RFC describes the problem this way: - - - Implementers of UTF-8 need to consider the security aspects of how they - handle illegal UTF-8 sequences. It is conceivable that in some - circumstances an attacker would be able to exploit an incautious UTF-8 - parser by sending it an octet sequence that is not permitted by the UTF-8 - syntax. - - A particularly subtle form of this attack could be carried out against a - parser which performs security-critical validity checks against the UTF-8 - encoded form of its input, but interprets certain illegal octet sequences - as characters. For example, a parser might prohibit the NUL character - when encoded as the single-octet sequence 00, but allow the illegal - two-octet sequence C0 80 (illegal because it's longer than necessary) and - interpret it as a NUL character (00). Another example might be a parser - which prohibits the octet sequence 2F 2E 2E 2F ("/../"), yet permits the - illegal octet sequence 2F C0 AE 2E 2F. - - - -A longer discussion about this is available at Markus Kuhn's UTF-8 and -Unicode FAQ for Unix/Linux at [http://www.cl.cam.ac.uk/~mgk25/unicode.html] -http://www.cl.cam.ac.uk/~mgk25/unicode.html. ------------------------------------------------------------------------------ - -5.9.4. UTF-8 Legal Values - -Thus, when accepting UTF-8 input, you need to check if the input is valid -UTF-8. Here is a list of all legal UTF-8 sequences; any character sequence -not matching this table is not a legal UTF-8 sequence. In the following -table, the first column shows the various character values being encoded into -UTF-8. The second column shows how those characters are encoded as binary -values; an ``x'' indicates where the data is placed (either a 0 or 1), though -some values should not be allowed because they're not the shortest possible -encoding. The last row shows the valid values each byte can have (in -hexadecimal). Thus, a program should check that every character meets one of -the patterns in the right-hand column. A ``-'' indicates a range of legal -values (inclusive). Of course, just because a sequence is a legal UTF-8 -sequence doesn't mean that you should accept it (you still need to do all -your other checking), but generally you should check any UTF-8 data for UTF-8 -legality before performing other checks. - - -Table 5-1. Legal UTF-8 Sequences -+------------------------+-------------------------+------------------------+ -|UCS Code (Hex) |Binary UTF-8 Format |Legal UTF-8 Values (Hex)| -+------------------------+-------------------------+------------------------+ -|00-7F |0xxxxxxx |00-7F | -+------------------------+-------------------------+------------------------+ -|80-7FF |110xxxxx 10xxxxxx |C2-DF 80-BF | -+------------------------+-------------------------+------------------------+ -|800-FFF |1110xxxx 10xxxxxx |E0 A0*-BF 80-BF | -| |10xxxxxx | | -+------------------------+-------------------------+------------------------+ -|1000-FFFF |1110xxxx 10xxxxxx |E1-EF 80-BF 80-BF | -| |10xxxxxx | | -+------------------------+-------------------------+------------------------+ -|10000-3FFFF |11110xxx 10xxxxxx |F0 90*-BF 80-BF 80-BF | -| |10xxxxxx 10xxxxxx | | -+------------------------+-------------------------+------------------------+ -|40000-FFFFFF |11110xxx 10xxxxxx |F1-F3 80-BF 80-BF 80-BF | -| |10xxxxxx 10xxxxxx | | -+------------------------+-------------------------+------------------------+ -|40000-FFFFFF |11110xxx 10xxxxxx |F1-F3 80-BF 80-BF 80-BF | -| |10xxxxxx 10xxxxxx | | -+------------------------+-------------------------+------------------------+ -|100000-10FFFFF |11110xxx 10xxxxxx |F4 80-8F* 80-BF 80-BF | -| |10xxxxxx 10xxxxxx | | -+------------------------+-------------------------+------------------------+ -|200000-3FFFFFF |111110xx 10xxxxxx |too large; see below | -| |10xxxxxx 10xxxxxx | | -| |10xxxxxx | | -+------------------------+-------------------------+------------------------+ -|04000000-7FFFFFFF |1111110x 10xxxxxx |too large; see below | -| |10xxxxxx 10xxxxxx | | -| |10xxxxxx 10xxxxxx | | -+------------------------+-------------------------+------------------------+ - -As I noted earlier, there are two standards for character sets, ISO 10646 and -Unicode, who have agreed to synchronize their character assignments. The -definition of UTF-8 in ISO/IEC 10646-1:2000 and the IETF RFC also currently -support five and six byte sequences to encode characters outside the range -supported by Uniforum's Unicode, but such values can't be used to support -Unicode characters and it's expected that a future version of ISO 10646 will -have the same limits. Thus, for most purposes the five and six byte UTF-8 -encodings aren't legal, and you should normally reject them (unless you have -a special purpose for them). - -This is set of valid values is tricky to determine, and in fact earlier -versions of this document got some entries wrong (in some cases it permitted -overlong characters). Language developers should include a function in their -libraries to check for valid UTF-8 values, just because it's so hard to get -right. - -I should note that in some cases, you might want to cut slack (or use -internally) the hexadecimal sequence C0 80. This is an overlong sequence -that, if permitted, can represent ASCII NUL (NIL). Since C and C++ have -trouble including a NIL character in an ordinary string, some people have -taken to using this sequence when they want to represent NIL as part of the -data stream; Java even enshrines the practice. Feel free to use C0 80 -internally while processing data, but technically you really should translate -this back to 00 before saving the data. Depending on your needs, you might -decide to be ``sloppy'' and accept C0 80 as input in a UTF-8 data stream. If -it doesn't harm security, it's probably a good practice to accept this -sequence since accepting it aids interoperability. - -Handling this can be tricky. You might want to examine the C routines -developed by Unicode to handle conversions, available at [ftp:// -ftp.unicode.org/Public/PROGRAMS/CVTUTF/ConvertUTF.c] ftp://ftp.unicode.org/ -Public/PROGRAMS/CVTUTF/ConvertUTF.c. It's unclear to me if these routines are -open source software (the licenses don't clearly say whether or not they can -be modified), so beware of that. ------------------------------------------------------------------------------ - -5.9.5. UTF-8 Related Issues - -This section has discussed UTF-8, because it's the most popular multibyte -encoding of UCS, simplifying a lot of international text handling issues. -However, it's certainly not the only encoding; there are other encodings, -such as UTF-16 and UTF-7, which have the same kinds of issues and must be -validated for the same reasons. - -Another issue is that some phrases can be expressed in more than one way in -ISO 10646/Unicode. For example, some accented characters can be represented -as a single character (with the accent) and also as a set of characters -(e.g., the base character plus a separate composing accent). These two forms -may appear identical. There's also a zero-width space that could be inserted, -with the result that apparently-similar items are considered different. -Beware of situations where such hidden text could interfere with the program. -This is an issue that in general is hard to solve; most programs don't have -such tight control over the clients that they know completely how a -particular sequence will be displayed (since this depends on the client's -font, display characteristics, locale, and so on). ------------------------------------------------------------------------------ - -5.10. Prevent Cross-site Malicious Content on Input - -Some programs accept data from one untrusted user and pass that data on to a -second user; the second user's application may then process that data in a -way harmful to the second user. This is a particularly common problem for web -applications, we'll call this problem ``cross-site malicious content.'' In -short, you cannot accept input (including any form data) without checking, -filtering, or encoding it. For more information, see Section 7.15. - -Fundamentally, this means that all web application input must be filtered (so -characters that can cause this problem are removed), encoded (so the -characters that can cause this problem are encoded in a way to prevent the -problem), or validated (to ensure that only ``safe'' data gets through). -Filtering and validation should often be done at the input, but encoding can -be done either at input or output time. If you're just passing the data -through without analysis, it's probably better to encode the data on input -(so it won't be forgotten), but if you're processing the data, there are -arguments for encoding on output instead. ------------------------------------------------------------------------------ - -5.11. Filter HTML/URIs That May Be Re-presented - -One special case where cross-site malicious content must be prevented are web -applications which are designed to accept HTML or XHTML from one user, and -then send it on to other users (see Section 7.15 for more information on -cross-site malicious content). The following subsections discuss filtering -this specific kind of input, since handling it is such a common requirement. ------------------------------------------------------------------------------ - -5.11.1. Remove or Forbid Some HTML Data - -It's safest to remove all possible (X)HTML tags so they cannot affect -anything, and this is relatively easy to do. As noted above, you should -already be identifying the list of legal characters, and rejecting or -removing those characters that aren't in the list. In this filter, simply -don't include the following characters in the list of legal characters: ``< -'', ``>'', and ``&'' (and if they're used in attributes, the double-quote -character ``"''). If browsers only operated according the HTML -specifications, the ``>"'' wouldn't need to be removed, but in practice it -must be removed. This is because some browsers assume that the author of the -page really meant to put in an opening "<" and ``helpfully'' insert one - -attackers can exploit this behavior and use the ">" to create an undesired "< -". - -Usually the character set for transmitting HTML is ISO-8859-1 (even when -sending international text), so the filter should also omit most control -characters (linefeed and tab are usually okay) and characters with their -high-order bit set. - -One problem with this approach is that it can really surprise users, -especially those entering international text if all international text is -quietly removed. If the invalid characters are quietly removed without -warning, that data will be irrevocably lost and cannot be reconstructed -later. One alternative is forbidding such characters and sending error -messages back to users who attempt to use them. This at least warns users, -but doesn't give them the functionality they were looking for. Other -alternatives are encoding this data or validating this data, which are -discussed next. ------------------------------------------------------------------------------ - -5.11.2. Encoding HTML Data - -An alternative that is nearly as safe is to transform the critical characters -so they won't have their usual meaning in HTML. This can be done by -translating all "<" into "<", ">" into ">", and "&" into "&". -Arbitrary international characters can be encoded in Latin-1 using the format -"&#value;" - do not forget the ending semicolon. Encoding the international -characters means you must know what the input encoding was, of course. - -One possible danger here is that if these encodings are accidentally -interpreted twice, they will become a vulnerability. However, this approach -at least permits later users to see the "intent" of the input. ------------------------------------------------------------------------------ - -5.11.3. Validating HTML Data - -Some applications, to work at all, must accept HTML from third parties and -send them on to their users. Beware - you are treading dangerous ground at -this point; be sure that you really want to do this. Even the idea of -accepting HTML from arbitrary places is controversial among some security -practitioners, because it is extremely difficult to get it right. - -However, if your application must accept HTML, and you believe that it's -worth the risk, at least identify a list of ``safe'' HTML commands and only -permit those commands. - -Here is a minimal set of safe HTML tags that might be useful for applications -(such as guestbooks) that support short comments:

(paragraph), -(bold), (italics), (emphasis), (strong emphasis), 

-(preformatted text), 
 (forced line break - note it doesn't require a
-closing tag), as well as all their ending tags.
-
-Not only do you need to ensure that only a small set of ``safe'' HTML
-commands are accepted, you also need to ensure that they are properly nested
-and closed (i.e., that the HTML commands are ``balanced''). In XML, this is
-termed ``well-formed'' data. A few exceptions could be made if you're
-accepting standard HTML (e.g., supporting an implied 
 where not provided
-before a 
 would be fine), but trying to accept HTML in its full generality
-(which can infer balancing closing tags in many cases) is not needed for most
-applications. Indeed, if you're trying to stick to XHTML (instead of HTML),
-then well-formedness is a requirement. Also, HTML tags are case-insensitive;
-tags can be upper case, lower case, or a mixture. However, if you intend to
-accept XHTML then you need to require all tags to be in lower case (XML is
-case-sensitive; XHTML uses XML and requires the tags to be in lower case).
-
-Here are a few random tips about doing this. Usually you should design
-whatever surrounds the HTML text and the set of permitted tags so that the
-contributed text cannot be misinterpreted as text from the ``main'' site (to
-prevent forgeries). Don't accept any attributes unless you've checked the
-attribute type and its value; there are many attributes that support things
-such as Javascript that can cause trouble for your users. You'll notice that
-in the above list I didn't include any attributes at all, which is certainly
-the safest course. You should probably give a warning message if an unsafe
-tag is used, but if that's not practical, encoding the critical characters
-(e.g., "<" becomes "<") prevents data loss while simultaneously keeping
-the users safe.
-
-Be careful when expanding this set, and in general be restrictive of what you
-accept. If your patterns are too generous, the browser may interpret the
-sequences differently than you expect, resulting in a potential exploit. For
-example, FozZy posted on Bugtraq (1 April 2002) some sequences that permitted
-exploitation in various web-based mail systems, which may give you an idea of
-the kinds of problems you need to defend against. Here's some exploit text
-that, at one time, could subvert user accounts in Microsoft Hotmail:
-                                                      
-  &{[code]}; [N4]                                                            
-   [N4]                                                  
-                             
-