[Testers wanted] /dev/console cleanups

[Jeremy Chadwick]

On Thu, Nov 20, 2008 at 05:39:36PM +1100, Peter Jeremy wrote:
> On 2008-Nov-19 02:47:31 -0800, Jeremy Chadwick <koitsu at freebsd.org> 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 |