Slashdot Mirror

My thoughts on FreeBSD vs Linux... FreeBSD chroot jails are more secure than Linux chroot jails. Even says so in the Ubuntu man pages: http://manpages.ubuntu.com/manpages/jaunty/man2/chroot.2.html
http://www.bpfh.net/simes/computing/chroot-break.html

FreeBSD also has kernel-level virtualized jails which are far more secure than chroot jails, and a virtual network stack for jails is right around the corner (vimage/vnet). Then there's also the kernel securelevel, extended attributes/ACLs, TrustedBSD/MAC, and pf/ALTQ which is far superior to iptables. BSD has really been leading Linux in the area of security--Linux is more focused on spreading GPL and getting the media wheel on your USB keyboard to work.

I would say that Linux has much more diverse hardware support and more complete support for cutting-edge whiz-bangs and desktop gadgets like sound cards and webcams--although current FreeBSD is not too far behind. Meanwhile, FreeBSD is focused on powerful features for administration and for servers, such as jails, pf, ZFS, netgraph, GEOM framework, HAST replication, CARP failover, consistent integration of kernel and userland, consistent interface for startup scripts, the ports system and repository, etc.

Of course FreeBSD has the better license without question.

I think the clear choice for security and network related infrastructure is always a BSD box. The only times I choose Linux are when I'm forced to, such as installing to embedded hardware or using as a desktop/workstation.

http://www.bpfh.net/sysadmin/never-underestimate-bandwidth.html

Bah humbug. I can't see how to PM @ /. - So I'll just reply here. BSD appears to be different, but on most unices http://www.bpfh.net/simes/computing/chroot-break.html

How much licensing revenue do content producers get per user per month from all radio stations radio listened to by the upper 1/3 of listeners + amount of revenue from purchased CD's, discounting production costs?

Seems to me like they should be able to break down using surveys how much money they should charge.

Another possibility is that instead of p2p or CDs, ship hard drives back & forth to users. Update whats on the hard drive with related songs. This falls under the category of "Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway"

See the hilarious Mad Max version at the bottom of http://www.bpfh.net/sysadmin/never-underestimate-bandwidth.html

If you execute chroot() and then a seteuid(uid) where uid>0, then you prevent a hole/bug in your program from being exploited in a way that will allow file access/execution outside the chroot. That *is* a security advantage.

According to the page about breaking out of chroot linked from the discussion, the seteuid() is not effective because the process still has a real UID of 0 and can call seteuid(0) at any time.

So don't use seteuid--use setuid (without the "e"); this is what the article that you just cited indicates:

If this [setuid to non-root] is done there should be no way to gain root privilages unless an attacker uses something within the chroot() jail to gain those privilages.

According to the page about breaking out of chroot linked from the discussion, the seteuid() is not effective because the process still has a real UID of 0 and can call seteuid(0) at any time.

You can create a chroot without any directories with mode 7771 privileges (a la /tmp), that is free of any setuid binaries, and without "useful" utilities like wget or curl that can make exploiting the system child's play. If your program runs inside of a chroot as a non-root user, and your chroot has no setuid binaries, and your kernel has no privilege escalation vulns, then you can be reasonably sure that nobody will break the chroot or achieve privilege escalation.

This isn't news.

For those of you who weren't aware how easy it can be to break out of most chroots, here's a good description of a common process:

http://www.bpfh.net/simes/computing/chroot-break.html

Never underestimate the bandwidth of a station wagon...

Still very much applies today.

Ryan Fenton

If you have root priviliges, chroot is pointless. You can easily break out.

* IN A your.ip.addr.ess

UseCanonicalName Off
RewriteEngine on
RewriteMap lowercase int:tolower
RewriteRule ^(.+)$ ${tolower:%{SERVER_NAME}}$1
RewriteRule ^w+\.(.+)$ $1
RewriteRule ^(.+)$ /var/www/virtual/$1 [L]

Well, the whole UUCP mechanism was developed over time. Allowing dial-up access between machines to transport big bunchlets of email and what-not.

But in the early days, most UNIX software was transported around on tape. Proverbally in the back of station wagons.

From Moe and Curly's Software Emporium no less!

No, Windows doesn't have chroot(), largely because of the legacy of drive letters, which means we don't have a single controllable root on Windows.

But chroot is really just a nifty short cut for restricting file system access - meaning you're probably using root for your process - bad. And it certainly isn't unbreakable if you're using root for your processes. ACLs can achieve the same effect, but with more work for the Admin.

I agree that 98% of Windows boxes are not adequately secured. My guess is that 85% of Linux boxes are also not adequately secured. I think XP SP2 and Server 2003 are great steps in the right direction toward good default configurations. I think Automatic Windows Update is a huge part of the solution. I think Windows app developers need to be flogged when Admin rights are required to run their app.

That's why I said "or your favorite buffer overflow exploit"; I just picked HTTP for an example because it's one of the better-known cases. My point is that "local" vulnerabilities become remote ones when paired with buffer overflows in programs accepting remote input.

Besides, you can break out of a chroot jail.

["Never underestimate the bandwidth of a vanload of tapes barrelling down the highway"]
I've seen this a couple times before, but Google seems to come up with nothing useful for it.

That's because the original is "station wagon" (or "stationwagon"). Another common variant is "a 747 full of...". See e.g. this story

And no, it's certainly not Tannenbaum 1996; it was (IIRC) mentioned in Bentley's "Programming Pearls" CACM column/book in the 1980s. It's unclear that anything original can be attributed to Tannenbaum (okay, that's flamebait, but Tannenbaum irritates me).

http://www.bpfh.net/microsoft/win98-ate-pc/

For all the pictures of burnt-out and gunk-filled hardware you could ever want.

So as I can't comment on the article itself I thought that it might be mentioning that chroots are good but no infalliable. If someone can get root permission inside a chroot you can break out

Rus

See this RFC on A Standard for the Transmission of IP Datagrams on Avian Carriers

So, while chroot may be good, do not rely on it soley for security.

Though it seems like a virtual system, a chroot cell is not totally virtual, and there can still be plenty of comprosmises.

Like usual, all you need is access to a compiler, and you can make a jailbreak. In fact, there's a whole guide to it here:

http://www.bpfh.net/simes/computing/chroot-break.h tml

If the whole jail resided in its own actual virtual Linux machine, where nasty things cannot break the account, just the session, they would be quite a bit more effective.

"Never underestimate the bandwidth of a station wagon full of tapes" - SysAdmin humor

I heard somewhere that MCSE was an abbreviation for Minesweeper Consultant and Solitaire Expert.

There are a few others here as well.

Definitions of MCSE