Another cool thing about jails is that they're really easy to convert to bhyve virtual machines if your security needs or general paranoia levels increase at any point.
FreeBSD Jails for Fun and Profit (2020)
111–120 of 161 posts
Re: FreeBSD Jails for Fun and Profit (2020)
#112Earlier quoted context omitted.
>Yes, the Linux API seems more flexible, but when you think about it, it really isn't, because all the models that actually make any sense can be implemented using simpler interface, which is what jails provide. Not really, the example of Docker would probably be the most straightforward there. I don't think it's possible to fully port Docker to jails or at least I've never seen a successful port, some of the network…
> Needing to be root is a major deficiency though Note: Linux also needs root for its namespaces. Or at least CAP_SYS_SYSADMIN, which grants enough that it's pretty much as good as root. See setns(2) and clone(2) for details. This is one of the complaints the plan 9 people have always had with Linux namespaces.
Not anymore, unprivileged user namespaces make it so you don't have to do that. That's how podman's "rootless containers" are able to work.
Re: FreeBSD Jails for Fun and Profit (2020)
#113Earlier quoted context omitted.
I'm using them for several things but the most straightforward one is probably that namespacing can be gradually added to services, you most likely see benefits from this already if you use systemd. That's one way that namespaces can be used in a different way from the docker model.
What are you adding gradually, specifically? Like, a concrete example that names a namespace you may want to use. I'm trying to figure out what problems a half sandbox solves, and a vague "I just want to enable some capabilities" doesn't help here.
A lot of the various security options in systemd: https://www.freedesktop.org/software/systemd/man/systemd.exe...
The sandboxing and mount-related ones are implemented with namespaces, and the idea with them is to not make any of them mandatory so they can be slowly added to system services. That way you can get some of the benefits without needing to build a full rootfs/container for the service. I am not sure how any of those would be done with jails because jails require you to create a chroot and network interface, whereas in Linux the mount and network namespaces are just optional namespaces and you can still use the other namespaces without using them.
Re: FreeBSD Jails for Fun and Profit (2020)
#114Earlier quoted context omitted.
In my experience, both Linux developers and BSD developers don't seem to care too much about porting things to the other's operating system. If you want to do things the Linux way you can use Linux, and if you want to do things the BSD way you can use BSD. That's seen as easier than trying to glue two incompatible things together.
BSD developers can't port things from Linux in a straightforward manner due to license issues. But that doesn't apply the other way around.
I don't see why. BSD and GPL are equally compatible, it doesn't matter which way you go. I can see why they wouldn't want a GPL component to be mandatory but it can be made an optional component for Linux compatibility which seems to be the way BSD would want it anyway.
Re: FreeBSD Jails for Fun and Profit (2020)
#115Earlier quoted context omitted.
They are completely different mechanism for doing different kind of stuff. Firejail sounds like something closer to Capsicum, but without the security model.
Could you elaborate on the differences? As far as I understood it firejail, or rather the Linux features that it depends upon, is far more powerful than FreeBSD jails.
From what I understand, firejail is a "syscall filter". This moves it to the same category as capsicum (https://www.freebsd.org/cgi/man.cgi?capsicum), but without Capsicum's security model, instead implementing something ad-hoc, probably by using Linux' seccmp.
Jails, on the other hand, are not a sandboxing mechanism - they are system-level virtualization, like Linux namespaces, but with a simpler interface. You can use it for sandboxing, but it's not what the mechanism fundamentally is.
Re: FreeBSD Jails for Fun and Profit (2020)
#116One 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…
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.
Re: FreeBSD Jails for Fun and Profit (2020)
#117Earlier quoted context omitted.
Depends on the industry. For general purpose computing it’s generally not an issue but it does matter for some specific workflows. I tend to look at it the other way though: given containerisation is so easy these days, what are the compelling reasons to run virtual machines. Neither is a wrong answer though.
VMs still provide better isolation and security, or is that no longer true?
They do but not by a significant margin these days.
The kind of domains where this is an issue isn’t what you’re average engineer would be concerned with.
Where VMs do help the average engineer is they have more secure defaults. It’s pretty easy to accidentally run containers insecurely on Linux (FreeBSD jails are a better story though)
Re: FreeBSD Jails for Fun and Profit (2020)
#118One 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…
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.
Re: FreeBSD Jails for Fun and Profit (2020)
#119One 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…
And? How is this more secure. Just seems unnecessarily complicated.
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