This question has three aspects, because I can't expose a directory in a jail without also checking symlink security and jail users/groups' security, to make sure that these common functions aren't left in a state that lets a user escape the jail.
Q.1 - exposing a path fully:
I want to expose part of my main pool within the jail, read only. I learned this is done using
With this data pool, I want to expose
When I use
Is there a way to get around this?
Q.2 - ensuring symlinks stay safe and jail access is limited to the stated path:
Of course executables in the jail must not be able to access anything outside the path
I have in mind an equivalent effect to Samba's "allow insecure wide links = no" - a way to disallow the jail from accessing unauthorised paths even if accidentally/maliciously reachable by links/mounts. How does one prevent that? Or do I just use uid/gid controls and
I'm assuming there must be some control, otherwise the jail's root account with id=0 could map to a non-jail privileged account ID and run rampage on the main file system? But iocage jail accounts/permissions/controls aren't well described in any docs I can find.
Q.3 - ensuring jail accounts can't misuse jail account -> nonjail account mapping:
I can't sort out #2 fully without considering users and groups, but I can't find docs covering this.
Are there any resources or web links that cover in depth, details about users/groups/permissions/security handling for iocage jails when they have access to outside file paths? Specifically I'm considering things like mapped users/groups, and how this works from a security point of view - a security oriented resource that explains how it works and how to mitigate risks, that focuses on this aspect.
By which I mean, learning about how user/group mapping+security works with iocage jails, in the sense of what allows or prevents a privileged jail user from creating an account that maps to a non-jail account, or mapping the jail root account, and using it to escape and do harm outside the jail. And of course, what kinds of config/perms setup can be used to mitigate this.
Q.1 - exposing a path fully:
I want to expose part of my main pool within the jail, read only. I learned this is done using
iocage fstab /path_to_real_dir /path_to_jail_mountpoint nullfs ro 0 0. But my real dataset spans subdatasets, and those aren't being exposed: # zfs list
pool
pool.data1
pool/data1/data2
pool/data1/data2/data3
pool/data1/data2/data4
pool/data1/data2/data4/data5
pool/data1/data2/data6
pool/data1/data7
pool/data8
... etcWith this data pool, I want to expose
pool/data1/data2 and all its contents (which span various child datasets) in a jail, and have them seen the same as they are outside the jail, but read only.When I use
iocage fstab to expose pool/data1/data2, it doesn't expose the children, just their mountpoints, I see almost nothing. I could individually run iocage fstab for each and every dataset contained within pool/data1/data2, but that's impractical as new datasets might be created on the spot or at any time, which can immediately be browsed outside the jail, but would need a privileged account and use of iocage commands from outside, before they can be seen in the jail. I suspect the changes to iocage fstab would also need the jail restarted to work, which is a no-no.Is there a way to get around this?
Q.2 - ensuring symlinks stay safe and jail access is limited to the stated path:
Of course executables in the jail must not be able to access anything outside the path
pool/data1/data2/***. There should never be any symlinks/hard links/mounts within the tree exposed to the jail, which would let them traverse elsewhere. But that's a "soft" control - if they're created (by accident or malice) then the control totally fails. Is there a way to be more sure that even if links/mounts exist within the tree exposed to the jail, that they can't be followed from within the jail to undesired non-jail paths?I have in mind an equivalent effect to Samba's "allow insecure wide links = no" - a way to disallow the jail from accessing unauthorised paths even if accidentally/maliciously reachable by links/mounts. How does one prevent that? Or do I just use uid/gid controls and
deny ACLs to prevent any account within the jail from having any rights anywhere it shouldn't? Will that work?I'm assuming there must be some control, otherwise the jail's root account with id=0 could map to a non-jail privileged account ID and run rampage on the main file system? But iocage jail accounts/permissions/controls aren't well described in any docs I can find.
Q.3 - ensuring jail accounts can't misuse jail account -> nonjail account mapping:
I can't sort out #2 fully without considering users and groups, but I can't find docs covering this.
Are there any resources or web links that cover in depth, details about users/groups/permissions/security handling for iocage jails when they have access to outside file paths? Specifically I'm considering things like mapped users/groups, and how this works from a security point of view - a security oriented resource that explains how it works and how to mitigate risks, that focuses on this aspect.
By which I mean, learning about how user/group mapping+security works with iocage jails, in the sense of what allows or prevents a privileged jail user from creating an account that maps to a non-jail account, or mapping the jail root account, and using it to escape and do harm outside the jail. And of course, what kinds of config/perms setup can be used to mitigate this.
Last edited:
