Date: Fri, 12 Jan 2024 19:58:43 GMT From: Kyle Evans <kevans@FreeBSD.org> To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org Subject: git: 5df041c4bbf7 - main - bhyveload(8): document some SECURITY CONSIDERATIONS Message-ID: <202401121958.40CJwhlV002242@gitrepo.freebsd.org>
next in thread | raw e-mail | index | archive | help
The branch main has been updated by kevans: URL: https://cgit.FreeBSD.org/src/commit/?id=5df041c4bbf70d549b055f332630925295ad5aaf commit 5df041c4bbf70d549b055f332630925295ad5aaf Author: Kyle Evans <kevans@FreeBSD.org> AuthorDate: 2024-01-12 19:57:53 +0000 Commit: Kyle Evans <kevans@FreeBSD.org> CommitDate: 2024-01-12 19:58:16 +0000 bhyveload(8): document some SECURITY CONSIDERATIONS The situation is improved now that we're running in a sandbox, but there is still some host machine access that could be concerning depending on the context. These concerns may be somewhat mitigated by the fact that the host machine usually provides the loader binary, even when the guest image is providing the loader scripts -- they only bring the lua scripts, and they have to be able to execute arbitrary syscalls rather than the interfaces provided by libsa(3). Reviewed by: jhb, markj Differential Revision: https://reviews.freebsd.org/D43299 --- usr.sbin/bhyveload/bhyveload.8 | 42 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 41 insertions(+), 1 deletion(-) diff --git a/usr.sbin/bhyveload/bhyveload.8 b/usr.sbin/bhyveload/bhyveload.8 index edeb8ee938f4..54e326e49c8c 100644 --- a/usr.sbin/bhyveload/bhyveload.8 +++ b/usr.sbin/bhyveload/bhyveload.8 @@ -23,7 +23,7 @@ .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" SUCH DAMAGE. .\" -.Dd June 24, 2016 +.Dd January 12, 2024 .Dt BHYVELOAD 8 .Os .Sh NAME @@ -171,3 +171,43 @@ at NetApp Inc with a lot of help from can only load .Fx as a guest. +.Sh SECURITY CONSIDERATIONS +Note that in some configurations, +.Nm +will execute guest loader scripts in the context of the host machine. +Note, however, that +.Nm +will enter a +.Xr capsicum 4 +sandbox before it loads the +.Ar os-loader +or executes any loader scripts. +On the host filesystem, the sandbox will only have access to the path specified +by the +.Fl h +flag, the contents of the +.Pa /boot +directory if +.Fl l +was not specified, and the chosen console device. +.Pp +Note that the guest loader scripts are already subject to some limitations that +are not relaxed simply because we are running in userland. +For instance, any I/O on the loader's +.Dq host +device that can be done in loader scripts is limited to the interface that +.Nm +provides, which itself will restrict paths that can be touched to those within +a specified +.Fl h +directory, if any. +Access to files within +.Pa /boot +inside the sandbox would require arbitrary code execution in userboot, and +userboot is usually provided by the host machine rather than anything that is +a part of the guest image. +All access to the +.Fl h +directory as well as +.Pa /boot +is strictly read-only in the sandbox.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202401121958.40CJwhlV002242>