On Thu, Nov 20, 2008 at 05:39:36PM +1100, Peter Jeremy wrote: > On 2008-Nov-19 02:47:31 -0800, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > >There's a known "issue" with the kernel message buffer though: it's not > >NULL'd out upon reboot. > > This is deliberate. If the system panics, stuff that was in the > message buffer (and might not be on disk) can be read when the system > reboots. If there is no crashdump, this might be the only record of > what happened.
That doesn't sound deliberate at all -- it sounds like a quirk that people (you?) are relying on. I do not think any piece of the FreeBSD system (e.g. savecore, etc.) relies on this behaviour. You're under the mentality that the information is *always* available after a panic/reboot -- it isn't. I have 4 different Supermicro motherboards (all from different years) which will "most of the time" lose the msgbuf after rebooting from single-user -- but sometimes the msgbuf is retained. And no, bad hardware is not responsible for the randomness of the problem. I think it's been discussed in the past how/why this can happen. It has to do with what each BIOS manufacturer chooses to do with some parts of memory during start-up. I'm sure the "Quick Boot" (e.g. no extensive memory test, which really doesn't test anything these days) option plays a role, and that option is enabled by default on all motherboards I've used in the past 10 years. > > Meaning, in some cases (depends on the BIOS or > >system), the kernel message buffer from single-user mode is retained > >even after a reboot! A user can then do "dmesg" and see all the nifty > >stuff you've done during single-user, which could include unencrypted > >passwords if mergemaster was tinkering with passwd/master.passwd, etc.. > > There shouldn't be unencrypted passwords, though there might be encrypted > passwords visible. Sorry, that's what I meant. The point is that a lot of things can go on in single-user mode which can/will disclose information or data in files which users do not have access to. Once the system is rebooted, a non-root user can do "dmesg -a" and see this buffer, getting access to data he/she normally does not have access to. Do you and I agree that this is in fact a security risk/problem? > >Rink Springer created a patch where the kernel message buffer will start > >with NULL to keep this from happening, but it needs to be made into a > >loader.conf tunable. > > I hope that never gets committed - it will make debugging kernel > problems much harder. There is already a kern.msgbuf_clear sysctl and > maybe people who are concerned about msgbuf leakage need to learn to > use it. And this sysctl is only usable *after* the kernel loads, which means you lose all of the messages shown from the time the kernel loads to the time the sysctl is set (e.g. hardware detected/configured). This is even less acceptable, IMHO. I would like to see Rink's patch committed, as long as the loader tunable defaults to *off* (e.g. current/historic behaviour). I'll also ask Rink to chime in here with his thoughts/opinions. -- | 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 | _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
