On Saturday, 16 May 2020 17:28:46 PDT Eugene Grosbein
wrote:> 17.05.2020 7:02, Ihor Antonov wrote:
> > So far it seems that my endeavor is doomed. Any comments or
suggestions
> > are
> > appreciated.
>
> You'll need to write and test lots of kernel-level code to achieve
this.
>
> I'd suggest you re-think your decision about jails because it seems
jails
> can really be the solution if you combine jail with other system abilities.
> For example, sharing subtree with r/o access is easily achieved using
> read-only nullfs mount.
Jails have a lot of drawbacks to.
In most basic (by the book) example you effectively end up with a separate
machine, which just happens to share same kernel with the host. And you need to
manage
this machine separately patches, upgrades, etc. (viva tools like
ansible / chef)
This is not very different from "just put it on a different VM"
suggestion.
If you try to go off the handbook script and try using nullfs and unionfs to
re-use pieces of your FS you quickly find out how limited those tools are.
You can't mount a single file into a directory, nullfs and unionfs
operate only on directories. Example: try to put a file into jails /etc.
Your options are: a) mount the whole directory and duplicate/overwrite
(depending on how
exactly you do it) a lot of files b) copy the file
In either case you are not far off the "separate VM" management
scenario
You also can't just mount / to /path/to/jail - so you end up mounting
/bin /etc /sbin ... into the jail with a separate commands. And this is possible
to do, but now
you can't use a lot of conveniences that jail.conf
has because your custom mounts conflict with jail's mount.* directives
(and the order in which they execute is undocumented)
I tried jails and was left disappointed. Jails are just VMs, trying to treat
them somewhat closer to Linux containers is not justifiable given how much
trouble it brings.
> Also, shared PAM does not mean duplication of system user database,
> take a look at: man -k pam_|fgrep '(8)'
The idea was to have a lightweight solution with minimum moving parts. Bringing
machinery
like LDAP into this defeats the purpose of the exercise.
> Usage of jails does not require any modification of the application.
> I did it for multiple setups and it works perfectly.
>
> As last resort, you may run nested FreeBSD system using bhyve(8).
Not an option as defeats the purpose of the excercise.
--
Ihor Antonov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freebsd.org/pipermail/freebsd-security/attachments/20200520/1b1eab82/attachment.sig>