[syslinux] problem with PXElinux and security of local LAN
jas at cs.yorku.ca
Tue Dec 20 08:42:50 PST 2005
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
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
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 +
> 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.
> (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 -
>> 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
>> 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 use it..
>> Thanks a bunch..
>> SYSLINUX mailing list
>> Submissions to SYSLINUX at zytor.com
>> Unsubscribe or set options at:
>> Please do not send private replies to mailing list traffic.
More information about the Syslinux