Subject: Re: NetBSD master CVS tree commits
To: None <thorpej@nas.nasa.gov>
From: Luke Mewburn <lukem@connect.com.au>
List: tech-security
Date: 02/23/1997 02:30:44
[migrating thread to tech-security@netbsd.org, because that's what it's for]

Jason Thorpe writes:
>  matthew green <mrg@eterna.com.au> wrote:
>  > i'm not sure i like this, from a `security' point of view.  if i have
>  > marked the console as insecure, then by hell i want netbsd to do it's
>  > best to keep the bad guys out!  and that includes *me* until i
>  > authenticate myself.  security systems should *always* fail closed
>  > (though, it's somewhat of a stretch to consider this to be failure :-).
>  > 
>  > IMO, `insecure console' and `no root password' situations are generally
>  > going to be caused by pilot error, and `reducing' the security of the
>  > system to work around this is a bad idea.
> 
> In a situation where there _was_ pilot error, I think there's an argument
> to be made for recoverability... 
> 
> Well, "you're the boss" with the security stuff... if you really strongly
> object to it, it can be backed out.

(I don't usually do "I agree" posts, but in this case, it may be relevant)

I concur with Matt (i.e, this feature may not be so great).

We *did* have cases where we didn't want a root password but had the
console insecure. Logins were via auth cards, and if you needed root,
you wanted to just do "su" without sending root's password over the
wire.

Nowadays you'd probably use an underlying session protection such
as ssh or stelnet (ssl telnet), with auth card logins for the ultra
paranoid, and potentially something like "sudo" or "priv". Even so,
there still is a case for preventing root w/o a password logging in.

If you're totally screwed, a boot floppy (+drive :) or other boot
media can fix you up. It's *rare* when this isn't available or
feasable (you normally should't do a level of hacking on a remote
serial console that could toast you bad unless you have a backout
mechanis; doesn't mean it doesn't happen though :)