Syslinux - Apr 2004 - SYSLINUX 2.09, 2.10-pre1 released

Hi all,

I have released SYSLINUX 2.09; it is the same as 2.09-pre15 except for 
the version number.

Changes in 2.09:
         * SYSLINUX: Remove residual setuid crap from
           syslinux-nomtools.
         * Handle video pages correctly when using the API functions.
         * Handle compiling on an x86-64 platform correctly.
         * Menu system from Murali Krishnan Ganapathy; see the menu
           directory for information.
         * COMBOOT: Allow COMBOOT programs to change screen text mode.
         * COMBOOT: Correct the documentation of how to detect
           SYSLINUX from COMBOOT!!!!
         * COMBOOT: Fix "get key without echo" API function.
         * SYSLINUX: Fix bug that affected the API open function.
         * ALL: Improve the E820 memory parser, to work around some
           buggy BIOSes.


I have *also* released 2.10-pre1, which adds Patrick LoPresti's support 
for zipped (as opposed to gzipped) images in MEMDISK; some Windows-based 
tools apparently can handle zipped images but not gzipped, and this 
makes it easier to just drop them in.

ftp://ftp.kernel.org/pub/linux/utils/boot/syslinux/

	-hpa

Hi,

I'd really appreciate if there were a PXELINUX option that would prevent
users from adding kernel commandline boot parameters apart from the
options nailed down in the configuration file. This is a very basic security 
issue in an unattended, potentially hostile environment if you don't want 
user to become root (init=/bin/sh), a situation not that uncommon.

I hope that such a configuration flag is not that complicated to implement,
since it is not a really new feature, but just disables an already functional
feature.

Thanks, Thomas

Hi,

"H. Peter Anvin" <hpa at zytor.com> schrieb am 29.04.04
20:12:16:
> Gebhardt Thomas wrote:
> > I'd really appreciate if there were a PXELINUX option that would
prevent
> > users from adding kernel commandline boot parameters apart from the
> > options nailed down in the configuration file. This is a very basic
security
> > issue in an unattended, potentially hostile environment if you
don't want
> > user to become root (init=/bin/sh), a situation not that uncommon.
> > 
> > I hope that such a configuration flag is not that complicated to
implement,
> > since it is not a really new feature, but just disables an already
functional
> > feature.
> > 
> 
> It's a new feature, and it is unfortunately reasonably complex to 
> implement.  What makes me really question the value is that it's not 
> clear to me that there aren't other security holes in the whole
scenario.
I've also asked for this a while ago, so this discussion isn't new.

For pxelinux it would at least allow to lock the ordinary User out of kernel
commandline
parameters. There are much hints how to get a root shell by adding
'init=/bin/sh', so
actually the user gets root access without much effort. If pxelinux locks the
command
line it would be somewhat harder: Either the user prevents pxelinux to read the
config file
at all (perhaps by pulling out the network cable at the right moment?) or needs
to do some
bios hacking. At least there wouldn't be the 'obvious' way.

For iso/syslinux maybe this could also lock the user to a fixed configuration.
This couldn't be
fixed easy, since writing the config file could be a really hard time. But it
could have its use
too.

For implementation: Isn't there some point in the code where the commandline
for the kernel is concatenated? So the options from the config file are taken,
then the options following the label on the command line are added? Why not just
skip adding the options following the label?
I've tried to find the right place for this in the code, but seems I've
not enough assembler skills
for this ...

Regards,

Josef

____________________________________________________________________
Der WEB.DE Virenschutz schuetzt Ihr Postfach vor dem Wurm Sober.A-F!
Kostenfrei fuer FreeMail Nutzer. http://f.web.de/?mc=021158

Hi,

thank you very much for all your answers!

Murali Krishnan Ganapathy <gmurali at cs.uchicago.edu>
wrote:
> * Create a menu, with options corresponding to the different isolinux
> labels
> * Set pcelinux.cfg to run the menu directly without any wait.
If I can feel sure that there is no escape from this menu then
this is my way to go!

"H. Peter Anvin" <hpa at zytor.com>
wrote:
> It's a new feature, and it is unfortunately reasonably complex to 
> implement.  What makes me really question the value is that it's not 
> clear to me that there aren't other security holes in the whole
scenario.
well, you sure have a better insight into that matter than I.

"Josef Siemes" <jsiemes at web.de>
wrote:
> For implementation: Isn't there some point in the code where the
commandline
> for the kernel is concatenated? So the options from the config file are
> taken, then the options following the label on the command line are added?
> Why not just skip adding the options following the label?  
> I've tried to find the right place for this in the code, but seems
I've not
> enough assembler skills for this .
Marc Haisenko <haisenko at be-ok.com>   wrote:
> Wouldn't it be easy to implement a configuration option that would skip
> construct_commandline and jump to commandline_end ? That would do just what
> all these people ask for (that request isn't showing up for the first
time).
> 
> Or did you think of another (better, cleaner ?) way to implement such
> a "skip   commandline options" feature ?
Yes, I thought of something like that, but since my assembler skills
are also very limited, I can't get the overall view to be sure that this
is sufficient.

Thanks, Thomas

Gebhardt Thomas wrote:
--- snip ---
 
> but still have two problems
> 1. I can escape the menu system and get the syslinux boot prompt with
either
> "ESC" or  "arrow left" in the main menu. Did I do
something wrong?
> 2. Can I easily configure the menu system to do something (boot from the
> local disk) after a specified timeout, i.e., can I configure a
noninteractive
> default boot?
You did not do anything wrong. The default setup of the menu is to quit 
the menu when the user hits "Esc" or "arrow left".  However
with a
little bit of C programming, you can solve both your problems...

* Default setup (Overview of how mymenu.c works)
initialise menu...
runmenu...
if user chose something 
   do it 
endif


* What your new mymenu.c should do

print "Press any key within 5 seconds.. to active menu..."
clear keyboard buffer
wait for 5 seconds
if keyboard buffer  is not empty
   run "localboot" / "chain.c32 hd0 0"
else
   initialise menu...
   loop:
       runmenu....
       if valid choice
           execute it
       endif
       goto loop
endif

Clearing and checking the kbd buffer can be done through BIOS interrupts.

To sleep for 5 seconds: here is one solution: Note the current time, and 
run an while loop, and exit that loop only when 5 seconds have passed. 
This is considered really bad programming for any multi-tasking OS. But 
hey, our code is the only one which is running now, so we can afford to 
do it.

- Murali
>On Thursday 29 April 2004 17:20, you wrote:
>
>Hi,
>
>  
>
>>Till such a feature comes along, you can implement the same
>>functionality as follows:
>>
>>* Create a menu, with options corresponding to the different isolinux
>>labels
>>* Set pcelinux.cfg to run the menu directly without any wait.
>>
>>This way you get a slightly user friendly interface and the users dont
>>have access to the pxelinux boot prompt.
>>    
>>
>
>I tried to do that 
>
>(pxelinux.cfg:
>
>DEFAULT mymenu.com
>PROMPT 0
>ONTIMEOUT ...
>ONERROR ...
>...
>)
>
>
>but still have two problems
>
>1. I can escape the menu system and get the syslinux boot prompt with either
>"ESC" or  "arrow left" in the main menu. Did I do
something wrong?
>
>2. Can I easily configure the menu system to do something (boot from the
>local disk) after a specified timeout, i.e., can I configure a
noninteractive
>default boot?
>
>My intention is as follows:
>I have a bunch of windows hosts, and want to supply the possibility to
>boot a diskless Linux by PXE.
>constraints:
>1. If the user who boots the machine does nothing at all, it should boot
>windows, just as before.
>2. A linux user should not be able to get root privileges by supplying
>additional kernel boot arguments.
>
>Thanks, Thomas
>
>  
>

Hi,

On Wednesday 05 May 2004 19:41, you wrote:
> * What your new mymenu.c should do
>
> print "Press any key within 5 seconds.. to active menu..."
> clear keyboard buffer
> wait for 5 seconds
> if keyboard buffer  is not empty
>    run "localboot" / "chain.c32 hd0 0"
> else
>    initialise menu...
>    loop:
>        runmenu....
>        if valid choice
>            execute it
>        endif
>        goto loop
> endif
>
> Clearing and checking the kbd buffer can be done through BIOS interrupts.
> ...
thank you very much! Since I have not written assembler code since the days of 
Z80, it took me some time to get the work done (and I still have implemented 
the timeout by a simple delay loop and not by a BIOS call). But now I have a 
nice interface and cannot escape from the menu.

Cheers, Thomas

Glad it helped.

- Murali

Gebhardt Thomas wrote:
>Hi,
>
>On Wednesday 05 May 2004 19:41, you wrote:
>
>  
>
>>* What your new mymenu.c should do
>>
>>print "Press any key within 5 seconds.. to active menu..."
>>clear keyboard buffer
>>wait for 5 seconds
>>if keyboard buffer  is not empty
>>   run "localboot" / "chain.c32 hd0 0"
>>else
>>   initialise menu...
>>   loop:
>>       runmenu....
>>       if valid choice
>>           execute it
>>       endif
>>       goto loop
>>endif
>>
>>Clearing and checking the kbd buffer can be done through BIOS
interrupts.
>>...
>>    
>>
>
>thank you very much! Since I have not written assembler code since the days
of
>Z80, it took me some time to get the work done (and I still have implemented
>the timeout by a simple delay loop and not by a BIOS call). But now I have a
>nice interface and cannot escape from the menu.
>
>Cheers, Thomas
>
>
>
>  
>