Comment by rsync | Hacker News Reader

Comment by rsync | Hacker News Reader

One 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

So it's an extremely lightweight environment with very little attack surface.

You can also share a lightweight environment with multiple commands - here are two other jail commands:

  /usr/sbin/jail /jails/dns ns1 10.10.10.30 /nsd/nsd -c /nsd/nsd.conf
  /usr/sbin/jail /jails/dns dns 10.10.10.37 /unbound/unbound -c /unbound/unbound.conf

... see how both jailings of 'nsd' and 'unbound' point to the same '/jails/dns' userland ? Once again, that userland is very, very compact:

  # find /jails/dns/|wc -l
  97

... so, 97 files total to run both name servers.

No 'make world' necessary, no building and maintaining of a full FreeBSD system - just the lightest skeleton required for both 'nsd' and 'unbound'.

How does it know what is needed to run? What if its a program that controls another program via CLI?

One needs to assemble the jail. There may be tools for this, although I haven't used them. It's real easy if you can build a static executable, if it's a normal dynamic executable, you can use ldd (or something) to get all the libraries and just remember to pull in ld.so (the runtime linker). If it's dynamically loading modules (like Apache HTTP and PHP often are configured) or running other executables like you asked, that's harder to automate.

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://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.

Exodus?

Exodus – relocation of Linux binaries–and all of their deps–without containers - https://github.com/intoli/exodus

Can you use jails with, say, and a bindfs / overlayfs / snapshot type of file-system, to run an executable in a jail that's a restricted and read-only view of your currently running system?

I did some reading and it looks like FreeBSD's unionfs or nullfs would handle the file-system part.

Yes. If it's literally read-only then it's safe and easy (just use read-only nullfs); if it's to be writable, but read-only below (like overlayfs), you'll have to use unionfs which is still a bit... temperamental.

And? How is this more secure.

Just seems unnecessarily complicated.

It's more secure because you're minimizing the attack surface. The jailed process has no binaries an attacker can use to further exploit the system, not even a shell. It means that there's a minimal to non-existent /etc directory, meaning there is less information about the server and the network it's on. It also means there are fewer places to hide modules to persist, because you control so much of the tree.

Going further, you can place the few executable files you need in a read-only filesystem, so attackers can't copy their own payloads in, further restricting what they can do. You can continue that process with firewall rules that are much more restrictive than what you could use with a more general purpose server, such as blocking any traffic that isn't to or from port 80/443. You can also virtualize the network of a jail, so an attacker wouldn't even get information about the network's layout from a compromised jail.

Heard the same about SELinux.

Typical application attack path:

RCE in the app -> ability to use anything in the OS under the app user privileges -> privilege escalation -> The whole box pwned (including access to all your secrets and management credentials)

Remediation process: wipe the box

Attack path for an app within a jail:

RCE in the app -> ability to use anything in the OS but there is nothing to use, must bring own tools (not always feasible) -> privilege escalation -> JAIL is pwned but not the box

Remediation process: recreate the jail

The complete mess that is containers on linux seems a whole lot more complicated to me. Jails do what you want in a simple way that works; containers are endlessly customizable such that you require a whole runtime and management daemon and message-bus integration and goodness knows what else.

Reply on news.ycombinator.com