Stay Ahead With Linux Security Features
threat detection scalability Building a SIEM is easier than scaling one. Most open-source deployments start as a simple "all-in-one" server. It is easy to set up, but that design rarely survives the transition from a lab to a production workload. . A SIEM watching 20 endpoints is not doing the same job as one watching 500. More endpoints mean more logs; more logs require more storage; more storage makes search heavier. Eventually, the very architecture that made your lab easy to deploy becomes the reason your production...
Jun 04, 2026
security advisory apache A newly disclosed attack technique called HTTP/2 Bomb is drawing attention because it targets the software that sits at the front of much of the Linux internet. Apache HTTP Server, NGINX, Envoy, and the ingress layers that many Kubernetes environments depend on can be forced into consuming disproportionate amounts of memory using relatively small amounts of attacker traffic. . For Linux administrators, the concern is not the HTTP/2 protocol itself. It is the possibility that a single...
Jun 04, 2026
security advisory important The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal...
Jun 03, 2026
security advisory open-source You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back. . What happened? You didn't lose the battle at the exploit; you lost it at the cleanup. In many modern Linux intrusions, the malware you found wasn't the main problem—it was the fallback mechanisms left behind. These hooks quietly restore attacker access the moment you look away. If you clean a host but miss these persistence layers,...
Jun 02, 2026
security advisory Red Hat Researchers investigating a campaign now tracked as Miasma found that more than 30 packages in Red Hat's @redhat-cloud-services npm namespace had been altered to deliver credential-stealing malware. . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reported so far, the objective appears to have been much simpler: collect credentials from developer environments and use that access elsewhere. GitHub tokens, cloud credentials, SSH keys, and other...
Jun 02, 2026
Refine features
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security features
We found -3 articles for you...
102
security advisorysystem securityUNIXImplementing Chroot for Security and Process Isolation Techniques
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. . C hroot 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 theycan 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. 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 ( ) 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 breakout 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 ( ), 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 #include #include #include #include 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 directoryattacker 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 thepostfix 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. . Chroot command and chroot system call might sound like a good security measure - one command execute. chroot(), function, powerful, mechanism, secure, system, correctly. . Anthony Pell
Feb 10, 2002
•
102
security practicesopen source securityLinux developmentDavid A. Wheeler Discusses Secure Programming Guidelines for Linux
David A. Wheeler is the author of the "Secure Programming for Linux HOWTO", the Linux Documentation Project's document describing how to write secure programs for Linux.. We thought it'd be interesting to interview David to learn more about his Secure Programming for Linux HOWTO and his views about security in general. He's the author of many other books and papers, including co-author of the GNOME User's Guide and lead editor of the IEEE's book Software Inspection: An Industry Best Practice . He's contributed various small programs and documents through the web as well. He lives in Northern Virginia. LinuxSecurity: When did you get involved in computing and security? What intrigued you about them? Wheeler: I first got involved with computing in the 1970's; like many, I was intrigued by being able to command a machine that could solve problems, create virtual worlds, and support new means of communication. In the 1980's I got involved with Unix systems and was very fascinated by Unix's elegance; it made it easy to hook together small tools to solve complex problems. About the same time I became interested in security; friends showed me subtle security holes that made me realize how difficult it can be to make a system secure. Yet, to realize the potential of computer technology, we've got to make computers much more secure. LinuxSecurity: What have you done since? Wheeler: Not everything I've done has been directly related to security. A lot of my work has involved how to build large, complex systems that need to be very reliable and interoperate. I've evaluated a number of large software development programs (evaluating their management approach, development process, and/or resulting code). I also work hard on keeping up with the technology, so I've learned a large number of languages, interesting libraries, standards, and so on. More specific to security, I've worked on developing processes to improve software security, and I've contributed to the development and implementation ofthe the Common Criteria for IT Security Evaluation (an ISO security standard). I've examined various security standards, Java, a commercial firewall, and Linux. LinuxSecurity: Why did you develop the "Secure Programming for Linux HOWTO?" Wheeler: Over the last several years I noticed that many developers for Linux 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. I guess all of that leads up to the answer: I developed this document in the hope that future software developers for Linux won't repeat past mistakes, resulting in an even more secure form of Linux. LinuxSecurity: For those who haven't read ``Secure Programming for Linux HOWTO,' can you briefly describe what's in it? Wheeler: I guess I'll start by quoting the introduction: ``This paper describes a set of design and implementation guidelines for writing secure programs on Linux systems. For purposes of this paper, 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, CGI scripts, network servers, and setuid/setgid programs.' After the background section, the paper summarizes Linux security features; The paper then lists hundreds of specific guidelines, grouped into the following categories: validate all input, avoid buffer overflow, structure program internals and approach, carefully call out to other resources, send information back judiciously, and special topics. I didn't invent these guidelines ``whole cloth;' much of this informationhas been available in various locations, but they weren't unified into a single location and almost none of them specifically discussed Linux. My document has lots of credits and references to those other sources, and in fact I'd recommend reading all of those references if you can. What I did was find these various sources (not an easy task!), add some guidelines of my own, developed a (hopefully) rational organization, and brought these guidelines together so there'd be a single, simple place to look. LinuxSecurity: Can you give any rationale for why you included what you did? Wheeler: Sure. I added the section on Linux security features because I've found that many programming books don't provide enough information about Linux security features, or they distribute the information across so many parts of the book that you can't understand the ``big picture.' I put buffer overflow in a separate chapter because it's so important. I try to do more than just warn that there's a problem; I discuss what you should do instead, including trade-offs of alternatives. For example, for buffer overflows in C/C++, I discuss the ``standard' solution (using strncpy and so on), alternative approaches (such as strlcpy and libmib), and discuss their trade-offs. My emphasis is on what a programmer can do, so for example, I don't dwell on all the horrible things that can happen to setuid/setgid programs that don't control the environment variables sent to them; instead, I recommend the only approach that works in most cases (pull out what you need, and throw away the rest). LinuxSecurity: Why doesn't your HOWTO cover administration, configuration, development processes, or other Unix-like systems such as the *BSDs? Wheeler: I don't cover administration or configuration because there are already a lot of useful books on the subject. There's the Linux Security HOWTO , the Linux Security Administrator's Guide , the Linux Administrator's Security Guide , and SANS' Securing Linux Step-by-Step , among many.Clearly, you need to know how to configure a secure system, but configuration won't help if the underlying software is fundamentally insecure. As far as not covering development processes or other Unix-like systems, I did that primarily so I could create a useful version of the document more rapidly than if I'd tried to do it all at once. I omitted some guidelines I considered less critical, but now I think that was a mistake and I intend to add them back in to make this a ``complete' document. I'm thinking of expanding the document to cover development processes, other Unix and Unix-like systems (like the *BSDs), more about CGI and Java, and adding code examples. Recommendations and pointers to references are always appreciated. LinuxSecurity: Do you suggest any particular tools for auditing or development of secure software? Wheeler: I don't have any particular recommendations for program auditing tools. You might look at, for example, RST's ITS4. Be careful: RST says ITS4 is an "open source tool," but it's only free for non-commercial use, violating requirement 6 of the open source definition. I'm afraid this will confuse a lot of people. However, while I don't like RST's confusing use of the term "open source," I'm glad to see tools like this more widely available. Remember that any such tool can be very useful, but it'll still miss a lot; a clean run does not mean that the software is secure. As far as development goes, currently one of the biggest security problems are buffer overflows. Thus, from a security point of view I'd suggest using a programming language that prevents buffer overflows; Python, Perl, Java, Ada, Eiffel, LISP, and lots of others fit that bill. If you really want to use a language that doesn't include buffer overflow protection (say C or C++), be sure to use libraries that defend you against buffer overflows and be especially careful with every line of code. In the end, it's a truism that the most important tool for auditing or developing secure software is the onebetween your ears. Everything else pales in comparison. LinuxSecurity: Do you think open source software has the potential for being more or less secure than proprietary software? Wheeler: In general, I see open source software as having the potential for being much more secure. I'm not alone in this; other security specialists such as Bruce Schneier have come to the same conclusion (see his comments about this in Crypto-Gram or Linux Magazine). The argument is fairly simple: when you close off your software, only a small number of people can review your software to find (and fix) errors, and when your software is open source, you can have many more reviewers. I don't buy the argument that opening source aids attackers more than defenders; attackers have had disassemblers and other tools for years, so they don't need source code to attack. There is the danger that people can insert malicious code into open source code, but malicious code can also be inserted into proprietary code. Both have happened, and so far the open programs' malicious modifications have been detected and fixed much more rapidly (because it's easier to detect such things). I will say this greater security is a potential, not a foregone conclusion. Very early versions of open source software haven't gone through a peer review process, so they're probably no better until such a review has occurred. And of course, peer review only works when there's real peer review by experts. In particular, if the software is of interest to only a few, then there are fewer to do that review and probably less trust should be extended to the component. Finally, there has to be a maintainer willing to fix any problems found. LinuxSecurity: There's a lot of detail that has to be ``gotten right;' is making secure software hopeless? Wheeler: It's not hopeless; it's just not easy. Capturing lessons learned from other programs (as I've done) hopefully makes it a lot easier. Peer review helps too, especially if the peer reviewers know ofspecific problems to look for. I should note that things aren't really any easier with other computer technologies. It's no easier to make secure programs for other Unix-like systems; indeed, many of the same guidelines apply. It's no easier for Windows NT/2000-based systems; indeed, the fewer years of experience with it suggests that we've only begun to learn how to avoid its pitfalls, and the constant flow of security reports shows that it's not fundamentally easier to develop secure programs on it. It's not even necessarily easier with Java, depending on the kind of application you're building. Java prevents buffer overflows, but there are new and interesting attacks in Java because its security is enforced by software instead of more traditional hardware protection mechanisms. In Java, even a minor JVM break or weakness (in such details as type enforcement or data visibility) can cause Java's entire security edifice to crumble. For applications where the Java program mediates security, you still have the difficulty of ensuring that exactly the right service (no more and no less) is provided. LinuxSecurity: It's been said that the bazaar method of open source development is the same as the failed ``penetrate and patch' process. Do you agree? Wheeler: No, I don't agree, although I understand why they'd be confused. In the ``penetrate and patch' process, the software is completely developed without really thinking about security issues; the primary method to secure the component is having ``experts' penetrate it after development and then patching the holes found. Now, even some well-designed programs have had to be patched; the difference is that, in penetrate and patch, expert penetration is depended upon as the primary method for gaining security. It's been repeatedly shown that this doesn't work very well; in nearly all cases it's very difficult to retrofit security into a component not designed to be secure. Eric S. Raymond coined the term ``bazaar;' readers who aren't familiar with theterm should see his definition. In the bazaar method, software updates are released early and often (e.g., daily), with the intent of gaining rapid feedback from co-developers. A project using the bazaar method may or may not be using the ``penetrate and patch' process, depending upon whether or not component developers and reviewers consider the security ramifications of the initial version and proposed changes. If security issues are considered by contributors and reviewers of contributions, then the project isn't using the ``penetrate and patch' process, even if it's using the bazaar method. I think larger bazaars are more likely to consider security, since they're more likely to have members with security expertise, so I'd expect that larger bazaars would be less likely to follow a ``penetrate and patch' process. I'm not surprised these approaches would be confused because, in the bazaar method, the development process is public in a way that a proprietary products' process would not be. If the bazaar reviewers use the information in secure programming guidelines (like mine), then hopefully it will be even easier for bazaar developers to avoid a ``penetrate and patch' process. LinuxSecurity: Where do you see IT security going in the future? Wheeler: People and organizations are increasingly depending on the Internet, and they can't depend on it if their machines and networks can be easily damaged. So I see organizations and governments spending much more money to protect what's becoming an increasingly vital service. In particular, I hope that the U.S. government will spend some money to speed the securing of open source components, so that the U.S. infrastructure will become secure more rapidly. Computers will become more plentiful and available to more people. These people want to use these computers as tools and not worry about security problems. Thus, I expect that many machines' basic components will be automatically updated as necessary (just as Windows and Mac users' virus checkers areupdated now). You'll also see more emphasis on ease-of-use of security capabilities. These machines will have to support much finer protection between applications, so that running one application is much less likely to corrupt or expose the data of another (Java already does this). There will need to be more flexible security policies (since people's needs vary so much); there are already several efforts to implement more flexible security policies in Linux. LinuxSecurity: What are your future plans? Wheeler: I hope to be doing more things to improve Linux security. Linux's combination of power, flexibility, and extremely low cost are great advantages. If its security was even better and its policies more flexible, it could be used in even more situations. David A. Wheeler's website is at David A. Wheeler's Personal Home Page . . We thought it'd be interesting to interview David to learn more about his Secure Programming for Lin. linux, david, wheeler, author, secure, programming, howto', documentation. . Brittany Day
Feb 28, 2000
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More