Is Full Install Secure?

[sleeper48]

It is very simple!!

ANY system that has ANY connection to ANY external source of ANY kind is inherently insecure - and that includes a keyboard.

True, nothing is totally secure, but some things are more secure than others. The more Puppy (or any distro) can simplify things, the better.

[8Geee]

I will also add this... If 'it' broadcasts a signal, such as BluTooth, Wifi, cellular, etc. it can be intercepted, or sniffed, or even cracked. The only mitigation is full client/server encryption of at least TLS1.2-256 bit forward secrecy. Many BT connections are open, and WPA2-FSK was only recently patched for end-users, but problems still remain for the host (server).

One should also consider Meltdown/Spectre and the new SSBD (split or cache-level side-channel attacks). A malicious script in an otherwise ordinary picture or webpage can circumvent these mitigations. That means BROWSER ! Even some Atom processors had to be added to the vunerable list due to SSBD.

I will opine that whatever it takes for the machine to be 'safe enough' has to be done to the browser.

Regards
8Geee

[s243a]

I will also add this... If 'it' broadcasts a signal, such as BluTooth, Wifi, cellular, etc. it can be intercepted, or sniffed, or even cracked. The only mitigation is full client/server encryption of at least TLS1.2-256 bit forward secrecy. Many BT connections are open, and WPA2-FSK was only recently patched for end-users, but problems still remain for the host (server).

One should also consider Meltdown/Spectre and the new SSBD (split or cache-level side-channel attacks). A malicious script in an otherwise ordinary picture or webpage can circumvent these mitigations. That means BROWSER ! Even some Atom processors had to be added to the vunerable list due to SSBD.

I will opine that whatever it takes for the machine to be 'safe enough' has to be done to the browser.

Regards
8Geee

I wonder to what extent VPNs like tinc can be jsed to mitigate against weakness in wifi security.

[musher0]

It is very simple!!

ANY system that has ANY connection to ANY external source of ANY kind is
inherently insecure - and that includes a keyboard.

Well my head being a system connected to my body, and my eyes connected
to my head and my hands connected to my forearms...

Yiiiiiiiiiiiiiikeees, I am a totally insecure system!!!!!!!!!!!!! (ROFL)

Come on, guys, let's get serious, shall we?

[slavvo67]

It's a loaded question. Nothing is totally secure; unless you're not connected to the web. Then, you're probably okay... especially if you encrypt.

[Sylvander]

...unless you're not connected to the web. Then, you're probably okay...

Unless someone gains access to your hardware...
A breakin while you're away?

[slavvo67]

Did we miss the "Especially if you encrypt?!"

Many puppies have older browsers so you should at least make sure you update to he latest version of Firefox, Chromium, Iron, whatever....

[s243a]

Did we miss the "Especially if you encrypt?!"

Many puppies have older browsers so you should at least make sure you update to he latest version of Firefox, Chromium, Iron, whatever....

Ransomewhere is found of encryption.

[Moat]

Frugal installs (using auto save techniques) are not more secure...

True. The key is to disable the periodic saves. Personally, I think that should be the default for frugal + save installs (for instance; pupmode 13, ask to save at shutdown (setting 0 or -0?), w/no save after timeout... i.e.; you snooze, you lose).

Next best thing to a remaster!

Just make progressive backups (using the Pupsave Hot Backup utility) as you modify/experiment & save system changes - eventually molding the system to your liking. Then from that point on... select "shut down" and walk away. Always where you last left it at next boot.

Bob

[bigpup]

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

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