[syslinux] problem with PXElinux and security of local LAN

[Murali Krishnan Ganapathy]

Your suggested easier solution might not be feasible. With enough work, 
it should be possible to boot Linux from mini-linux. But I dont think it 
is possible to transfer control to Windows from a mini-Linux. Too many 
linux specific stuff has already taken place. Am I right?

- 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.
>>>
>>>
>>
>
>
>