Julien Gormotte gormi456 at
Fri Feb 12 14:54:14 UTC 2010

Le 12/02/2010 15:19, Adam Vande More a écrit :
> On Fri, Feb 12, 2010 at 8:05 AM, John <john at 
> <mailto:john at>> wrote:
>     People, people - be careful that we are not creating a formula to
>     break into FreeBSD servers around the world...
>     The only acceptable solution is for someone in Eric's organization
>     to secure physical access to the server.  It may be in a co-lo
>     situation, but if that's true, they must have a contract open and,
>     if nothing else, they terminate the contract and get the machine
>     back, though more likely, the contract allows them supervised
>     access.  Machines are not perfect - even without losing the root
>     password, they break and need maintenance - this is a MAINTENANCE
>     event and should be treated as such, just like a hard drive failure
>     or a NIC failure.
>     Creating a scheme for someone to break into FreeBSD systems remotely
>     or to publicize schemes people have created to remotely manage their
>     systems in ways that could be used to compromise them is foolishness!
>     Regardless of the purity of his intention, Eric is asking us to
>     tell him how to break into our homes or steal our cars. ;)
> Security through obscurity is no security, hence it is a good exercise.
> -- 
> Adam Vande More
I have to agree. Plus, these ways of setting root password are not 
"breaking into" the server. If you have a KVM over IP, it is like 
physical access. And rescue disks are used for these kinds of situation 
(among others, like kernel config errors and such).
These methods are just what they are : recovery methods. In a dedicated 
server situation, you are supposed to be the only one to have access to 
the rescue systems.

If we were discussing about gainig root privileges from a normal user 
account, or remotely (using security holes in php scripts, or in CGI, 
or... any other thing...), your complaint would somehow make sense (but 
in fact, it wouldn't, because these security holes don't have to be 
hidden, they have to be corrected).

More information about the freebsd-questions mailing list