[syslinux] problem with PXElinux and security of local LAN - readonly double boot idea

[Richard L. James]

Hi,

Firstly rather than a harddisk why not boot from a
read-only USB key or even read-only CD-ROM drive? 
Some USB keys come with a hardware write protect
switch.  You could locate the USB key inside the PC
itself.  If being truely paranoid superglue works
wonders to ensure things stay write protected or in
place, e.g. when 100% happy with the boot just glue
the USB protect tab to lock or in the case of a
CD-drive glue over the eject button etc.


I believe the following might help solve part of this
problem:

I once worked on how to capture a PC's original
interrupt table without an operating system loaded,
e.g. where to save the data and how?-with no Operating
System API etc!  The solution I came up with was to
have a small boot program which did the following:

1) Copy the interrupt vector table to a safe unused
memory space
2) Set a flag / pointer in the BDA (BIOS Data Area) to
the area
3) Performed a INT 19h (bootstrap loader) to load an
O/S, e.g DOS

Thus the original interrupt vector table could be
recovered from DOS.  This worked for what I needed it
for.  To make it fully water tight my thinking was to
fake a BIOS header (55AA,ROMSIZE, ROM CRC values etc
thus CRCing the data), so that DOS/Windows etc
wouldn't overwrite my "ROM" - I never implemented this
bit.

My thinking with regards to your problem is that you
could use a similar technique with a local bootable
readonly device (e.g CD) but temporary store the
selected menu option in the PC's own RAM, e.g. in the
Intra-applications communications area of the BDA
(BIOS Data Area) -
http://www.bioscentral.com/misc/bda.htm

and then perform a second boot by way of an INTerrupt
19h.
http://www.delorie.com/djgpp/doc/rbinter/id/79/22.html

into an OS from which you then recover the option
selected.  Of course if we were being really sneaky we
could poke values into BIOS's keyboard buffer to auto
select which option we wanted ;-)

Note: I have to confess that I haven't used PXElinux
yet but I will and I have read most of the specs.  I
also have to confess that I'm really tired and not
very good at explaining ideas.... !

Still I'm sure someone on here will be on a similar
wavelength.

Regards 

Richard L. James

--- Jason Keltz <jas at cs.yorku.ca> wrote:

> Hi Murali,
> 
> I don't mind if I ALWAYS boot the machine a second
> time, but there is a
> minor chicken and egg problem that I would need to
> solve.  I can't trust
> the state that is stored on the machine if the
> machine has been off for
> a while.  I also need to be able to set the state
> globally globally set
> the saI would always need to probe for the state the
> first time, and
> then reboot into the required O/S.  I don't mind
> that the partitions,
> etc. are fixed since the operating systems stay on
> the machine anyway.
> 
> I still don't know how to load the comboot code, and
> if that code
> requires being installed in a FAT16 partition, how
> do I protect it from
> Windows?
> 
> I wonder if there is an even easier solution...
> somehow I have 3 O/S ..
> Windows,Linux, Mini-Linux as you say ... you always
> boot to Mini-Linux
> which probes the web daemon for the state of the
> machine... at this
> point, if I could just boot to linux/windows knowing
> that the next time
> the machine boots, it would still go back to
> mini-linux, this would be
> great!!
> 
> jas.
> 
> Murali Krishnan Ganapathy wrote:
> > Yet another approach. This does not use PXELINUX!
> Install the Windows 
> > and Linux images on two partitions of your hard
> disk (so with this 
> > solution changing the boot image will not be very
> easy). But it requires 
> > two boots everytime instead of one.
> > 
> > The boot cycle is as follows
> > 
> > (1) Machine boots locally into COMBOOT code
> > (2) Code checks local machine for boot
> instructions.
> > (3) If instructions not found it boots a small
> linux image
> > (4)     small linux goes online and finds out what
> the state of this 
> > machine should be (Windows only/Linux Only/Boot
> Menu)
> > (5)     Stores this information somewhere on the
> hard disk and reboots 
> > so that COMBOOT code can find this info during
> next boot
> > (6) If instructions found, it follows instructions
> and acts accordingly.
> > 
> > This requires the local machine to have a Windows
> installation and a 
> > Linux installation which the users can use, and
> another small linux + 
> > initrd.
> > As soon as you boot into the small linux, you go
> online (in one of the 
> > init scripts) somewhere you trust (local webserver
> perhaps) and download 
> > a small file which says what the next boot image
> should be 
> > (LINUX/WINDOWS/MENU). The script then writes this
> information on sector 
> > N of the local hard disk (which is not used for
> any other thing). The 
> > COMBOOT code checks sector 6 for this information
> and when found boots 
> > into the appropriate image directly.
> > 
> > Good Things:
> > (a) Uses things which already exist, i.e. linux
> code to write this info 
> > to sector N and COMBOOT code to read this info
> already exist. (see 
> > http://gui.mahamurali.net and click on
> Autobooting)
> > (b) No PXELINUX. No TFTP server, so bad guy cannot
> give you a kernel to 
> > boot from
> > (c) A change in your local webserver, will affect
> all clients the next 
> > time they boot. Infact if your logic of
> (Windows/Linux/Boot Menu) is 
> > simple, this logic can be put as a cgi script on
> your webserver. So you 
> > dont need to change anything in the webserver at
> all!!!
> > 
> > Bad Things:
> >  (a) You need to an extra reboot everytime you
> boot
> >  (b) If you need to change the boot image, you
> need to change it on 
> > every machine
> >       or setup another image you can boot into on
> the local machine 
> > (which requires a password) and use that image to
> help automate the 
> > change of boot image.
> > 
> > Good/Bad:
> >   (a) Machine retains state between reboots, (i.e.
> local files on machine)
> > 
> > - Murali
> > 
> > Jason Keltz wrote:
> > 
> >> I have two new thoughts on solving this problem,
> but I'm not sure 
> >> whether either is doable with PXELinux/syslinux..
> >>
> >> 1) I've been doing some web searching.  It seems
> like Intel has a BIS 
> >> (Boot Integrity Service) spec that is included in
> the PXE 2.0 spec.  
> >> The code, I believe, is open source - 
> >> http://sourceforge.net/projects/bis.
> >> I don't see anything in the PXELinux code about
> handling BIS.  If 
> >> PXELinux could handle BIS, it seems like this
> would completely solve 
> >> my problem.  I could authenticate the code that
> the PXE server 
> >> receives! (On the other hand, it's not clear if I
> could authenticate 
> >> the configuration file, but I guess that would
> only make sense).  If 
> >> PXELinux could handle BIS, it seems like it work
> in a lot of 
> >> situations (like mine) where people have
> recommended not using PXE.  
> >> Maybe Peter can comment on the feasibility of
> adding this 
> >> functionality to a future PXElinux?
> >>
> >> 2) It is "possible" that I could do what I want
> to do now with 
> >> syslinux in a different way.  The question is, is
> it possible for 
> >> syslinux to probe a DHCP server for a value and
> then to act based on 
> >> that value?  I don't see anything about DHCP in
> the syslinux page, and 
> >> the network code may not even be available to
> syslinux.  This is a bit 
> >> like the idea that Murali had.  Our machines are
> supposed to boot 
> >> either directly into linux, directly into
> Windows, or present a boot 
> >> menu.  Before, I was handling the configuration
> file change on the 
> >> server and using PXELinux.  By changing the
> symlink to the 
> >> configuration file, I could change the options
> available to the 
> >> users.  Basically, my idea is this -- syslinux
> probes the DHCP server 
> >> for an option that determines how it proceeds. It
> might be something 
> >> like:
> >> value of 1 indicates boot directly to linux
> >> value of 2 indicates boot directly to windows
> >> value of 3 indicates to present a boot menu.
> >> syslinux would then either boot directly to
> linux/windows/present a 
> >> menu.  There are a couple of problems with this:
> >>   1) (again) I'm not sure I can probe a DHCP
> server in syslinux,
> >>   2) I'm not sure a syslinux configuration file
> could act based on the 
> >> condition received in 1.
> >>   3) In order to install syslinux on the hard
> disk, it needs to be 
> >> installed into a FAT16 partition.  However, by
> doing this, as far as I 
> >> understand it, there would be no security on the
> FAT16 partition when 
> >> users boot Windows XP, and hence users could mess
> with or disable the 
> >> syslinux configuration.
> >>
> >> If someone might be able to help me with 2, that
> would be great.
> >> If option 1 is magically available and hiding
> from my sight, it would 
> >> be great if someone could help me figure out how
> to 
=== message truncated ===