On Tue, 31 Oct 2006, Alexander Leidinger wrote:

> Quoting Robert Watson (Tue, 31 Oct 2006 09:43:45 +0000 (GMT)):
>> (2) Sweep of the remaining kernel files, cleaning up privilege checks,
>> replacing suser()/suser_cred() calls, etc, across the kernel.

> What about denying access to the dmesg in a jail? I noticed in the run of
> the periodic scripts in jails that I can see the segfaults of programs in
> other jails (stock -current, but I haven't seen such a privilege in your
> list of allowed privileges for a jail). A quick test revealed that I'm able
> to see the complete dmesg.
> From an user point of view I don't want to get confused by broken stuff in a
> jail of someone else (shared hosting) and I don't want to let other people
> know what programs I run (in case they are failing).

A couple of years ago, I added a sysctl that could be set to require privilege
in order to read the kernel message buffer. When that sysctl is set,
"unprivileged" (i.e., unable to read the buffer) includes root processes in
jail. I agree that reading the message buffer is probably something that
should be restricted even for root processes in jail, although in some senses
the current model is quite consistent with normal behavior (privileged vs.
unprivileged). I'd be quite happy to review a patch to limit that sysctl to
outside of jail, perhaps keyed to a specific sysctl that can be disabled to
allow dmesg in jail.

Robert N M Watson
Computer Laboratory
University of Cambridge
freebsd-arch@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"