from the Do-not-pass-Go,-Do-not-collect-$200 dept.
Klara Systems has an article with a deep dive into the origins of FreeBSD jails. These ideas have been around for many decades and taken form in several stages and finally became part of FreeBSD over 20 years ago. FreeBSD jails share the main system's kernel and are therefore a relatively light weight means for userspace isolation, compared to "containers". Within the jail, the environment appears as a normal system and processes within the jail can not see upward into the host or laterally into other jails.
In the late 1990s, [Poul-Henning] Kamp was contacted by a man from South Carolina named Derrick T. Woolworth. Woolworth had a problem and was looking for a solution. He ran a web hosting company named R&D Associates Inc and he “had this idea for running multiple different versions of Apache and MySQL on the same server”. Woolworth “complained about the fact that different customers in his webhotel needed different versions of apache, mysql, perl etc, and that this forced him to run many machines, each almost idle, just for these different software loads.”
Woolworth offered to pay for the development of such a feature. “The deal was that he would pay for the development and then after one year I would commit them to FreeBSD.” With that Jails were born. After Woolworth’s year of exclusivity expired, Jails were included in FreeBSD 4.
(Interestingly, the first use of jail in the computer world was in 1991. An AT&T researcher named Bill Cheswick created what he called a “chroot ‘Jail’ ” to watch a hacker trying to get into their systems.)
Jails allow “administrators to partition a FreeBSD computer system into several independent, smaller systems – called “jails” – with the ability to assign an IP address for each system and configuration.” Jails is a method for giving “permission to access certain isolated areas of the operating system. Other jails remain completely untouched. Almost the entire isolation magic occurs at the kernel level; users only ever see the components they are supposed to see.”
As Kamp explains it, “Jails is like a one-way mirror.” He said further, “This means that an unjailed process can see all the jailed processes and, subject to UNIX access controls, send them signals, attach debuggers to them and so on. But the jailed processes cannot ‘see’ out of their jails, neither into other jails, nor into the unjailed part of the system.”
chroot, the progenitor to jails, probably first turned up sometime between 1975 and 1979 in 2BSD.
Previously:
(2018) FreeBSD Celebrates 25th Anniversary, Tuesday, June 19th
(2016) FreeBSD Devs Ponder Changes to Security Processes
(2016) Beat This: Server Retired After 18 Years and 10 Months
(2014) How to Avoid Systemd?
Related Stories
jbernardo writes:
"Having had several issues with systemd, and really not liking the philosophy behind it, I am looking into alternatives. I really prefer something that follows the Unix philosophy of using small, focused, and independent tools, with a clear interface. Unfortunately, my favourite distro, Arch Linux, is very much pro-systemd, and a discussion of alternatives is liable to get you banned for a month from their forums. There is an effort to support openrc, but it is still in its infancy and without much support.
So, what are the alternatives, besides Gentoo? Preferably binary... I'd rather have something like arch, with quick updates, cutting edge, but I've already used a lot in the past Mandrake, RedHat, SourceMage, Debian, Kubuntu, and so on, so the package format or the package management differences don't scare me."
[ED Note: I'm imagining FreeBSD sitting in the room with the all the Linux distros he mentioned being utterly ignored like Canada in Hetalia.]
El Reg reports
A chap named Ross, says he "Just switched off our longest running server".
Ross says the box was "Built and brought into service in early 1997" and has "been running 24/7 for 18 years and 10 months".
"In its day, it was a reasonable machine: 200MHz Pentium, 32MB RAM, 4GB SCSI-2 drive", Ross writes. "And up until recently, it was doing its job fine." Of late, however the "hard drive finally started throwing errors, it was time to retire it before it gave up the ghost!" The drive's a Seagate, for those of looking to avoid drives that can't deliver more than 19 years of error-free operations.
The FreeBSD 2.2.1 box "collected user session (connection) data summaries, held copies of invoices, generated warning messages about data and call usage (rates and actual data against limits), let them do real-time account [inquiries] etc".
[...] All the original code was so tightly bound to the operating system itself, that later versions of the OS would have (and ultimately, did) require substantial rework.
[...] Ross reckons the server lived so long due to "a combination of good quality hardware to start with, conservatively used (not flogging itself to death), a nice environment (temperature around 18C and very stable), nicely conditioned power, no vibration, hardly ever had anyone in the server room".
A fan dedicated to keeping the disk drive cool helped things along, as did regular checks of its filters.
[...] Who made the server? [...] The box was a custom job.
[...] Has one of your servers beaten Ross' long-lived machine?
I'm reminded of the the Novell server that worked flawlessly despite being sealed behind drywall for 4 years.
Arthur T Knackerbracket has found the following story:
The developers of FreeBSD have announced they'll change the way they go about their business, after users queried why known vulnerabilities weren't being communicated to users.
This story starts with an anonymous GitHub post detailing some vulnerabilities in the OS, specifically in freebsd-update, libarchive, bspatch and portsnap. Some of the problems in that post were verified and the FreeBSD devs started working on repairs.
But over on the FreeBSD security list, threads like this started asking why users weren't being told much about the bugs or remediation efforts. That's a fair question because updating FreeBSD could in some circumstances actually expose users to the problem.
Now the FreeBSD team has answered those questions by saying “As a general rule, the FreeBSD Security Officer does not announce vulnerabilities for which there is no released patch.”
The operating system's developers and security team are now “reviewing this policy for cases where a proof-of-concept or working exploit is already public.”
That post also explains that the team is considering more detailed security advisories. There's also an admission that the proposed patch may have broken other things in the OS.
The post concludes by saying that the FreeBSB core and security teams are working with all due haste to fix things and will let those subscribed to its mailing lists know when patches are ready and the danger is past.
[The majority of SoylentNews.org's servers run Ubuntu 14.04 LTS (Long Term Stable version). Upgrading to version 16.04 LTS would expose our systems to systemd and there has been some discussion among staff about our options. One option under consideration would be FreeBSD. Are there any Soylentils who run FreeBSD? What has your experience been? Any surprises to share with the community? --martyb]
The FreeBSD Foundation has announced that the name FreeBSD turns 25 years old on 2018-06-19. The mailing list archives contain a thread about name selection with with a message containing the following suggestion
How about just simply "FreeBSD"? No confusion, no fuss, seems like a good compromise to me. :-)
(Score: -1, Spam) by Anonymous Coward on Saturday March 06 2021, @05:24AM (2 children)
NIGGER
(Score: 2, Touché) by Rosco P. Coltrane on Saturday March 06 2021, @06:48AM
Indeed, an excellent and a-propos social commentary on the abnormal race disparities in jails.
(Score: 0) by Anonymous Coward on Sunday March 07 2021, @06:17PM
Damn it Trump! How many times do we have to tell you to go away?!
(Score: 2, Interesting) by Anonymous Coward on Saturday March 06 2021, @07:33AM (7 children)
Indeed, almost everything you need to know about jails can be learned by reading the chroot()-related man pages, and it has been around for decades.
The chroot() system call is integral to booting CDROMs - you have to load a copy of your filesystem into memory and then perform a chroot() to the root of the new filesystem, in memory. I think it played a role in ND (Network Disk, a predecessor to the Network File System, for diskless workstations, back in the 68000 days), as well, and NFS, following that.
Jails are a practical application for a system call that was usually used just once, at boot time.
Raise your hand if you know what L1-A does, and know that you are one of a steadily shrinking minority.
(Score: 4, Informative) by pe1rxq on Saturday March 06 2021, @09:39AM (3 children)
jails do more than just chroot.
chroot gives you a different view on the filesystem, but the rest of the system is still shared. For example with 'ps' you will still see binaries running outside your chroot.
With jails you can actually get a separation of the rest of the system as well, including its network stack.
(Score: 4, Informative) by TheRaven on Saturday March 06 2021, @11:55AM
The original jails implementation was far from complete. It didn't give you a separate namespace for SysV IPC, for example, which meant that you couldn't run PostgreSQL in a jail securely (there was a sysctl to turn of SysV IPC in jails entirely, but then PostgreSQL didn't run at all, if you turned it on then your jail could access any SysV IPC objects). This was fixed later, though Solaris Zones actually did it first.
The network stack virtualization (VNET) was even more recent. Amusingly, part of the motivation for jails was that it's less overhead to share a kernel across virtual systems than to run a full VM, but with the network stack it turned out that you got a lot more resource contention by adding a load of jails to the network stack. It was much faster to have a separate copy of all network-stack state.
sudo mod me up
(Score: 2, Touché) by leon_the_cat on Saturday March 06 2021, @12:27PM (1 child)
Great! But I tried running epstein.sh script inside one and now its dead. Just checked the log and it says it didn't kill itself. Any ideas??
(Score: 0) by Anonymous Coward on Saturday March 06 2021, @03:51PM
Yes. Stop watching the news.
(Score: 2) by sjames on Saturday March 06 2021, @10:49AM
A caution though, chroot is not jail. On many systems (including Linux) chroot is not regarded as a security measure and so can be escaped.
(Score: 0) by Anonymous Coward on Saturday March 06 2021, @12:36PM (1 child)
Raises Hand
Hello my friend.
That is a sequence I haven't pressed since-
(Score: 1) by crotherm on Saturday March 06 2021, @06:49PM
Suns Only. Yep, it's been a while. Almost forgot, repressed memories. heh
(Score: 2, Informative) by toph on Saturday March 06 2021, @01:01PM (1 child)
As others have said, chroot alone is not a jail.
(Score: 0) by Anonymous Coward on Saturday March 06 2021, @05:21PM
Prior chroots do not a prison make.
(Score: 2) by corey on Saturday March 06 2021, @10:29PM (2 children)
Why would I want to use jails? I’ve been running FreeBSD on my server for years, doing proxy, samba, nfs, zfs, pf firewall etc. I see so much discussion on the forums about jails but I’m not sure why someone like me would use this function, with no multi user system.
(Score: 2) by jimtheowl on Monday March 08 2021, @05:27PM
It also makes it easier to run linux services.
https://wiki.freebsd.org/LinuxJails [freebsd.org]
(Score: 0) by Anonymous Coward on Monday March 08 2021, @08:26PM
to isolate an application that could get compromised?