some irrelevant (but somehow illuminating) Tiny experience... the immortal Tiny

[TinyCoreFltk]

all started when i decided to install a dualboot Tiny (at first only in virtualbox, to get accustomed with Tiny's unusual but awesome infrastructure). i accidentaly installed 2 bootloaders (don't ask me how i did it. even myself can't answer that ). after a little "hacking" to the main bootloader (to add the secondary Tiny boot options), i tried to get rid the files of the second bootloader. i opened the filemanager with sudo (i don't think that it would let me delete such files as a regular user). went in the second HD, found "boot", and delete. but it said, it couldn't delete the folder as it was read only (the "criminal" was a single file inside this folder  ). ok, lets do it "the men's way"... terminal... su>root (i had asigned a password for root before this), and "rm -rf"... nothing happened.

after some search, i found out that this file was "immunized" (immutab flag is called i think) as read only, even for root, and wanted the chattr command run as root to remove "immunization". ok, download and install e2fsprogs (they contain this command). so again as root i removed the "immunization" of the file and finally got rid of the folder. and then it popped in my mind. "what if i could "immunize" the whole system?" (i use persistent boot, tce, opt, home). and so did i. i immunized, boot, tce, and opt, with just one command  . i even tried the notorious "sudo rm -rf //". of course my (not so persistent) home folder was wiped away but the whole system didn't have a clue of what just happened (it froze of course but after reset it was like new. nothing was damaged)

now i have the immunization permanent on my Tiny and have nothing to fear (i have downloaded the apps i need and have made the setup i want, so i don't need to have the, boot, tce, opt, folders writable any more). the undead Tiny system boots fine, and IF i want to change something, i just run chattr to temporarily remove immunization, and restore it after having made my changes.

[TinyCoreFltk]

enough with the talking, here is  the Tiny immortallity, live on video, in all it's awesomeness:...

http://www.youtube.com/watch?v=Aks_tp3scWg 

nothing but the Tiny itself (and some terminal commands from inside Tiny) was used.


P.S:... it's been long after posting this, but, it would be silly to open new post just for the same subject.

[sebus]

So you are protecting Tiny from... yourself then...

[TinyCoreFltk]

well... not exactly (i'm not suicidal    )... i have done it mainly for security reasons and faster/easier system recovery after some failure. if i screw something, or, even if some script kiddie (or some malicious code) managed to sneak into the system (i sometimes enter some webpages with very doubtful security), i only need a reboot (and optionally a home folder restore from a backup, also locked, located inside "/opt") to restore the system back to normal operational status, in no time

there is no way to unlock the system and tear it down (or "hack" it) from inside itself (e2fsprogs, and therefore chattr command, not installed "onboot", or, "ondemand"). you can do so, only if you have physical acces to the system and boot it from a live media. (if i need to change something systemwide and not user specific -- very rarely -- i go overkill:... reboot from a live system > unlock system > reboot system normally and make the changes > reboot from live and lock system > reboot system normally    )

i think, i have very twisted inspirations sometimes   

[tinypoodle]

if i screw something, or, even if some script kiddie (or some malicious code) managed to sneak into the system (i sometimes enter some webpages with very doubtful security), i only need a reboot (and optionally a home folder restore from a backup, also locked, located inside "/opt") to restore the system back to normal operational status, in no time

The way I perceive it such could be valid for about everyone using default core without any particular procedure...

[TinyCoreFltk]

if i screw something, or, even if some script kiddie (or some malicious code) managed to sneak into the system (i sometimes enter some webpages with very doubtful security), i only need a reboot (and optionally a home folder restore from a backup, also locked, located inside "/opt") to restore the system back to normal operational status, in no time

The way I perceive it such could be valid for about everyone using default core without any particular procedure...

if they gain access to the virtual ramdisk (to sneak in their garbage like they do on a real hard drive), it's easy to find the actual hard drives that live under "//mnt", and start messing (or just deleting) stuff there too.
so, installing Tiny with persistence, and all of it locked (except //home which obviously can't be locked) leaves no options for messing or deleting Tiny's main infrastructure (//boot, //tce, //opt)

[tinypoodle]

Uhmm...
It's the filesystems which "live" under /mnt, the hard drives "live" under /dev.

For your theory to be implemented all following conditions would have to be met:

1. /dev has to be on an ext* filesystem.
2. You would chmod all dev files of hard drives a-w (not sure how compatible that could be with udev).
3. You would chattr them to immutable afterwards.

[TinyCoreFltk]

well... yes... not hard-drives, filesystems is what i meant. slipped my tongue.

1. my installation IS on an ext filesystem

2. i didn't do that, as "/dev" is also in virtual disk (ramdisk), so there is no point. after reboot, it would be lost. (i use the persistent  mode, not the backup, as the backup is painfully slow). not tried this before, so i don't even know what would happen with udev.

3. done that for all files in the actual filesystem (/boot, /opt, /tce) except home (accidentally i have done that on home too, on one installation, and it wouldn't start xorg afterwards. it said something about write error on ".xsession" file)

[tinypoodle]

1. my installation IS on an ext filesystem

I meant condition would be that /dev in particular would be on ext to be made immutable read-only.

With your scenario of a malicious intruder, if they could gain write access to /dev, then immutable files wouldn't prevent deletion by e.g. writing zeros directly to the device, no file system access required.

[TinyCoreFltk]

i suppose, you mean the dd command. i have also thought about this, but haven't found a viable, all time, solution (other than booting from a write protected usb drive)

other than chmod //dev (which lives in ramdisk, so it's not permanent), is there any way to pernamently make a drive, read only, with some boot code, or, something like that? (to be permanent, like chattr, and be able to revoke it if i want)

i'm now trying the chmod thing, but if i can't make it permanent, there is no practical use of it.