[syslinux] problem with PXElinux and security of local LAN

[Murali Krishnan Ganapathy]

You can handle stale states as follows: Instead of writing just the 
state of the machine also write the time till which this state is valid. 
The COMBOOT code then checks the current time against the validity time 
and acts accordingly. You will need to modify the autoboot code (from 
gui.mahamurali.net) appropriately. So you will need to install some 
variant of SYSLINUX on your hard disk so that the COMBOOT code can be run.

The FAT16 problem can be handled easily by using EXTLINUX instead of 
SYSLINUX on your hard disk. Then you should be able to put the COMBOOT 
program in the EXT filesystem which ofcourse is not touched by Windows. 
Note that the MBR on your hard disk would need to point to EXTLINUX and 
EXTLINUX should then boot your Windows Partition. If Windows overwrites 
MBR you will need to re-overwrite the MBR with the one given with SYSLINUX.

So this will be a classic example of EXTLINUX and COMBOOT code working 
together to solve your problem.

----------

May be we should collect all the open source COMBOOT code people have 
and put them somewhere in the SYSLINUX homepage. Best would be make the 
code downloadable from SYSLINUX home page and also have a link to the 
author's version (so if the author disappears we still have some usable 
code). This would give potential users of COMBOOT code an idea of what 
can be done with COMBOOT stuff.

- Murali

Jason Keltz 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 use it..
>>>
>>> Thanks a bunch..
>>>
>>> Jas.
>>>
>>> _______________________________________________
>>> SYSLINUX mailing list
>>> Submissions to SYSLINUX at zytor.com
>>> Unsubscribe or set options at:
>>> http://www.zytor.com/mailman/listinfo/syslinux
>>> Please do not send private replies to mailing list traffic.
>>>
>>>
>>
>
>
>