Date: Tue, 16 Oct 2018 19:50:50 +0000 From: bugzilla-noreply@freebsd.org To: jail@FreeBSD.org Subject: [Bug 211580] deny system message buffer access from jails Message-ID: <bug-211580-29815-bKkRNndoQV@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-211580-29815@https.bugs.freebsd.org/bugzilla/> References: <bug-211580-29815@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211580 --- Comment #19 from Jamie Gritton <jamie@FreeBSD.org> --- (In reply to Joe Barbish from comment #18) 1. The "sysctl" command: the sysctl MIB that the command is an interface to contains a wide variety of things, many of which jails have no need to see,= and some of which (e.g. kern.hostname) are considered essential for normal operation, and doubtless some in between. Many of the jail permission bits= are already tied to specific parts of the MIB, but it doesn't make any sense to wholesale turn off the ability to retrieve data via sysctl. It might make sense to have some kind of jail-readable flag for sysctls, similar to the jail-writable flag that already exists (CTLFLAG_PRISON), but there are many per-value judgement calls to make there. 2. The "kenv" command and associated system call: none of this information looks particularly useful to jails, but neither does it look particularly dangerous. At first glance, that's a similar situation to dmesg, but the problem with the latter is there's no regulation on the kind of information that might end up in the dmesg buffer. The kernel environment from kenv is= n't so open-ended, and seems to be almost entirely boot/device options. We may want to hide those, and I doubt that showing them serves anyone any purpose, but I'm not particularly worried about the security implications. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-211580-29815-bKkRNndoQV>