How to run ISO Live Mode from RAM?

Hi!

I like the promise of your OS, but I prefer to run things out of RAM and I couldn’t do it out of the box. In some standard live ISO a “toram” parameter should be specified in the vmlinuz config section in GRUB, but here I saw a great lot of parameters, very unusual and curious, but “toram” didn’t work for me, unfortunately. I like to remove my flash drive after booting the system - but here it immediately terminated session - cool, but I would trade running purely from ram to this very cool feature (it really is cool, I just have a slightly different taste/preference). Any assistance would be great, thanks!

Alexander

Addition: Without a browser the OS’ functionality is greatly reduced. An option to have any working graphical browser is really needed for proper from-ram work. Downloading a browser every time is quite a complication, especially, if they are uninstallable. Looks like ISO Live Mode is not really suitable for regular use.

It’s untested, but try using rd.live.ram=1. This is the equivalent of toram in Dracut, the initramfs generator used by Kicksecure.

If the instant shutdown issue continues to occur, you may need to boot into an “UNRESTRICTED Session” on the ISO, and then run sudo systemctl stop emerg-shutdown.service after booting.

See the rationale behind requiring explicit installation of a browser here:

And here:

Unfortunately, at the moment in order to install a browser while in the live ISO session, you will need to boot into an “UNRESTRICTED Session”. There is a fix for this in the development repos, which will allow browser-choice to install browsers in ISO Live mode even in a standard user session, but that hasn’t been fully released yet.

2 Likes

Thanks for your reply. rd.live.ram=1 did load the system to RAM (can be deduced by the increased load time), but removing the flash drive still leads to a reboot.

I’ve booted into the “UNRESTRICTED Session”, but there is a disclaimer that it is “semi-persistent”, so disabling emerg-shutdown.service would not affect ISO Live Mode. Is there a way to boot not into “semi-persistent” but into persistent unrestricted environment? Then I could fix the shutdown service and the browser issue and have a working ISO - but looks like this path is not possible. So the only way left is reconfiguring the ISO image apparently.

On a side note, have you heard of Dillo browser? It weights almost nothing and has a very small code base, so maybe it could be security audited and included? The main problem is that it does not support javascript and without javascript even this forum won’t work (you won’t be able to log in). Bot infestation further complicates things, requiring anti-bot challenges which usually use javascript…

Disabling would not affect ISO Live Mode, true, but stopping will. systemctl disable ... tells systemd to not start a service automatically (kinda; there are exceptions), while systemctl stop ... tells systemd to terminate a running service. Thus, if you boot into an “UNRESTRICTED Session”, then run sudo systemctl stop emerg-shutdown.service, it will stop the emerg-shutdown background process. That process is responsible for the instant shutdown when the USB drive is removed (see emerg-shutdown - Instantly Power Off the System), so stopping it should prevent the shutdown.

Yes and no. ISO files themselves are difficult to modify and can’t simply be mounted read-write. Beyond that, the majority of the OS itself is stored in a container file using a fundamentally read-only format known as SquashFS. Security-wise, it’s best to read the ISO as potentially read-write, but from a user standpoint the ISO is fully read-only.

That being said, you can boot Kicksecure from an ISO flashed to one USB drive, and then install Kicksecure to another USB drive, giving you a persistent, portable installation. This is a supported use case of Kicksecure, see:

I have heard of it and used it briefly. I wouldn’t call its codebase “very small”:

┌─╴aaron@kf-m2g5:~/Github/dillo
└─╴$ find -type f | wc -l
549
┌─╴aaron@kf-m2g5:~/Github/dillo
└─╴$ sloccount .

...

SLOC    Directory       SLOC-by-Language (Sorted)
31279   src_top_dir     ansic=17114,cpp=14127,sh=38
23277   dw              cpp=23277
4760    dpi             ansic=3939,cpp=821
4451    src_IO          ansic=4438,cpp=13
3734    test            cpp=2579,ansic=953,sh=197,awk=5
2630    lout            cpp=2630
1375    dpid            ansic=1375
784     dlib            ansic=784
387     dpip            ansic=387
214     top_dir         perl=131,sh=66,ansic=17
0       devdoc          (none)
0       doc             (none)
0       icons           (none)


Totals grouped by language (dominant language first):
cpp:          43447 (59.61%)
ansic:        29007 (39.80%)
sh:             301 (0.41%)
perl:           131 (0.18%)
awk:              5 (0.01%)




Total Physical Source Lines of Code (SLOC)                = 72,891
Development Effort Estimate, Person-Years (Person-Months) = 18.06 (216.78)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 1.61 (19.30)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 11.23
Total Estimated Cost to Develop                           = $ 2,440,334
 (average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL.
SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
redistribute it under certain conditions as specified by the GNU GPL license;
see the documentation for details.
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."

That’s about 67% of the size of the combined codebases of Kicksecure and Whonix. I don’t think it would be practical for us to review it.

There have historically been two CVEs in Dillo that would have potentially permitted arbitrary code execution:

https://www.cve.org/CVERecord?id=CVE-2005-0012

https://www.cve.org/CVERecord?id=CVE-2009-2294

Dillo also appears to lack a browser sandbox similar to those used by Chromium and Firefox. Therefore I don’t really see Dillo as a good choice for a secure default browser.

2 Likes

Please refer to:

1 issue = 1 forum thread please.

Planned to be available in 18.1.3.4 and above. “Soon.” (Days probably - but please don’t quote me on that.)

Thanks for your reply.

Disabling would not affect ISO Live Mode, true, but stopping will.

I’ve meant disabling it to then reload the OS and run it in RAM in non-persistent restricted mode with emerg-shutdown.service disabled. It looks like the only way to have it disabled for the non-persistent mode is to remake the ISO image.

Security-wise, it’s best to read the ISO as potentially read-write

This kind of confirms my wariness of keeping the booting flash plugged in during work. This is like with a phone or laptop camera - you can be 100% sure that it is off only if it is unplugged from its power source.

Thanks a lot for the brief Dillo review, looks like I was deceived by its small size. I will create a different thread for off-topic next time.

True, if you want to permanently disable it, you’d need to rebuild the ISO for that. My thought was that you’d boot using rd.live.ram, then stop emerg-shutdown.service, then unplug the drive.

1 Like

Thanks for replying. Since it is impossible to run sudo systemctl stop emerg-shutdown.service in the restrictive mode, this is not a good option and running kicksecure in the unrestricted mode is subpar.

Would it be a good idea in the next version to configure emerg-shutdown.service to skip starting if kernel parameter rd.live.ram is set?

Trivial to implement but haven’t throught through yet if it’s a good idea.

1 Like

Most likely yes, since the primary use case for rd.live.ram is to be able to remove the boot USB drive and continue using the system.

Speaking of which, maybe we should add a boot option to the ISO boot menu, along the lines of LIVE RAM Mode | USER Session? If rd.live.ram works reliably, it would be easy to add.

2 Likes

I tried rd.live.ram=1 in Live Mode entry and disabled emerg shutdown first before hand and my system froze upon removing disk, in my case my disk was and external ssd. Is there any conflicting flags or maybe not enough RAM?

2 Likes

Well, it is completely untested. Maybe the needed Dracut module for loading into RAM wasn’t embedded, and so the system crashed when you unplugged the drive.

I might be able to investigate this more at some point.

1 Like

Yeah my mouse moved around but I couldn’t launch any apps and then it locked up completely.

1 Like

I tried to tinker with the udev rule, hoping I could sidestep the emergency‑shutdown routine by grepping /proc/cmdline for the presence of the “rd.live.ram=” flag. Instead, I accidentally turned off shutdown entirely.

Clearly I’m missing something? There has to be a way to make this configurable. This way a toram equivalent if passed by the user would disable the udev rule for emerg shutdown, but still allow manual key press since pull out wouldn’t work.

Hey @arraybolt3, on one of the machines I was messing with (running Kicksecure), I didn’t have an END key. Following the wiki, I dropped a file into /etc/security-misc/emerg-shutdown and swapped END for Backspace:

EMERG_SHUTDOWN_KEYS="KEY_LEFTCTRL|KEY_RIGHTCTRL,KEY_LEFTALT|KEY_RIGHTALT,KEY_BACKSPACE"

Unfortunately, that didn’t do the trick. FYI, this was a corebooted Chromebook. Chromebooks don’t ship with an END key in the first place.

Mine also too crashed after connecting to wifi and waiting for notifications to go away. I suspect low RAM issue, as in my case I only have 4GB of RAM. Wonder if its any conflicts with systemd’s tmp.mount?

emerg-shutdown isn’t triggered by a udev rule, it’s triggered by a udev event coming directly from the kernel (specifically, it listens for a “drive was removed” event). If the kernel didn’t generate that event, the entire rest of the system would likely not notice that the drive was no longer there unless it polled for it and realized “whoa, the drive vanished”. Configurability should be done on the systemd unit layer; if the system is booted in a mode where emerg-shutdown doesn’t make sense, it shouldn’t be started.

Hmm, that should have worked, KEY_BACKSPACE is defined in emerg-shutdown’s source code. Did you restart emerg-shutdown with sudo systemctl restart emerg-shutdown.service after changing this file? It only loads the file during startup, so if you changed it and then didn’t restart, it will never load the new configuration. (That isn’t documented at the moment, it probably should be.)

1 Like

Done.

Will be included in version 18.1.3.8 and above.

Yes, if…

Dunno how big of an if that is.

Seems off-topic.

1 issue = 1 forum topic please.

2 Likes