FreeBSD Jails were so much better than everything else out there, for a long time. I'll just copy&paste part of a comment I wrote on another HN thread some time ago, since it's relevant here: [...] In fact, many years ago, when FreeBSD was my main OS (including on notebook) I went as far as to isolate each app that used internet into its own custom-setup jail [0][1]. I had Firefox, Thunderbird, Pidgin and a few other…
"... I even had a separate Firefox jail that was only allowed to get out via a Tor socks proxy to avoid leaks ..." I have looked into doing this many times and it's neither simple nor straightforward. Specifically: jailing a GUI app that you can interact with on your desktop. I can't remember what the most promising recipe I saw for this was but it wasn't quite promising enough to compel me to built it up ... and thi…
FreeBSD Jails for Fun and Profit (2020)
61–70 of 161 posts
Re: FreeBSD Jails for Fun and Profit (2020)
#62(FreeBSD) jails are amazing. I just wish there were easier ways to use them more "cattle"-like, so I can augment or replace Docker/Podman. At the moment tooling and many of the real-world setups remind me a lot of "pet" LXC containers or even VMs in the Linux world. The tooling is slowly moving in a direction I like, though :)
Re: FreeBSD Jails for Fun and Profit (2020)
#63Just curious, is there an equivalent (or at least similar in spirit) to FreeBSD jails in the Windows world?
Re: FreeBSD Jails for Fun and Profit (2020)
#64One thing I find so valuable about jails is the ability to jail a single command with no other userland than what that binary requires. Here's an example from my personal name server: /usr/sbin/jail /jails/www www 10.10.10.36 /lighttpd -f conf/lighttpd.conf ... and although this jail has a lot of content files in it, the actual UNIX userland is only what is required to run 'lighttpd': # find /jails/www/usr | wc -l 43…
Totally feasible on Linux, btw. Packaging an entire system is more about convenience than anything else. It's also pretty difficult to package just the libs one needs when you are dependent on libc and other C libs. I suspect that if one was really ok with it, some tooling could be built to copy/link in system libs into the rootfs automatically from the host.
It's pretty easy using Nix, e.g. this example defines a container for running a shell script: https://ryantm.github.io/nixpkgs/builders/images/ocitools
That script depends on bash, bash depends on libc, etc. so those dependencies (and only those dependencies) will be put in the container. (See https://nixos.org/guides/nix-pills/enter-environment.html#id... for an example of what dependencies look like in Nix).
> I suspect that if one was really ok with it, some tooling could be built to copy/link in system libs into the rootfs automatically from the host.
Eww, no thanks! I want my containers to be reproducible.
Re: FreeBSD Jails for Fun and Profit (2020)
#65I always hoped for macOS to borrow FreeBSD jails for itself. A Docker-like solution with a pretty UI could be really useful for pros. For novices, it could mean a less cumbersome security measure than the restrictions we’ve been experiencing since Catalina.
Re: FreeBSD Jails for Fun and Profit (2020)
#66One thing I find so valuable about jails is the ability to jail a single command with no other userland than what that binary requires. Here's an example from my personal name server: /usr/sbin/jail /jails/www www 10.10.10.36 /lighttpd -f conf/lighttpd.conf ... and although this jail has a lot of content files in it, the actual UNIX userland is only what is required to run 'lighttpd': # find /jails/www/usr | wc -l 43…
Re: FreeBSD Jails for Fun and Profit (2020)
#67I never understood the appeal of BSD jails over Solaris zones which seem to be more hardened and seem to vitualize more of the OS.
The issue with zones was the lack in the early days of GNU software and the difficulty in compiling certain things. For instance, awk can act differently and if you don't know the 25 year old decisions that led to the differences, it can be very confusing. (There are different behaviors and command line switches between GNU's AWK and the version from SVR4/XPG)
Re: FreeBSD Jails for Fun and Profit (2020)
#68Earlier quoted context omitted.
Counts what you are afraid against. There's always some side channel attack that could possibly used to gain information, even on VM's this is true. Off the top of my head there could be some timing attack to gain information on which libraries others are using by reading in libraries and seeing if they are warm in the buffer cache, counts if you care about sharing the same kernel. I generally find them secure enough…
Can a process in them exec on the rest of your system?
You can't even see a binary from the rest of your system, and exec won't get you out.
Re: FreeBSD Jails for Fun and Profit (2020)
#69One thing I find so valuable about jails is the ability to jail a single command with no other userland than what that binary requires. Here's an example from my personal name server: /usr/sbin/jail /jails/www www 10.10.10.36 /lighttpd -f conf/lighttpd.conf ... and although this jail has a lot of content files in it, the actual UNIX userland is only what is required to run 'lighttpd': # find /jails/www/usr | wc -l 43…
How does it know what is needed to run? What if its a program that controls another program via CLI?
Re: FreeBSD Jails for Fun and Profit (2020)
#70Earlier quoted context omitted.
Totally feasible on Linux, btw. Packaging an entire system is more about convenience than anything else. It's also pretty difficult to package just the libs one needs when you are dependent on libc and other C libs. I suspect that if one was really ok with it, some tooling could be built to copy/link in system libs into the rootfs automatically from the host.
> It's also pretty difficult to package just the libs one needs when you are dependent on libc and other C libs. It's pretty easy using Nix, e.g. this example defines a container for running a shell script: https://ryantm.github.io/nixpkgs/builders/images/ocitools That script depends on bash, bash depends on libc, etc. so those dependencies (and only those dependencies) will be put in the container. (See https://nixo…