LinuxSecurity.com
Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Welcome!
Sign up!
EnGarde Community
Login
Polls
What is the most important Linux security technology?
 
Advisories
Community
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
SELinux
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Securitydistro
Latest Newsletters
Linux Security Week: July 28th, 2014
Linux Advisory Watch: July 25th, 2014
Subscribe
LinuxSecurity Newsletters
E-mail:
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

  
Using Chroot Securely Print E-mail
User Rating:      How can I rate this item?
Source: Linuxsecurity.com - Posted by Anton Chuvakin, Ph.D.   
Features The chroot() function can be a powerful mechanism to secure your system, but only if used correctly. Anton provides a good foundation for implementing it in your programs and services running on your system.

Chroot command and chroot system call might sound like a good security measure - one command executed and plain old UNIX "cd /" no longer transports you to a root directory of the system. Instead, you are bound to stay in the restricted part of the filesystem, surrounded only by files chosen by a paranoid system administrator. In fact, that is how it should be.

Is it possible to break out of chroot solitary confinement? Yes, if certain conditions are met. In this paper we will analyze what chroot is good for and also what chroot is bad for.

First, how does it work? When one types /sbin/chroot directory_name on the UNIX system command line one sees that the new root is now 'directory_name' (the /bin/ls / command produces the listing of files from 'directory_name' presuming that you have an 'ls' command located within your new root). Chroot shell command changes the root directory for a process, goes into this directory and then starts a shell or a user-specified command.

Chroot command uses a chroot() system call. The command and the system call have an important difference between them: unlike the shell command, chroot() call does not change your working directory to the one inside chrooted jail. The source of chroot.c (shell command, in Linux part of sh-utils) shows the following sequence of system calls:

chroot (argv[1]);
chdir ("/");
As will be seen further, it will allow for easy chroot jail breaking.

Chroot is often used as a security measure. If one has ever used an anonymous ftp server, one has used chroot. Ftp server chroots itself into a special directory upon the anonymous ftp login. DNS (Domain Name System) daemon bind is often chrooted as well. People also suggested chrooting telnet/ssh remote shell users into their corresponding home directories, so they can only update their web pages. Web servers can be run chrooted too. Smap secure email wrapper from FWTK firewall tool kit runs chrooted to the mail spool directory. When chroot is implemented, programs running inside cannot access any system resources on the outside. Thus all system libraries, configuration files and even devices files should be recreated within the chroot jail.

What daemons can be chrooted? If a daemon has to access files that are not easily collectible in one place, chrooting it will be hard. For example, sendmail needs mail spool (/var/spool/mail), other files in spool (such as mqueue), user's home directories (to check for .forward files) and system configuration files in /etc. There is no place on the filesystem where sendmail can be effectively confined. Of course, some makeshift solution is possible, but it is not clear that it will add to security, but rather cause it to lax. If sendmail functionality is separated into spool daemon and mail transfer program (like done in FWTK smap and smapd), than chrooting is entirely possible.

Chrooting shell users is possible if there is a business need to keep them in some particular directory. Suggestions for doing this with ssh2 are provided in the SSH FAQ, and for OpenSSH in the Linux From Scratch archives and SF Linux archives. However, it might involve copying multiple system libraries, files and other resources such as Linux Pluggable Authentication Modules (PAM) architecture, used by most modern Linux distributions.

Anything else such as bind, apache, squid can be chrooted, but sometimes the benefits are unclear, especially for daemons that run as root. This URL (http://www.networkdweebs.com/chroot.html) provides a nice list of daemons that its author chrooted successfully.

"What daemon should be chrooted?" is an entirely different question from "What daemons can be chrooted?" Before we answer it, lets analyze how attackers break out of chroot.

First, the more software is deployed within chroot environment, the more dangerous it becomes, since it is hard to keep track of programs that can be used by the attacker to elevate permission and escape.

Second, the number of ways that root user can break out of chroot is huge. Starting from simple use of a chroot() call with no chdir() [see code below] to esoteric methods as the creation of your own /dev/hda or /dev/kmem devices, injection code into the running kernel (http://www.big.net.au/~silvio/runtime-kernel-kmem-patching.txt), using open directory handles outside chroot or chroot-breaking buffer overflows. While system capabilities can be used to render inoperable many of these methods, new ones will likely be found by smart attackers.

Sample code to break out of chroot:

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>
int main(void)
{
    int i;
    mkdir("breakout", 0700);
    chroot("breakout");
    for (i = 0; i < 100; i++)
      chdir("..") ;
    chroot(".");
    execl("/bin/sh", "/bin/sh",NULL);
}

compile statically (using "gcc -static") and run within chrooted directory (after doing "chroot ." or similar from shell prompt) to escape. Third, if there is no root user defined within the chroot environment, no SUID binaries, no devices, and the daemon itself dropped root privileges right after calling chroot() call (like in the code below), breaking out of chroot appears to be impossible. In other words, if there is no way to gain root shell or perform actions that only root can usually perform (e.g. create devices, or access raw memory) breaking chroot is not clearly possible. Ideally, if the custom software uses chroot for security the sequence of calls should be:

chdir("/home/safedir");
chroot("/home/safedir");
setuid(500);
Keep in mind, that after these lines are executed there will be no way for the program to regain root privileges.

Fourth, in some cases attackers might not be able to break (i.e. run processes outside of chrooted directory), but instead will be able to somewhat affect such processes. For example, if bind is chrooted, several devices should be created. One of them is /dev/log, necessary for logging bind messages into the regular system logs. By crafting a malicious log message and sending it into /dev/log from within the chrooted directory attacker will influence the behavior of syslog daemon running outside the chroot. If there is a buffer overflow in syslog (which runs as root), additional privileges can be obtained.

What daemons can be chrooted but with no valuable security outcome? In light of the above, chrooting programs that do not drop root privileges while running, or programs that provide root shell access (sshd, telnet with a root account within chrooted directory) does not provide any extra security.

To conclude, chroot() is a good way to increase the security of the software provided that secure programming guidelines are utilized and chroot() system call limitations are taken into account. Chrooting will prevent an attacker from reading files outside the chroot jail and will prevent many local UNIX attacks (such as SUID abuse and /tmp race conditions).

References

  • Secure Programming HOWTO -- 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.

  • Chroot-BIND HOWTO -- This document describes installing the BIND 8 nameserver to run in a chroot jail and as a non-root user, to provide added security and minimise the potential effects of a security compromise.

  • Linux Security QuickReference Card -- This Quick Reference Guide is intended to provide a starting point for improving the security of your system. Contained within include references to security resources around the net, tips on securing your Linux box, and general security information.

  • Linux Security Documentation -- Linux Security documentation starting point.

  • WWW Security FAQ -- Steps on chrooting the Apache Web server.

  • Securing and Configuring Postfix HOWTO -- General steps on securing the postfix mail server, including how to configure it to run in a chroot.

  • Debian Security HOWTO -- Debian security checklist including programs to be chrooted.

  • Chrooting All Services in Linux -- Good starting point to explain the basics of using chroot() but be sure to heed the instructions provided in this article before chrooting all services running on your system.

About the Author

Anton Chuvakin, Ph.D. is a Senior Security Analyst with netForensics, a security information management company that provides real-time network security monitoring solutions.

Comments
ForexWritten by would 500 on 2007-11-04 05:04:45
http://forecast.newdataforex.com/map.html 

Only registered users can write comments.
Please login or register.

Powered by AkoComment!

 
< Prev   Next >
    
Partner

 

Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Yesterday's Edition
Ottawa Linux Symposium: May get by with a little help from its friends
Black Hat 2014: How to crack just about everything
NSA Playset, 911 hacked and war cats: A wild ride at DEF CON 22
More Details of Onion/Critroni Crypto Ransomware Emerge
Is there Another NSA Leaker? Updated
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2014 Guardian Digital, Inc. All rights reserved.