is a new security model for puppy needed?

[williwaw]

comments have been made in other threads suggesting puppys security model could be better.

which attack vectors present the most risk for a single user, non-networked install?

[p310don]

which attack vectors present the most risk for a single user, non-networked install?

Going out of your own way to install malware..

The greatest risk for most computers is the operator.

[GMBudwrench]

p310don

Going out of your own way to install malware..

I saw someones signature once that read "The biggest threat to a computer is between the keyboard and the chair back."

[dancytron]

comments have been made in other threads suggesting puppys security model could be better.

which attack vectors present the most risk for a single user, non-networked install?

IMHO, the whole internet is the main attack vector.

Host lists, setting up your firewall like you mean it, changing your root password, and maybe quarantining your browser in a chroot or something similar...

[williwaw]

Going out of your own way to install malware..

The greatest risk for most computers is the operator.

lol, I guess I was not thinking of the nut behind the wheel when I posed the question.

seems like some of the mainstream distros have tried to circumvent that by taking a windows like approach and making it bothersome to become root.

When it comes to threats from the internet, some of the threats have become much more sophisticated.

maybe quarantining your browser in a chroot or something similar...

Is running in ram as effective as having the browser in a chroot or container? I can see where not having malicious code persist is one thing, but wouldn't help with some threat "in session".

Is there any such thing as a ransomware type encryption attack that could happen "in session" that might make a savefile/folder or an other partition unusable in future boots?

Is more needed in Puppy to meet present day threats than "security by obscurity"?

[rockedge]

most of the Puppy Linux file system is read only. To the save file or folder it would be possible to write something malicious and effect the system. So maintaining a clean one is important in a security sense. Otherwise it wouldn't be possible to change the main SFS's without some effort. I suppose if someone made a Trojan adrv.sfs and somehow was able to upload it to the Puppy Linux installation folder where it would be loaded during the boot process, this attack vector could be used to load some harmful programs

[williwaw]

I suppose if someone made a Trojan adrv.sfs and somehow was able to upload it to the Puppy Linux installation folder where it would be loaded during the boot process, this attack vector could be used to load some harmful programs

Doesn't seem like an easy thing to do, but I suppose one could run a script on boot to check the integrity of any sfs or a static savefile or folder.

Another possibility would be to hack an adrv and the account at the repo to make a substitution?

[rockedge]

No it's not easy. Yes there could be a potential danger if a adrv.sfs and or ydrv.sfs was hacked. Although the danger would be a replacement ISO that gets spread around with those adrv.sfs and ydrv.sfs files altered and packaged in a release ISO, which would appear as a legit copy but contained malicious code in those files which are auto loaded during system start.

But that still would involve getting access to the Puppy Linux repos and one always can build a fresh Puppy using woof-CE to start out with rock solid system.

[wiak]

I suppose if someone made a Trojan adrv.sfs and somehow was able to upload it to the Puppy Linux installation folder

The initrd would be a smaller file to attack/key-file-to-replace and inside that a modified initrd/init to do something nasty (assuming hacker in with root user permissions). After the boot switch_root that initrd.gz isn't being used so system won't freeze if you swap it over. Not much you couldn't do if you could upload a trojan initrd.gz - even add a new fixed upper layer for unknown to the user sfs module (maybe stored in some hidden path on the system) for use on next boot too. Loading then running system from RAM doesn't protect you from anything really since you can still access the external media. Easiest way (since Puppy going to be running as root user anyway) is for some nasty hacker to gain your confidence to install some apparently innocent pet with a specially crafted binary program inside it (an initrd.gz generator , for example) that swaps over the initrd when the program is run... Thank goodness we all trust each other, the pet and sfs portable app producers and so on, or we'd be checking the sha- or md5-sum of our initrd.gz each time before booting... Any 'extra' malicious sfs module could include code to hide its existence and auto-umount when done its call-back-to-hacker work. Hmmm... are you sure you want to try Hackadmin's newly released chome-portable sfs when logged in as root user???

Actually a pre-built Puppy could contain nasty code as could any other forum created distro. Better build your own via WeeDogLinux build scripts since they are not super complex to check - at least you know what you are getting then and more so since they use upstream package managers and official repos only if you so choose... and... are true multiuser capable I suppose the DogHouse dogs are similar in terms of official package managers etc, but do include some weird little binaries to allow them to behave a bit more like Pups - maybe a specially crafted pup-volume-monitor binary or whatever...

But it is the 'community-provided' little dotpets and so on that are the likeliest attack vector I'd say (along with the hundreds/perhaps-thousands of Puppy distro remasters), and the fact that these are going to be run by root user.

I don't want to make you nervous, but I wouldn't myself happily run Joe Blog's new dazzling remastered iso release - not unless I was really confident about Joe Blog (name made up - apologies to any actual Joe Blog if one on here).

[rockedge]

build your own via WeeDogLinux build scripts

I just have built several while refining a plugin to build WeeDog64-Void's with a JWM - ROX desktop......and they all use runit instead of systemd and being able to overlook the plugin's commands before a build is another solid security feature. WeeDog is a main stay daily driver in my Kennel. I've just touched the tip of the iceberg of WeeDog's potential.

I agree that a hacked initrd.gz would be a game changer. The SFS's and PET's I gather in are from trusted sources and regular contributors on the forum

[williwaw]

thanks for the insights. I am setting up an old laptop and will try to make better use of features already in my flavor of choice

[user1111]

most of the Puppy Linux file system is read only. To the save file or folder it would be possible to write something malicious and effect the system. So maintaining a clean one is important in a security sense. Otherwise it wouldn't be possible to change the main SFS's without some effort. I suppose if someone made a Trojan adrv.sfs and somehow was able to upload it to the Puppy Linux installation folder where it would be loaded during the boot process, this attack vector could be used to load some harmful programs

Actually changing a sfs when you have root permissions isn't as difficult as it may seem. The header structure is moderately easy to figure, so identify the compression method, and offset/pointer to the gzip'd/whatever version of a particular file and you could substitute that gzip content with ... whatever. Provided the replacement gzip file/content was shorter in size then it will fit OK. So pick a file, any file, ideally (for hacker) a executable file that's commonly used, and form a version that does the same task so that it looks as though it still does what its supposed to, with a little additional 'functionality' in the same or less amount of gzip'd file space. Maybe simple functionality that simply sends out a request to the hackers servers asking 'what should I run' and then runs the returned action, before looping around again.

Hmm! But a problem, how to get root access to make such changes? Well much of software have bugs/flaws that can be exploited, some browsers even publish those as part of the later version fix reports. So detect a older version still being used and with some effort they might be exploited to drop into root control.

As countermeasures, loading the main SFS into ram before its storage medium is physically disconnected would help, as might checking the sfs's checksum to see if it had been changed. Ditto for the MBR/initrd/whatever. Intrusion detection. Browser and data wise there's not a great deal you can do, best to just assume they could be flawed and 1. keep good disconnected backups of data, and 2. boot to a known clean session/system before doing sensitive stuff such as banking, and reboot again afterwards. If you boot, go direct to your banks web site using a clean system then there are little opportunities to hack that session. Rebooting afterwards better ensures that there's no residual data/information being left around. For whatever reason however the common practice is to run with systems that are rw instead of ro and where at any time across the entire history something might have been changed (hacked).

Booting the exact same 'clean' system each and every time, along with good backups and append write only to data (audit trail) is a great way to implement security. All of the big businesses that sometimes see days of outage due to ransomware or virus could largely be reduced down to a simple coincidental shutdown/reboot to get back to clean operation, and where data analysis might roll back to known clean versions of data.

Most hackers wouldn't bother with attacking individual PC's however, too much time/effort for little potential benefit/large downside risks. Central repos so that their code is broadly distributed have far greater appeal, as do central high value data repositories. As such, just simple backups and good practices is more often enough for single desktop users.

Me, I checksum the main system files, load to ram, run browser in a chroot/capsh (capabilities dropped) 'container'. So even with root access that 'root' is just a highly restricted userid with just the name of 'root'. Some time/effort required to initially set that up but once done its done, little different to just booting a regular desktop.

[williwaw]

checksum the main system files, load to ram, run browser in a chroot/capsh (capabilities dropped) 'container'.

thx

[wiak]

If the distros discussed on this forum were hugely popular that would bring the biggest hacking risk. Being used by so relatively few, probably, the likelihood of a professional hacker targeting the distros here is likely to be small. By far the likeliest danger would be from some gremlin who decides, as I said, to create a nasty dotpet or community sfs for his or her amusement. i.e. we are more likely to become victims to those in our own family (community) - people we 'know'. So rockedge is correct to use people who have a long reputation and trust here - of course a person could join the forum and behave for a year to gain everyone's confidence and then nuke us all! Most dodgy dotpets and apps in sfs modules are likely to have less dangerous abilities by far is not run as user 'root' or inside some protecting container - that's why I comment that 'running as root' remains the likeliest weakness to each of our personal security - not so much from global hackers out on the Internet (though browser flaws and so on are a general danger all distros face).

Forum contributions are potentially more 'dangerous' than official distro releases since the people who make such releases are indeed well-established and trusted. Many other distros limit that kind of danger in the sense that they keep major contributions in well-tested repos - Puppy has a 'here is a dotpet/sfs I just made for you to run as root user approach' to addon apps, so no appointed, trusted, maintainer to pre-test carefully for safety. No big deal with that thus far that anyone has ever reported so some consolation in that I'd say.

[joet12345]

Browsers post the majority.

So firejail a browser and keep in in a sand box plus built in a version of ublock origin....

browsers and corrup.t ad-ons that are probably not audited...

[8Geee]

Basically, the original is still one of the best... run the Pup from a Read-Only optical drive. There are portable CD/DVD drives available for on-the-road.

8Geee

[wiak]

Arch Linux also allows user-contributed packages in a somewhat unofficial way via its AUR repo. It is kept unofficial in that packages in there cannot be installed by Arch's official package manager pacman directly. Instead you have to git clone the package from the AUR and then use the PKGBUILD script to create a pacman package out of that (which can including compiling from sources). In terms of the security issue involved, using an example of mysql (which I'm currently playing with - except I'm using officially supported Arch package mariadb), Arch offers this security advice:

Understand that AUR packages are not officially supported, may be updated less frequently, and because they are not necessarily submitted by a vetted Trusted User, their PKGBUILD/ETC should be reviewed for any suspect code. That said, as of early 2019, the current AUR maintainer for mysql is "Muflone". Although not a vetted Trusted User who can publish to the official repositories, he has been a valuable contributor to Arch since 2011, maintains about 250 AUR packages (many of them popular) and has never done anything suspect.

So to a large extent, using Arch AUR is, from a security point of view, similar to using contributed Puppy dotpets/sfs files, except that creating an Arch AUR package is a lot of work (so less likely a mischievous hacker would bother) and includes the PKGBUILD script, which can be examined for any such mischief (which is a big difference really - much more secure in that sense). Having said that, most packages I tend to later addon (for my own use) to my WDL_Arch64 distro system are available in the official Arch repos anyway (so much more secure in practice), but when they aren't someone almost always has created a build on AUR repo.

In similar vein to Arch AUR, a better security model for Puppy could include requiring user-addon-packages/contributions to be scripted instead of ready build dotpet/sfs files - i.e. a script that user runs to build the dotpet or the sfs. Much more work to prepare such a package build script, but definitely has the advantage of allowing everyone to check how it was built along with additional advantage of allowing an individual to customise the build or use it as a template for some other build of their own. No not running by default as root-user would also limit the damage user-contributions could do.

[mikewalsh]

@wiak :-

I hate to come across as all "negative", Will, but reading your posts in this thread would scare the bejesus out of your average Joe Bloggs. It would scare the crap outta folks to such an extent that I reckon many would question the sanity of even buying a computer in the first place.....never mind taking the absolutely mammoth risk of going on-line with it..!

You trying to shut down the 'net single-handedly?

(The very fact of your even mentioning the concept of a hacked initrd.gz followed by "replacing" the official download ISO file, means that someone, somewhere, will already have read it and could already be formulating "ways & means". Have to be VERY careful what ya post, mate...)

------------------------------------------------------

As for tackling williwaw's original query, I have to agree with 8Geee. Puppy's original model is still the best; running from an optical drive, loading read-only files and shutting down without creating a save-file takes some beating. I mean, I'd like to see any hacker attempt to modify read-only files on a "closed" CD/DVD.....especially when it can be completely removed from the machine immediately after booting.

Crack that if you can, "Neo"!

Mike.

[wiak]

(The very fact of your even mentioning the concept of a hacked initrd.gz followed by "replacing" the official download ISO file, means that someone, somewhere, will already have read it and could already be formulating "ways & means". Have to be VERY careful what ya post, mate...)

For casual home use of computer, personally I don't think there is much to worry about - not with distros that the majority in the world are not using anyway. However, I think it is actually best to point out the dangers of user-contributions - you make many a contribution, so have I over many years, and I guess we are basically 'trusted' due to that long history of doing so. But that doesn't mean the community shouldn't be aware of the danger that some bad actor could suddenly appear and disturb this peaceful arena. Being aware of the type of attacks that could relatively easily be made is better than burying our heads in the sand and imagining such attacks are impossible. The initrd example was in retort to the comments about the 'apparent' safety of read-only sfs files - such safety is simply a dangerous illusion. Having said that, the forum members who develop distros here (and create and modify initrd and similarly complex files) are well known and 'trusted' - so it was a simple reminder how important the 'track record' of contributors is taken into account, especially when major system files are involved, prior to blindly installing their work. i.e. a little knowledge is a dangerous thing, but ignorance can lead to blindly unexpected disaster. That's why out there in the increasingly dangerous web environment there is big money for expert hackers to determine potential exploits so that these holes can be filled before we fall into them. Silence is not golden in the world of computer security.

[mikewalsh]

@wiak :-

I have to wonder, y'know..... Kinda makes me think that a good many exploits over the years may very well have been initially prompted by threat actors casually trawling community forums.....specifically these particular 'security' sub-forums, and looking for those "what-if" type of threads where this sort of thing is openly discussed on a publicly accessible website.

And then "getting ideas"...

As for "track records"....mmm. The point is well taken, though for the life of me I can't understand why any regular contributor to a small community would even entertain the idea of such behaviour. Reputations are a hard-won thing; they're easily lost, and trust is usually difficult - if not impossible - to ever fully regain.

Such reputations are usually well-guarded, and jealously hoarded....

(*shrug*)

Mike.

[williwaw]

Thanks for the good ideas. Perhaps a way to verify the integrity of the os at each boot would be useful.

Are there any pups,dogs,etc. that lend themselves to being able to configure the loading (or unloading) of the savefile at boot time?

[Feek]

Are there any pups,dogs,etc. that lend themselves to being able to configure the loading (or unloading) of the savefile at boot time?

Not sure what you mean exactly.
Using more than one savefolder, the boot process stops (before loading the save) until is chosen which one to load. If "none" is chosen, it should be the same as pfix=ram.

I use reboot or shutdown for unloading of the currently loaded save.

A savefolder can be after right click duplicated on linux partition (only from outside - cannot be in use at the same time). Different savefolders can be used for different purposes.

I´m not certain about savefiles, in princip should be similar.

[mikewalsh]

Zero trust security model
https://en.wikipedia.org/wiki/Zero_Trust_Networks

Gawd. In other words, trust no-one.....and automatically assume that everybody else out there is up to no good, full of bad intentions, and out to make your life hell.

So this is the world we're living in. Marvellous....

Mike.

[8Geee]

Trust no-one model was tried in Dr Strangelove... it failed there too. Too many trusting individuals out numbered and out gunned the base. It appears a limited or selective trust policy is needed (end user in control).