Date: Fri, 22 Feb 2008 02:09:24 -0800 From: Jeremy Chadwick <koitsu@freebsd.org> To: freebsd-hackers@FreeBSD.ORG, gizmen@blurp.pl Subject: Re: cool feature of dmesg.boot file Message-ID: <20080222100924.GA26637@eos.sc1.parodius.com> In-Reply-To: <200802220952.m1M9qskE001105@lurza.secnetix.de> References: <20080222092506.GA25704@eos.sc1.parodius.com> <200802220952.m1M9qskE001105@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 22, 2008 at 10:52:54AM +0100, Oliver Fromme wrote: > Jeremy Chadwick wrote: > > Oliver Fromme wrote: > > > Upon a reboot, the kernel is usually loaded to the same > > > physical addresses in RAM where it was before, so the > > > dmesg buffer will be at the same location, too (unless > > > you built a new kernel, of course). So all the contents > > > from before reboot are still there -- *IF* the system > > > BIOS didn't clear the RAM. Then the old contents will > > > end up in /var/run/dmesg.boot, too. > > > > > > You could try looking at your BIOS setup. Some have an > > > option called "Quick POST" or similar. If you enable > > > it, the BIOS will skip the RAM test (which is rather > > > useless anyway) which clears the RAM. It might help, > > > but it depends very much on your mainboard and BIOS. > > > > There is also kern.msgbuf_clear. However, this is a sysctl, which > > means if set to 1 in /etc/sysctl.conf, you'd lose your dmesg output > > after the OS had started. Bummer. > > > > It would be useful if there was a loader.conf variable which was the > > equivalent of msgbuf_clear. In fact, I'm wondering why the message > > buffer isn't cleared on shutdown/immediately prior to reboot... > > So you can see panic messages and other useful things that > happened before the reboot. It's a _feature_, not a bug. I've never seen a single kernel panic push output into the kernel message buffer; do you mean things ike automatic stack trace dumping on panic? (We have this disabled, which may be why I've never seen it). Either way, it's a feature with major security implications. So, for those of us who are concerned about master.passwd changes via mergemaster being stuffed into msgbuf, how do we disable said feature? (Before answering, see below as well). > > Interesting tidbit: We have one production machine which when booted > > into single-user via serial console for a world install, retains all of > > the output from that single-user session even once rebooted and brought > > back into multi-user mode. This poses a substantial security risk, > > especially during the mergemaster phase (we can discuss why if anyone is > > curious). > > sysctl security.bsd.unprivileged_read_msgbuf=0 No can do -- we have many users who look at dmesg for a reason: logging of coredumped binaries (kern.logsigexit=1), and if there were any signs of disk or network issues during that time. I've tried using that in the past and got significant flack from our userbase. If you'd like, I can have them chime in on this thread as validation. Using security.bsd.unprivileged_read_msgbuf=0 to "solve" said concern is an ineffective workaround in our case. I'm willing to bet others feel the same way. Maybe I should look into writing a patch that does in fact clear the buffer immediately before reboot, and tie it to a sysctl. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080222100924.GA26637>