Freeze SO Linux, it's possible?

[Loïc Grenié]

2008/12/11 Bart Silverstrim <bsilver at chrononomicon.com>:
> Loïc Grenié wrote:
>
>>     I have slower performance because I'm using an USB key (program loading,
>>   data writing is all done on my USB key and it's slow). If you use a hard-disk
>>   for the read-only partition and memory for read-write, it's probably roughly
>>   the same speed as a regular linux (memory fills while you use the system,
>>   so it might become slow after a while, especially if you download
>> large files).
>
> True. I was thinking your main advantage to the USB key though is ease
> of cloning and backing up rather than a hard disk.
>
> My concern is figuring out if someone clever would find a way to have it
> mount the hard disk R/W on reboot without someone noticing, while CD's
> and hardware-lockable-RO USB drives would thwart this.

     If you user become root on the hosted system (s)he can change the
  BIOS settings in the NVRAM and it will be difficult to prevent him/her
  to boot on a CD and do whatever to a non hardware-locked medium.
  I'm no specialist of Windows/Deep Freeze but it might be the same.

    If the user is not root, s/he cannot change the boot commands.

    In other words, if the hardware is not locked a root user can change
  it. You can have a master copy that is restored each night on all the
  stations (and that eases the update process).

> DF I guess has had a couple attempted hacks, but for the most part is
> pretty good about not being bypassable, maybe as long as you don't allow
> booting from CD-ROM or other devices. Your proposed method is something
> I'd have to ponder and see how comfortable I'd be with that method.
>
>>   If you use a disk partition for both partitions it's probably the
>> same speed as
>>   a regular Linux (maybe slightly slower on slow processors) -- in that case the
>>   read-write partition must be reformated at each boot, though.
>
> Then you get into arguments over slack space :-)
>
> I don't know exactly how DF works and no one seems to come forward with
> explanations. I'm half tempted to see if anyone can get an email
> forwarded to Mark Russinovich (spelling?) to see if he's ever looked at
> it and would be willing to come forward with theories.
>
>>      Only when you create the setup or when you want to update/upgrade
>>   it. At regular run-time, you don't need to know. The system boots like
>>   any Linux system, except that changes don't survive reboot.
>
> Good point, but I think the update and upgrade part is frequent enough
> that it would drive me batty :-)

    It's pretty easy to automate the "upgrade" process.

>>> In other words this might not be an ideal setup for an average end user...?
>>
>>      This is definitely not an ideal setup for an average end user, but Deep
>>   Freeze on Linux is not a very useful program for the average end user. It's
>>   doable for a motivated system administrator (or hacker, in the positive
>>   sense). After the initial setup, which was a pain for me (but I know it's
>>   easier now, but I don't know how much easier) it's not difficult to use,
>>   even when you want to update the "read-only" part.
>
> It's a niche thing. Locking out changes is a niche no matter what...we
> use it because we have two or three people working to administrate 800+
> systems used by students and faculty, so it's to reduce support problems
> with malware and users altering settings and claiming they don't know
> how XYZ was installed or settings were altered.

    If you have to fight against students you probably have already lost the
  battle !!!

            Loïc