Re: encrpyt harddrive without passphrase/userinput
On Sun, 2006-02-26 at 14:13 -0800, Stephan Wehner wrote:
> Who is going to be booting this machine??
It´s a server. It is supposed to be online all the time.
Once turned on it will run till someone reboots its remotely or due to
power failure or something alike.
The whole scenario can be pictured like this:
Put your server in a corner of a street and secure it. In case someone
hits the reset button it needs to be able to boot automatically without
user input.
In a nutshell: Secure it without physical security and user input.
I guess it can`t be done?! :(
Not the usual way...
> Stephan
> Mario Ohnewald wrote:
> > Hi Horst
> >
> > On Sun, 2006-02-26 at 22:23 +0100, Horst Pflugstaedt wrote:
> >
> >> On Sun, Feb 26, 2006 at 10:11:44PM +0100, Mario Ohnewald wrote:
> >>
> >>> Hello security list!
> >>>
> >>> I would like to secure the harddrive/partitions of linux box.
> >>>
> >>> The whole setup must fulfill the following requirements:
> >>>
> >>> a) it must be able to boot (remotely) without userinput/passphrase
> >>> b) the importtant partitions such as /etc, /var, /usr and /home must be
> >>> encrypted/protected.
> >>>
> >> I just ask myself why you bother encrypting a filesystem that will be
> >> accessible to anyone having access to the machine since it boots without
> >> password?
> >>
> > It boots with grub and pam/unix password.
> >
> >
> >>> Is this even possible? Is there a way?
> >>>
> >> Is it something you'd really want? Encrypting a filesystem is a
> >> protection against someone having physical access to the machine or the
> >> harddrive. If the machine (the disk in another machine) boots without
> >> password, you might as well _not_ encrypt it.
> >>
> > Thats the point.
> > In my case i can not protect the linux box or lock it away 100%
> > securely.
> >
> > I need to secure the box in some way without having a physical
> > protection.
> >
> > Someone should be able to: Steal the whole server or hard drives, but
> > still not be able to read it.
> >
> > Maybe we could narrow the actual problem down to where this scenario
> > actually fails or where the problems are?!
> >
> > Maybe someone has some cool ideas, too.
> >
> > Cheers, Mario
> >
> >
> >
>
>
Reply to: