Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
There is less than 24 hours left to vote in the 2015 LinuxQuestions.org Members Choice Awards. Click here to go to the polls. Vote now and make sure your voice is heard!
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I agree. Especially if you take some extra steps to secure the box, like using "lcap" to take away some LINUX_CAPABILITIES (caps intended), like the ability to load modules after boot, run suid and sgid apps or be able to create devices (which can also lead to some breakage).
Btw, if you choose to patch your kernel with GRSecurity you'll get a lot more options to restrict chroot breakage and a lot more.
Originally posted by akohlsmith
- chroot is trivial to escape from once root is gained
When you have setup a chrooted environment your attention move to root gaining methods: if your jail is in a partition mounted with nosuid, any process in the jail run as its own user, you have blocked dev creation and module loading, ... chroot is NOT trivial to escape, because gaining root in this env. is VERY hard!
Surely no defense is unbreakable but you can make probability lower and that's your job.
- chroot'ed environments need to be set up for each daemon which is a major PITA
Climbing computer security's stair is harder at any step and setting up chrooted environment is not the first, but if you want go higher (and you have time to spend ) it worth his price.
- run the daemon as its own user instead
This is a must for any daenmon but some need root privileges and that's a pain.
I agree that security is important. However the world of network security is a world of diminishing returns. Where on the graph you decide is secure enough depends on the situation.
For me, I have a set of daemons which I more or less 'trust': OpenSSH, ProFTPd, Apache+mod_perl+mod_ssl, recent BIND, qmail+vpopmail+courier IMAP, PostgreSQL, GNU-RADIUSd, NTPd.
Anything else that I'm not familliar with I would escalate the level of security somewhat along the lines of what you suggest, although what I usually do is put them on a separate server with the relevant ports forwarded and anything originating from it blocked and logged.
To me, having separate partitions and chrooted jails and so on is beyond where I'm willing to go; if I can't trust the app that much I will try to find something else, although I do admit that it is an interesting technique!
Distribution: Slackware, (Non-Linux: Solaris 7,8,9; OSX; BeOS)
Since this thread was resurrected, I'll just post my $0.02.
I use chroot for completely non-security related work, and something that I doubt the chroot developers had in mind. I use it to setup/configure a newly installed OS while the old one is still running.
This requires, of course, enough disk space to have two OSs installed, but with such cheap hard drives, who doesn't have the space?
Believe it or not (probably not ) that's what got me thinking about all this kind of stuff. I've been chrooting into a Gentoo I've been configuring for me. I'm trying to get it all setup to a point where I can boot back and forth between my main distro and it, seamlessly. Each time I do things with it I chroot myself into the / partition of the gentoo env.
Yeah, I wouldn't believe me either, sure sounds like I'm just trying to sound as cool as Moses
lcap.c is a nice program. It is clean and works. Have you ever used the "secumod" package bundled with SuSE but not installed by default? http://www.suse.de/en/private/suppor...ecure_webserv/ explains a little about it. At only 25kb, it doesn't kill my memory and it's performance impact isn't noticeable.
Distribution: Slack 8.1, Gentoo 1.3a, Red Hat 7.3, Red Hat 7.2, Manrake 8.2
chroot can be a pig to set-up as I can atest to, but in my opinion any system with Bind or Apache on it should run these jailed.
Yes Apache needs lots of stuff to run when being used in a Commercial environment e.g. Openssl, php and access to a database connection.
However once you nail down all of the issues and get it working its relatively easy to start Apache on boot chrooted and to ensure all other systems function Okay. Im talking from my recent experience of jailing Apache 2.0 with ssl and php support and a need to access a mysql database so if anybody disagree's then fine but In my opinion when looking at the possible problems that can be caused when runnign a web server that allows scripts and cgi then allowing it to run un-jailed is taking quite a risk.