I wonder if you could have "staged layering" - where the init process stalls at various steps and allows the user to validate checksums against known good values - before continuing to the next init step.
That would be like a form of 2FA.
Can't see how that level of security could be achieved with a full install unless there was some way to discard files newer than a certain date and therefore always run the system via a dated snapshot of the full install. Not layered - but multiple snapshots/rollbacks.
Is Full Install Secure?
A common claim for layered (frugal) is the benefit of being able to save, or not. However full installs can do similar. If you rsync a full install on sda4, using something like
cd /mnt/sda3
rsync -a /mnt/sda4 sda4-sync/ --delete --ignore-errors
then yes that does take time (a number of minutes) to run through the first time, and doubles up on the total amount of disk space used, but nowadays disk space is relatively inexpensive, and when it comes to restoring or subsequent updates it flashes through quickly.
To restore such a snap (save) you just reverse the direction
cd /mnt/sda3
rsync -a sda4-sync/ /mnt/sda4/ --delete --ignore-errors
which again flashes through quickly assuming a modest amount of changes/differences.
i.e. full installs do have the option/ability to use save's, you could boot a clean version of a full install at each reboot, and you also have the option to update that 'clean' save (add software, rsync it to the sda4-sync).
But that does involve an additional boot-strap layer. Boot, rsync the sda4-sync/ folder to /mnt/sda4/ and its back to 'clean' again, as though no save had occurred the last time it was used. Perhaps booting a very minimal system/initrd that performs such rsync actions (or not) and then chains to boot-strap the full installed system. Integrity checks could be performed as part of that mini boot stage.
Personally I'm using a simpler integrity check mechanism that is run after the boot has completed, secure keys (md5sum) that if mismatched to the booted versions results in a big warning screen being left on the desktop. For a single user desktop setup that's adequate IMO, but yes that mechanism could be made even more secure/reliable.
cd /mnt/sda3
rsync -a /mnt/sda4 sda4-sync/ --delete --ignore-errors
then yes that does take time (a number of minutes) to run through the first time, and doubles up on the total amount of disk space used, but nowadays disk space is relatively inexpensive, and when it comes to restoring or subsequent updates it flashes through quickly.
To restore such a snap (save) you just reverse the direction
cd /mnt/sda3
rsync -a sda4-sync/ /mnt/sda4/ --delete --ignore-errors
which again flashes through quickly assuming a modest amount of changes/differences.
i.e. full installs do have the option/ability to use save's, you could boot a clean version of a full install at each reboot, and you also have the option to update that 'clean' save (add software, rsync it to the sda4-sync).
But that does involve an additional boot-strap layer. Boot, rsync the sda4-sync/ folder to /mnt/sda4/ and its back to 'clean' again, as though no save had occurred the last time it was used. Perhaps booting a very minimal system/initrd that performs such rsync actions (or not) and then chains to boot-strap the full installed system. Integrity checks could be performed as part of that mini boot stage.
Personally I'm using a simpler integrity check mechanism that is run after the boot has completed, secure keys (md5sum) that if mismatched to the booted versions results in a big warning screen being left on the desktop. For a single user desktop setup that's adequate IMO, but yes that mechanism could be made even more secure/reliable.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
Hmm! Interesting. Never tried it before myself but with rsync you can live sync - and it seems to work from the quick test I've just run. Boot the full install (non layered), use it for a bit and then rsync restore the 'clean' (sda4-sync) content from within that full install booted version ... and it does revert to being 'clean' again.
I left chrome running and created some files in the booted full install and then ran rsync -a sda4-sync/ /mnt/sda4/ --delete --ignore-errors ... from within that (non layered) session - and seconds later those newly created files were all gone, chrome had also reset to being clean again i.e. back to a 'clean' (saved) session again.
That's one up on layered (frugal) that requires you to reboot without saving to re-initiate back to a clean session, but that said it was a very minimal test (posting from that session now), so very 'alpha'. In the first stage could just add a script to ~/Startup that prompts you to either continue with the previous session as-is, or revert to the last 'save' (rsync of a clean version) [and not a single .wh whiteout file anywhere
]
I left chrome running and created some files in the booted full install and then ran rsync -a sda4-sync/ /mnt/sda4/ --delete --ignore-errors ... from within that (non layered) session - and seconds later those newly created files were all gone, chrome had also reset to being clean again i.e. back to a 'clean' (saved) session again.
That's one up on layered (frugal) that requires you to reboot without saving to re-initiate back to a clean session, but that said it was a very minimal test (posting from that session now), so very 'alpha'. In the first stage could just add a script to ~/Startup that prompts you to either continue with the previous session as-is, or revert to the last 'save' (rsync of a clean version) [and not a single .wh whiteout file anywhere
][size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
Certainly seems so greengeek.
Rolled back to my 'clean' rsync (save) within the Full Installed (non layered) boot a number of times now, with vlc, chrome, libre ...etc all having been run for a while and each time so far its reverted OK. No crashes and everything I've tried has continued to work as expected.
I guess it would mess some things up, such as if you were running a long compile you'd have to start over again. It could however be selective i.e. whichever folders you wanted to restore to being 'clean'. For simplicity I am doing non-selective syncs i.e. everything under /mnt/sda4 (the full install partition), not selectively omitting /proc /tmp ...etc.
For sfs's, in non layered full install you simply extract them to 'load' them, so rsync'ing back to a pre sfs being loaded save 'unloads' the sfs.
EDIT: Providing you close things down in the current session, then live restoration of a save (using rsync) does seem to work OK. In one instance however I had vlc running, closed its window but forgot about the systray icon and after restoration and restarting vlc again (and jumping to 1hr 12 mins into the thing I was listening-to/watching prior to doing the restore) I later noticed I had two vlc icons in the systray. I guess a better approach would be to exit X, do the restore and re-enter X again. Each restore has been very quick (few seconds or less), but I guess it would be - as there's relatively little/small changes involved in most cases.
Rolled back to my 'clean' rsync (save) within the Full Installed (non layered) boot a number of times now, with vlc, chrome, libre ...etc all having been run for a while and each time so far its reverted OK. No crashes and everything I've tried has continued to work as expected.
I guess it would mess some things up, such as if you were running a long compile you'd have to start over again. It could however be selective i.e. whichever folders you wanted to restore to being 'clean'. For simplicity I am doing non-selective syncs i.e. everything under /mnt/sda4 (the full install partition), not selectively omitting /proc /tmp ...etc.
For sfs's, in non layered full install you simply extract them to 'load' them, so rsync'ing back to a pre sfs being loaded save 'unloads' the sfs.
EDIT: Providing you close things down in the current session, then live restoration of a save (using rsync) does seem to work OK. In one instance however I had vlc running, closed its window but forgot about the systray icon and after restoration and restarting vlc again (and jumping to 1hr 12 mins into the thing I was listening-to/watching prior to doing the restore) I later noticed I had two vlc icons in the systray. I guess a better approach would be to exit X, do the restore and re-enter X again. Each restore has been very quick (few seconds or less), but I guess it would be - as there's relatively little/small changes involved in most cases.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
You could even store multiple different 'saves' (rsync's), but if the installation takes up 1GB for example of storage space, and three family members each want their own save image, then you don't have to rsync three sets of 1GB save images, one for each family member, but can instead use hard links combined with rsync so you have just a single main copy (1GB) and three separate and typically much smaller sets of changes, a bit like difference files.
http://murga-linux.com/puppy/viewtopic. ... 53#1027753
... but where there is no actual difference file(s) as such, each rsync image appears to be the full image for each family members rsync save folder, but beneath that illusion files common to all of the separate saves are physically stored just once on disk.
http://murga-linux.com/puppy/viewtopic. ... 53#1027753
... but where there is no actual difference file(s) as such, each rsync image appears to be the full image for each family members rsync save folder, but beneath that illusion files common to all of the separate saves are physically stored just once on disk.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
Intrusion checking a full installs mbr, menu.lst, grldr and vmlinuz is trivial. What however about a full rsync image/folder that typically comprises tens of thousands of files and where you load (restore) that rsync image into the current session - how might you go about validating that?
A quick-and-easy answer is to run ...
where <dir> is the rsync image folder of both the known clean version and current version (which are the same folder) i.e. run that command just after initial creation (and securely record its md5sum value) and repeat that each time you restore that rsync, to make sure the md5sum's compare.
That could be extended to actually record the output from ls -alR to a file which could then potentially be used to locate exactly what file(s)/folder(s) had been changed, but only to a granularity of file/folder names ... not the actual changes that had been made within a file(s). i.e ls -alR lists all files/folders recursively and shows the ownership, permissions, timestamp and filesize, so if there are any changes to any one or more of those, or there are additional/fewer files/folders the md5sum of that complete set will be different. For most cases that is adequate enough validation.
A quick-and-easy answer is to run ...
Code: Select all
ls -alR <dir> | md5sumThat could be extended to actually record the output from ls -alR to a file which could then potentially be used to locate exactly what file(s)/folder(s) had been changed, but only to a granularity of file/folder names ... not the actual changes that had been made within a file(s). i.e ls -alR lists all files/folders recursively and shows the ownership, permissions, timestamp and filesize, so if there are any changes to any one or more of those, or there are additional/fewer files/folders the md5sum of that complete set will be different. For most cases that is adequate enough validation.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
Just trying to follow from a distance - it looks as if you have a concept there that could form the crux of a self-tracking backup creator/validator combined with a failsoft feature to restore the OS to a known-good-boot.
To be honest those features need to be standard with full install i reckon.
Would you have to build an MD5 list creator into the shutdown routine or do it on the fly? Or have i misunderstood?
To be honest those features need to be standard with full install i reckon.
Would you have to build an MD5 list creator into the shutdown routine or do it on the fly? Or have i misunderstood?
-
RetroTechGuy
- Posts: 2947
- Joined: Tue 15 Dec 2009, 17:20
- Location: USA
Get the program "md5deep -rz", which will produce md5s for the tree from wherever you start itrufwoof wrote:Intrusion checking a full installs mbr, menu.lst, grldr and vmlinuz is trivial. What however about a full rsync image/folder that typically comprises tens of thousands of files and where you load (restore) that rsync image into the current session - how might you go about validating that?
A quick-and-easy answer is to run ...where <dir> is the rsync image folder of both the known clean version and current version (which are the same folder) i.e. run that command just after initial creation (and securely record its md5sum value) and repeat that each time you restore that rsync, to make sure the md5sum's compare.Code: Select all
ls -alR <dir> | md5sum
[url=http://murga-linux.com/puppy/viewtopic.php?t=58615]Add swapfile[/url]
[url=http://wellminded.net63.net/]WellMinded Search[/url]
[url=http://puppylinux.us/psearch.html]PuppyLinux.US Search[/url]
[url=http://wellminded.net63.net/]WellMinded Search[/url]
[url=http://puppylinux.us/psearch.html]PuppyLinux.US Search[/url]