Re: Re: Bootdisk minikernel to load full kernel via /linuxrc

Re: Re: Bootdisk minikernel to load full kernel via /linuxrc

[ragnagock]

> > 
> > Hi,
> > 
> > How would a /linuxrc look like, if I want a small bootdisk to load
> > a kernel from hdd? It has to boot just like loaded by loadlin or lilo
> > so noone can boot the PC without the disk but I can fiddle around
> > just like "normal"...
> > 
> > I'd be happy, if someone could help me.
> 

Sorry, I forgot to mention that I want to have all partitions encrypted.
And since there will be some kernel changes later on I don't want to
create a boot disk every time. This means it can't be very big -> no CD-R.

> A) a small filesystem to mount the encrypted filesystems, and then start
> the main system.

How?
Take a std floppy disk and boot a normal system from it... I ran out of
space.

> B) A dual-boot system, booting windows, with a normal kernel simply set to

> boot from the partition linux is installed on.

But why would I encrypt the linux part/haven't lilo installed then? 

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

Re: Re: Bootdisk minikernel to load full kernel via /linuxrc

[ragnagock]

> On Mon, Nov 26, 2001 at 01:01:49PM +0100, ragnagock@gmx.de wrote:
> > 
> > Sorry, I forgot to mention that I want to have all partitions encrypted.
> 
> Would you please explain the utility in having the /boot
> partition encrypted?  It seems to me that if this one
> partition existed, and was plain-text, most, if not all,
> of your problems would go away.
> 

The goal is to have a machine where all hard disk content is encrypted so
an attacker has first to crack this to gain information. The problem is:
how to boot? I thought of a key disk with the decryption keys an a small
kernel to decrypt the parts needed to initiate an "normal" boot (i.e.
kernel, mount, the config files...). Then the decrypted kernel form hard
disk
is started and takes over the system. This way one kann recompile and patch
the kernel without having to watch the size available on the boot/key disk
and does not need to recreate it every time since it is thought to do a
capabilities implementation which would need a lot of recompiles to test...

To de-/encypt it is thought of using the existing method via loop/cryptoapi.

Btw: As there will be a kernel level capabilities implementation, an
attacker
should not be able to mess around with the kernel, so a plain-text boot
partition is out of question (the disk can be locked away).

As an explanation: I study on a polytechnical and my contribution
to this project will be my diploma.

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net