dual boot test

[Chris Murphy]

On Dec 27, 2013, at 4:40 PM, bruce <badouglas at gmail.com> wrote:

> Hi Chris.
> 
> Thanks fo.r the reply
> .
> The principle reason for doing/testing dual boot is to have the
> ability to be able to do a remote reinstall for a fresh OS on a remote
> box. If you know of a way to accomplish that, I'm more than willing to
> hear it!!

USB key imaged with netinstl ISO is has a way to confirm it hasn't been altered, and a VNC and kickstart capability for unattended installation over a network.


> Everything I've seen regarding doing reinstalling of OS, requires
> having access to the box, with fresh media.

Well it is easier to do it that way, completely remote setups have more fail points. You ultimately need the ability to get physical access to it anyway - hard drive dies, etc.

> 
> This is really intended to allow me to detect if the "base/master"
> system has been hacked, and then to immeadiately switch to the minimal
> OS/system, which would then invoke a netinstall for the hacked
> system/OS to have a clean system.

I'm not a security expert or a lawyer, but this use case seems specious. Firstly, in any business use case it seems to me the machine needs to be preserved for forensic analysis. You shouldn't just obliterate it and reinstall, that's destruction of evidence, it very well could be illegal.

In any case, if the primary system is hacked, the minimal system is also likely compromised. If it has write once media in it, like a CD/DVD,  you can create known reliable media that can boot a live environment from which you can ATA Secure Erase the drives, and reinstall a system. But this isn't dual boot in the sense that there are two OS's on one physical drive.

> So, the test is to have a dual Centos process, which is what I'm
> looking to implement right now.

Maybe someone with more security and VM experience can speak up. But it seems to me that the setup and management of all of this is a lot easier if you have a rather locked down baremetal setup, and then you have one or more virtual machines that are more "exposed". And if they get hacked, it's a ton more straightforward to preserve its virtual disk, point the VM to a backup image, replace keys and passwords, and get it up and running in minutes vs hours for a truly clean install of a baremetal setup.


> Here are the current steps I've used, feel free to tell me where I've
> gone off track.

I already gave you the proper grub.conf 2nd entry. That's what you got wrong and why it won't boot. It's pointing to the wrong root which is what I said from the beginning.



Chris Murphy