Is Full Install Secure?

[perdido]

If you have one of those talking head devices in your home. (Amazon Echo, Alexa, etc....)
There is no security!!!!

Story is all over the news.

Amazon Echo Recorded And Sent Couple's Conversation — All Without Their Knowledge

Oh, but I have nothing to hide so I am ok with that <g>
The convenience factor outweighs anything else <g>
Just a minute while I wait for my windows pc to boot so I can verify your link using bling search <g>
Then I will talk to my toaster and make a cup of auto coffee using my new tv <g>
Later I will use my self driving car <g> while talking on my google android <g> while I order from my amazon account <g>, that is so convenient that they make deliveries into my home while I'm away <g>

And a full install is not secure??? LOL, You have a better chance of catching a virus from cat farts than anything done in a full install.



.

[slavvo67]

In my opinion, the only real threat to a full install is that you can screw up programs that are currently working by trying to update or by adding other program packages that may conflict.

That, my friend, can completely ruin your full install and make you wish you didn't do it. Of course, as long as you backup your important files, you can always do a reinstall.

The other threat is web-browsing and I would worry about internet banking with an older browser OR maybe even with a newer one. But that's not a Puppy issue, that's a worldwide issue.

I've been using TrueCrypt for years along with Ccrypt and have never seen a malware issue, though I'm not surprised they exist.

Oh, and I personally never use any of those software applications that supposedly save all of your logins and passwords. Write 'em down and keep them in a drawer; don't be foolish and ask for trouble....

[rufwoof]

There are other methods to improve security too - mostly focusing on ensuring that system files are readonly and contained within "sfs" files - not contained as read/write files as is done in a full install or a frugal+save.

Never tried it, and can't at present as running OBSD which for security reasons doesn't support layering (SFS's), but wondering how layering caters for dealing with a file that is ro at the bottom layer, but where a higher layer has a alternative version. When layered does the bottom layer 'shine through' (as it should) or does a higher layer version get 'revealed' instead? (Can't imagine that it would as that would be a serious flaw). If a sfs is loaded into memory, then even a ro sfs could still conceptually be operationally tampered with i.e. by changing the referenced ram content - perhaps even more so if being loaded consistently in the same manner (OBSD specifically randomises things in memory after each new boot).

Agree with others. If breaking out of user to root was easy, then server providers would be chasing their tails. A browser running as user has just as much prospect of elevating privileges. The better "prospect" (for dark side hackers) is to find flaws in the kernel processing of privilege based tasks, or flaws in programs that run under a privileged PID.

For me, completely reinstalling from fresh is a 5 minute task. I have OBSD fully installed and its ramdisk is just 9KB, pulls the rest down via http/ftp and is around 8 mostly ENTER's to then be ready to boot to desktop. Tar backup's/restores are relatively quick also. Much of the longer backup/restores is data. OBSD comes pre-set to be secure and unlike Linux - being just a kernel, includes both kernel and userspace which collectively are under regular security audit review. Kernel, bins, libs .... and even X (their own more secure version). The bummer is that it does run slower, especially disk synchronous/secure transfer. You can easily turn that off (async) which does help with speed, but sacrifices security and stability. I liken it to flying. Do I want to board a flight that will get me somewhere in 3 hours, but where the boarding process is clearly insecure and the pilots pre-flight checks consist of just kicking the tyres ... or board a flight where it takes 4 hours, but security and pre-flight checks are much more rigorous. In practice once flying, the speed differences are much less apparent especially when most of activity is being cached in ram.

The other factor is provider. Windows boxes tend to have software installed from here-there-everywhere. Linux have top of tree providers such as Debian who do a reasonable job of checking consistency and security across programs - but where holes are all too apparent (1700 vulnerabilities across all of the kernel + programs on my Jessie based system that I had installed a few months ago). Let alone others such as Ubuntu who take Debian's stuff and "improve" things (add in security flaws - more lines of code = more potential risks introduced). And I was running Debian Main repos only, dread to think what the count might have been by the time other repos were added in on top of that.

Whew! Enough! I'm off to boot my easy-pyro MMC to investigate sfs layering further.

[nosystemdthanks]

i wouldnt expect permissions from existing files to shine through sfs layers. i mean lets figure a few permutations of that:

1.ro bottom file / rw top file

since only root can mount sfs (whether puppy everything-is-root or other distro) you would expect that the permissions for the top layer would be the ones that count


2.ro bottom file / NO top file

if this is what you meant then of course you would expect perms to shine through, since there is nothing on top to contradict (using sfs shouldnt make every already-existing file rw)


3. rw bottom file / ro top file

you would probably want ro to be ro here-- not for rw to shine through.


whether editing the file in the sfs affects the file underneath or not (i would expect it to affect the file in the sfs, and leave the "bottom file" untouched) im trying to figure out why you would EVER want the perms of the mounted (top) sfs to be ignored or to count "second." but apologies if i misunderstood.

[rufwoof]

1.ro bottom file / rw top file

since only root can mount sfs (whether puppy everything-is-root or other distro) you would expect that the permissions for the top layer would be the ones that count

... that is the particular case I have in mind. ro main sfs at the bottom, rw layer on top of that, that records any changes. B bottom ro layer, C changes rw layer, T top layer that 'shows' (formed by C overlaid on top of B).

Such a structure employs .wh files to indicate deleted files. The changes (C) layer is also rw by anyone, so for instance a user "deleting" /home/user/.profile file stored in the B ro bottom sfs layer would be recorded as something like a /home/user/.wh..profile file created in the C layer, so that /home/user/.profile file isn't 'shown' in the Top (T) layer. My thoughts are that as the changes (C) layer is rw, then even though I haven't a particular exploit/method/example in mind, it just feels like it could contain potential security risks.

I suspects its as good as conventional (non layered) file/folder permission security, some such as OpenBSD however do frown upon such methods, so I suspect there are additional security risks involved - perhaps such as the layering structure recorded in memory potentially being editable in a undesired manner if stored in a non W^X region (which I believe would be the 'natural' case under Linux anyway in not implementing W^X). If OBSD with their W^X and kernel/memory randomisation are reluctant to employ squashfs overlays, its somewhat uncomfortable using such in even less security conscious alternatives such as Linux!

My guess is that full install would be more secure than frugal T = B + C type layering (main sfs + save/changes).

[greengeek]

... but wondering how layering caters for dealing with a file that is ro at the bottom layer, but where a higher layer has a alternative version. When layered does the bottom layer 'shine through' (as it should) or does a higher layer version get 'revealed' instead?

Very good question. I would imagine that the highest layer always takes precedence - even if it changes a ro file to an rw file.

However - the result should surely only be revealed during a live session - in a properly configured system that "override" should not be allowed to contaminate the next boot by being incorporated into the saved data. (unless of course the user specifically requests it by virtue of updating a savefile or save folder).

Contamination of a session is possible using the method you describe - but how can this be avoided? Avoidance of "in session" contamination is the goal of every browser update (or ssl update, or wget update etc etc etc) but in the end there will never be totally secure system i suspect.

As far as I can tell, full installs never allow any mechanism to exist that locks out "in session" contamination - such contamination always become permanent and reflected in every subsequent boot.

[rufwoof]

Contamination of a session is possible using the method you describe - but how can this be avoided? Avoidance of "in session" contamination is the goal of every browser update (or ssl update, or wget update etc etc etc) but in the end there will never be totally secure system i suspect.

As far as I can tell, full installs never allow any mechanism to exist that locks out "in session" contamination - such contamination always become permanent and reflected in every subsequent boot.

Doesn't something like Suricata do that, unusual behaviour/action type detection? Simpler Intrusion Detection System (IDS) such as mtree are already a integral part of OpenBSD - that in effect just run a checksum against each file and compare to a known clean checksum value. More usually set to monitor /bin, /sbin and /usr - and where /bin and /sbin validation flashes by very quickly, but /usr takes much longer ..... Just run mtree interactively on my obsd system for instance that has kdenlive, libreoffice ...etc i.e. a lot of libs and and time ids (my setup) 4m14.43s real 1m48.82s user 0m31.55s system

Attached is a snippet from Mastering FreeBSD and OpenBSD Security By Yanek Korff, Paco Hope, Bruce Potter

[cousinFrancis]

If you have one of those talking head devices in your home. (Amazon Echo, Alexa, etc....)
There is no security!!!!

Story is all over the news.

Amazon Echo Recorded And Sent Couple's Conversation — All Without Their Knowledge

Oh, but I have nothing to hide so I am ok with that <g>
The convenience factor outweighs anything else <g>
Just a minute while I wait for my windows pc to boot so I can verify your link using bling search <g>
Then I will talk to my toaster and make a cup of auto coffee using my new tv <g>
Later I will use my self driving car <g> while talking on my google android <g> while I order from my amazon account <g>, that is so convenient that they make deliveries into my home while I'm away <g>

And a full install is not secure??? LOL, You have a better chance of catching a virus from cat farts than anything done in a full install.

[rufwoof]

As far as I can tell, full installs never allow any mechanism to exist that locks out "in session" contamination - such contamination always become permanent and reflected in every subsequent boot.

Not always. For instance I'm more inclined towards tracking OpenBSD --current nowadays as you get the very latest (security patched) software with that, so pretty much fresh full install each time I boot. Yes that means a slower boot, typically 5 minutes to download the latest 9M or so snapshot ramdisk image and fully install the system to HDD before the system is ready, but that's OK for my typical daily action of pressing the power on button and then making a cup of tea/coffee and by the time I get back to the PC its all ready to go.

More a question of time then? Using a Puppy fixed sfs that has you back to a clean/pristine (equivalent of new install) after just a reboot amount of time, versus 5 minutes to do a clean/pristine full reinstall to HDD. With the latter however that's the latest (authenticated) versions of software, so for the former to compare you should also factor in the time it takes to update to the latest software (availability of that, the security of the process of updating, and the time that it takes to do that ... and reboot again). But even then the two don't compare as with Puppy the base system security is nowhere near as extensive as under OpenBSD (that randomises many things such as the kernel, pid's, file id's, randomises and encrypts swap, monitors that programs stay within the bounds of what they are expected to do/use ...etc. - and of course not running as root). OpenBSD also separates memory utilisation (i.e. W xor X (write or execute)) along with other measures that make contamination of things running/loaded in ram to be difficult (its also careful to ensure that ram is also cleaned appropriately so as to not leave sensitive things hanging around either).

Is it not then just perhaps structure? A desktop OpenBSD setup might comprise a headless OpenBSD router that also serves as a PXE server for desktop clients to boot (install) from, where those desktops tend to be more terminal client like (run typical desktop programs via secure shell or remotely such as googledocs or online calculator ... etc.) where that 'terminal/gui session' is extremely secure and data is isolated/remote, versus secure base system (Puppy sfs) but where the software within that might be outdated so as to compare other procedures (updates/security patches etc.) have to be added on top in order to compare more like-for-like. But where even then the system isn't as secure due to lower levels of the entire system as a whole being protected/audited/validated.

In addition to the standard OpenBSD 'secure by default' install, I also add in checksum tests (using mtree) against bin's, sbin's, lib's and /etc so if any of those files/folders were compromised such as a trojan installed I'd be made aware of that. I guess using nice and repeated/continual checking that could be made even securer, in my case however I have it set to just run hourly. i.e. my intrusion detection is relatively mild/light (few however (as far as I am aware none) employ any IDS under Puppy Linux).

[rufwoof]

I'd suggest naming conventions of

Full Install = Non Layered (all changes written directly to storage).
Otherwise ... Layered (changes are stored in ram, that are optionally written to storage - or not).

You can full install to a partition and run that as-is where all changes are recorded (non layered). Rolling back that to a clean backup typically takes less than 5 minutes and the backup file can be compressed/copied/moved etc.

You can layer a full install, use the full install partition as the "save area", but where you can optionally save, or not, changes that occurred during a session.

Or that save area can be a file filesystem (save file), or save changes in a folder (save folder).

Layered involves a initrd, full install doesn't. initrd's are easily opened/changed/closed again and as such are a security risk that full install avoids. Countering that, layered is better suited to booting a known clean version, using it, and closing without preserving changes (so the next boot is also clean), whilst that's possible under full installs it takes more time (restore time). With layered you can add additional layers on top of existing layers - mount (and unmount) additional sfs's on the fly (you can 'mount' sfs's in full installs i.e extract the sfs's content, but undoing that is more awkward, or requires a reboot and restore).

Layered broadly is the more flexible choice, but from a security perspective is no more secure than a full install, subjectively less secure (initrd risk). For instance given access to a Puppy system, with relatively small changes .. just several lines of code, I could easily set it up to boot with a sub system layer running beneath and hidden from Puppy's view - that initiated a connection to a server I controlled.

[greengeek]

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.

[rufwoof]

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.

[rufwoof]

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 ]

[greengeek]

Sounds interesting - if I understand correctly what you are saying it could be possible within a session on a full install to revert relatively quickly to a "known good" state?

[rufwoof]

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.

[rufwoof]

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.

[rufwoof]

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 ...

Code: Select all

ls -alR <dir> | md5sum

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.

[greengeek]

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?

[RetroTechGuy]

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 ...

Code: Select all

ls -alR <dir> | md5sum

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.

Get the program "md5deep -rz", which will produce md5s for the tree from wherever you start it