Subject: Re: Another changer, another changer problem
To: Greg A. Woods <email@example.com>
From: Curt Sampson <firstname.lastname@example.org>
Date: 10/08/1998 12:23:55
On Wed, 7 Oct 1998, Greg A. Woods wrote:
> > > This is, of course, all blue-sky dreaming at the moment (though I will
> > > note that there are existing systems where a reboot will redirect the
> > > console to the user's current tty).
> > Which of course would blow our whole securelevel scheme.
> If you're thinking of the nonsense with "secure" on the console entry in
> /dev/ttys, then you're jumping to conclusions too fast again....
No. You'll note I didn't mention `secure' or `/dev/ttys'; I mentioned
Now, if you're finished jumping to conclusions, I'll explain what
you missed here.
In multiuser mode, if I have a machine running at securelevel 2,
files with the immutable flag cannot be modified. The system won't
allow modification directly (even by root), nor will it allow any
writes to the disk devices (even by root) to do it without going
through the filesystem. Therefore someone who breaks into my machine
cannot modify binaries and configuration files that I deem essential.
They also cannot cover their tracks when logged in logfiles that
I flag append-only.
The only way the hacker can get around this is to modify these
files in single-user mode. As it stands, if he brings the machine
down to single user mode he loses his connection. He must have
physical access to the server to get around this. With your method,
making your server physically secure doesn't make any difference,
because he's now got single-user access (giving him much more power
than root when running multiuser), and can now change files, replace
binaries, etc. at will.
Curt Sampson <email@example.com> 604-257-9400 De gustibus, aut bene aut nihil.
Any opinions expressed are mine and mine alone.
The most widely ported operating system in the world: http://www.netbsd.org