Jails so thin that they are totally empty:
https://freebsdfoundation.org/wp-content/uploads/2020/03/Jail-vnet-by-Examples.pdf
No config file needed.
In that article's example, Cochard-Labbe uses empty jails as nodes to demo some vnetting. It's worth a read because if you have any number of jails going, you're almost certainly going to want to handle the routing. There are some interesting examples in there with sequential routing; I found those useful for sequential tasking; for example, you can use one jail to filter, another jail to pcap traffic, another to serve the application, and then route the traffic out.
I had one jail one time that only held a binary of nano. I just kept it on a thumb drive; whenever I wanted to use nano on a LiveCD system, I would just build a jail and attach that storage into /tmp. It was handy, but I always felt a little risky about thin jails. It seemed to me that when you make your jail thin, there was a chance to be taken and a choice to be made: how well are you willing to research the system needs of that program that's being put in the jail? Honestly, except for the smallest homemade programs, I would probably not do the work to ensure that all of the system needs of a program were being met by a thin jail.
When I think of a big program like Firefox, I ask: what kind of system calls might be needed to keep that thing running? What parts of the system might be needed to ensure that those programs were always available and fully supported? Since I'm often not willing to do that research, sometimes the answer is to play it safe and use a thick jail.
I have just stuck a binary in a jail and run it, but then I was taking a chance: that it was safe to blindly put the binary in the jail and run it because there were no system dependencies. If there had been a need for one, and it was absent, then the program would be in a state likely to terminate or throw an exception. Since I could spend a very long time, say years, reading and understanding the code behind a modestly complex program (like Firefox), it just didn't seem practical to avoid using an underlying operating system.
This opens up an interesting possibility: what about configurations that allow a jail, or child jail, access to the parent's system? Maybe those paths would lead to a reasonably safe thin jail configuration. If you delve into the world of hierarchical jails, it is probably possible to wrap a child jail in a parent jail as a way of keeping a perimeter up-to-date. That is, the child may be an older BSD version so long as the parent is younger.
In the case of the thin jail, I just built an empty jail, assigned storage, and put a binary in it. I activated it with jexec, if I remember right. There was no configuration file needed for that. Thin jails seemed like a mystery to me at the time, but the answer really was as simple as it sounded: you can put in there whatever you want; but you have to put in there whatever you need to make what you want work.
To delve into what it takes to make Firefox work or build, it might help to look into poudriere servers and do a couple Firefox builds. This tutorial from 2015 served me well, back when:
https://www.digitalocean.com/commun...m-to-create-packages-for-your-freebsd-servers
Best book I've found on jails was from mwl.io:
https://www.tiltedwindmillpress.com/product/fmjail/
One last thing: sometimes it's not just the jail's config, but the parent system's settings that can be pertinent. Like forward ip routing as a sysctl, the parent system's rules will limit how jails function. It may help to look into those as well. Some of those ideas are covered in those references.
Hope this helps. Good luck.
