Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Build an unbreakable syslinux #107

kaihendry opened this Issue Nov 8, 2012 · 10 comments


None yet
3 participants

kaihendry commented Nov 8, 2012

You can break the install boot holding Alt, as you can see here: http://webconverger.org/debug/

In rare scenarios where members of the public cold boots the machine, they could break syslinux and enter debug mode to do what they wanted.

As mentioned several times before, Webconverger users should never see Webconverger boot.

Nonetheless the problem should be addressed probably as an option for http://custom.webconverger.com/. A big downside is that it makes the default Install version very difficult to debug without the configuration system, hence I'm reluctant to put this "extra lockdown" feature into the default downloadable version.


matthijskooijman commented Nov 8, 2012

Perhaps it makes sense to add a "lockdown" (or boot_lockdown perhaps) configuration parameter? Since the install version regenerates the bootloader config on every upgrade (and potentically some config changes as well, but this still needs to be coded IIRC), we could change the syslinux configuration to disable the prompt alltogether when this lockdown parameter is present.


matthijskooijman commented Nov 8, 2012

w00ps, wrong button


kaihendry commented Nov 8, 2012

Thanks for the reminder. I'll need to investigate how to pass an option like this to syslinux http://www.syslinux.org/wiki/index.php/EXTLINUX

Hopefully this is possible (!)

geneC commented Nov 14, 2012

"NOESCAPE 1" as documented in doc/syslinux.txt


kaihendry commented Nov 18, 2012

@matthijskooijman just to be clear, I need to add "NOESCAPE 1" somewhere near https://github.com/Webconverger/webc/blob/master/etc/webc/functions.sh#L186 if cmdline_has lockdown

Or is there a better API name? :)

geneC commented Nov 18, 2012

Somewhere thereabouts, yes, unless you have logic elsewhere that modifies files that'd be more appropriate.

  1. Why bother with splitting the config? Now, there's two files that must be secured against modification and they're both tiny/ Does it help with modifying the boot params?

  2. Setting DEFAULT, PROMPT or NOESCAPE in linux.cfg will override the original.

  3. I'd tend to keep the LABEL specified in DEFAULT in the base config file then override in the included files. This provides a fallback scenario in case the included file is not found.


kaihendry commented Nov 19, 2012

Thanks for taking the time to make suggestions @geneC I subscribe to the just the one file suggestion. I think we have it like this to map to what Debian Live does. Be good to get @matthijskooijman's input.

Still a bit confused by live.cfg.in on the binary and how that works.


matthijskooijman commented Nov 19, 2012

I just kept the split in there because it was already there, but I agree that it is a bit silly and pointless. I wouldn't mind having just a single linux.cfg that contains all the relevant stuff.

As for live.cfg.in, it's not used for an installed instance (but on a read-write non-installed / live instance). This code is only used in an installed instance.

@kaihendry kaihendry closed this in 9b47bee Nov 28, 2012


kaihendry commented Nov 28, 2012

Be good if you could review my change @geneC before I merge to master. :)


Seems to work with my testing.

@kaihendry kaihendry reopened this Nov 28, 2012


kaihendry commented Nov 30, 2012

Merged to master. Mental note: use Pull requests more.

@kaihendry kaihendry closed this Nov 30, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment