Bug 25337
| Summary: | dmesg -a should be restricted | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | mitsuru <mitsuru> | ||||
| Component: | bin | Assignee: | Robert Watson <rwatson> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | ||||||
| Priority: | Normal | ||||||
| Version: | 4.2-STABLE | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
State Changed From-To: open->feedback Fixed in 5.0-CURRENT, sbin/dmesg/dmesg.c,v 1.13. Responsible Changed From-To: freebsd-bugs->ru MFC reminder. > switch(ch) {
> case 'a':
> if (getuid() != (uid_t)0) {
> fprintf(stderr,"dmesg: must be root to get all data in the message buffer\n");
> exit(1);
> }
This fix is not sufficient, I'm afraid; first, the whole message buffer
is exported as sysctl (on i386); second, dmesg classifies the lines by
the first characters (lines starting with <number> and number != 0 are
only printed when -a is given). Because the kernel message buffer is
a ring buffer, the first characters of a line may be overwritten, causing
the rest of the line to be printed by a simple dmesg (without -a).
- thomas
State Changed
From-To: feedback->open
The suggested fix does not work:
On Sat, Feb 24, 2001 at 01:49:57PM -0500, Robert Watson wrote:
>
> Please back out this change. The syslog hack was fairly bogus *before*
> this change, but now it's gone from being bogus to being a vulnerability.
> This is because the heuristic used to differentiate syslog messages and
> console messages is not always correct, as (a) this prevents dmesg from
> showing strings the kernel prints that are in the format of syslog
> messages, and (b) wrap-around in the dmesg buffer in kernel can result in
> messages being displayed when the syslog string prefix is squished. So
> you've turned what was an innocent hack into a security problem, since
> you now make a security guarantee about the availability of the messages.
>
> We're also about to commit changes to dmesg to make it no longer require
> privilege when used on a live system by virtue of the existing sysctl (on
> i386) currently exporting the message buffer, so this piece of "security"
> doesn't even prevent users from getting to the data, as they can currently
> extract it directly using sysctl and don't have to use the dmesg command.
>
> We're currently considering adding two new sysctl's that could be used to
> restrict creation and access to msgbuf data. First, a sysctl that toggles
> whether or not console output is sent to the message buffer. Second, a
> sysctl that toggles whether or not dmesg output is available in jail().
Responsible Changed From-To: ru->rwatson Robert objected this change and proposed the right fix. State Changed From-To: open->suspended Doing this requires us to seperate the different msgbuf contents, requiring a larger rewriting of the console and message buffer code. Doing so would fix a number of bugs, including the "overflow" bug involving the msgbuf ringbuffer problem. However, that's a lot of work. In the mean time, it's possible to restrict access to the entire message buffer by setting the security.bsd.unprivileged_read_msgbuf sysctl to 1 on 5.0-CURRENT. This will prevent unprivileged users from using the msgbuf-retrieval sysctl, although they will still be able to read the boot-time cached data in /var/run/dmesg.boot. I'm putting this PR into suspend mode to remind me every now and then I should rewrite all this stuff. State Changed From-To: suspended->closed Close this PR; a security toggle was provided to help limit the problem, but the fundamental issue of combining kernel message buffers for kernel printfs vs console output will be harder to address. Since my work queue has grown too deep, I'll close this PR as addressed, but I will open a feature request PR to have the two buffers separated. |
Using dmesg -a, any user can get all data in the message buffer, and it may cause security problem. Especially all messages written to the console are stored in the message buffer during single user mode, and any user can get them later. The use of -a option should be restricted to root user. How-To-Repeat: dmesg -a