New in-kernel privilege API: priv(9)

[Robert Watson]

On Tue, 31 Oct 2006, Alexander Leidinger wrote:

> Quoting Robert Watson <rwatson at FreeBSD.org> (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