Run an Almost Invulnerable Puppy

[mikeslr]

Edit December 7, 2020:
You know it finally occurred to me that you may be able to save time and effort by using Puli. https://forum.puppylinux.com/viewtopic.php?p=2551#p2551 or EasyOS, for the reasons explained on this thread. https://forum.puppylinux.com/viewtopic. ... 873#p11873. In particular, read rufwoof's post, https://forum.puppylinux.com/viewtopic. ... 122#p12122. Edit 3/13/21: also note my post here, viewtopic.php?p=19808#p19808. But then you'll miss all the fun of learning how Puppies function, selecting one which you like and training it your way. Original revision follows:

History of this Post.

This is only slightly edited from the post @ http://murga-linux.com/puppy/viewtopic. ... 066#974066 which had last been edited in February 2020. It was part of a continuing discussion started by jpeps on ‘How to Remove the Automatic Save’ and combining some of the work which appeared on shinobar’s thread “Keep your savefile slim and healthy”, http://murga-linux.com/puppy/viewtopic. ... 769#468769, Together those discussions spanned 18 pages. Combining the two beneficial actions had some undesirable side-effects. The February 2020 post put all the ‘workarounds’ known to me to those side-effects in one place and brought it up to that date.
=-=-=-=-=-=-=-=-=-=-=-=-=---=-=-
On boot-up a Puppy will copy into RAM its operating system files, all of which are READ-ONLY with the exception of what you, as User, have SAVED to you SaveFile or Folder. If you never SAVE, your system will be as pristine as the when you first deployed it.
Your SaveFile/Folder enables you to Save the changes you’ve made to your system. By default, a Frugal Puppy is setup to execute an automatic Save every 30 minutes. jpeps’ thread showed the method(s) to modify that interval to Never while retaining your ability to manually execute a Save when you want.

When a SAVE is executed everything in RAM –with the exception of files in /tmp-- is copied to Storage. By EVERYTHING, I mean including the new applications you’ve installed, the settings and customizations to your applications, which SFS applications will be loaded at boot-up, files downloaded into /root/Downloads, /root/spot/Downloads, /home/spot/Downloads, any datafiles you wrote to or edited in /root/my-documents, all the mistakes you’ve made by installing or changing applications, and all the junk which got downloaded while you surfed the web even if you didn’t know you downloaded it.
Obviously, you don’t want to preserve the latter bunch.

Which is why, although I may test changes at any time, I do not perform a Save until I’ve re-booted, only made the changes I want, and (except if pertaining to Web-browsers) especially before going on line.

Removing the Automatic Save has the following beneficial effects on your system: (1) Reduces the likelihood of corrupting your SaveFile or installing gibberish into a SaveFolder when a scheduled Save occurs during a power-surge or power-outage; (2) corrupting a SaveFile on reboot/shutdown when the amount of files to be Saved exceeds the available space in a SaveFile; (3) Saving errors, non-functional applications or just junk you’ve unknowing picked up while surfing; and (4) incrementally filing up a SaveFile with such unwanted files. Deleting non-functional applications does not entirely restore the space in your SaveFile which had been used by that application.

If you are booting from a USB-Stick and using a Puppy first published since about 2015 all you have to do is open Menu>System>Puppy Event Manager, Click the Save Sessions Tab, change the Save Interval to 0 (zero); AND check the “Ask at Shutdown” box. Unchecked, Puppy will automatically Save at Shutdown.
If that Puppy is on your hard-drive, you ALSO have to “trick” Puppy into ‘thinking’ it is booted from a USB-Stick. By default, the boot argument on the kernel/linux line is either silent or reads pmedia=atahd. Edit that argument, or include one, to read pmedia=ataflash.
Pre-2015 Puppies have an earlier grub4dos version. With those Puppies, you ALSO have to install shinobar’s updated grub4dos available from here, http://hg.shinobar.server-on.net/puppy/opt/. The only way I know of determining whether the updated grub4dos is necessary is to perform the other steps, reboot –to make certain they are in effect-- then shutdown again and carefully watch if despite those changes the Puppy still performs a Save at shutdown.

Removing the Automatic Save, however, has it downsides. You have to remember to Save if you want a change to become permanent. And there are many times you would have to perform a Save if you don’t take steps to change how Puppies work after removing the Automatic Save.

Like all Linux distros of which I’m familiar when an application is instructed to save a data-file it first offers to save it in your Home Folder (the functional equivalent of Windows’ ‘Documents and Settings’ Folder). This is also the first location from which applications will offer to open a previously saved file. In Puppies, your Home Folder is /root and the contents of /root are only in Random Access Memory until Saved. It’s kind of annoying to spend time writing, periodically having LibreOffice save the additions/changes and later boot into Puppy and discover all your work is missing. The /my-documents folder is in /root; /root was in RAM and RAM wasn’t Saved to Storage. Of course, I could have Saved RAM to Storage; but this would have Saved everything then in RAM to Storage.

There’s an easy Workaround. And it forms the basis for all others. Open two file-manager windows, one to /root and the other to /mnt/home. Using rox on a standard Puppy’s desktop, Left-clicking the ‘Files’ or ‘Home’ icon at the Top-Left corner of your monitor will open a window to /root, your Home Folder. Just above your Task-bar are icons representing your drives/partitions and providing short-cuts to them. The one which immediately on boot-up has an ‘x’ in its top-right corner represents your home drive/partition –otherwise known as /mnt/home (or /mnt/dev_save). Left-clicking it will open a window of your Home Partition. Remember, while your Home Folder is in RAM, your Home Partition is on Storage. Within your Home Folder you’ll see a folder named “my-documents”. Left-Press, Hold, then drag that folder into your Home Partition Window. From the popup menu, select Move. Again Left-Press, Hold then drag the “my-documents” folder back into your Home Folder. From the popup menu select Link(relative). This will create a symbolic link (short-cut/symlink) in your Home Folder directly to the ‘my-documents’ folder which is now on your Home Partition and, thus, on Storage. Anything you write to the ‘my-documents’ folder and folders you create in the ‘my-documents’ folder will be immediately written to Storage. No further Save is necessary. Similarly, selecting the /my-documents folder from an application's file menu as the location from which a data-file is to be opened, immediately takes that application to the ‘my-documents’ folder on /mnt/home (Storage).

After its been relocated, to expedite access to it, you may find it helpful to bookmark the my-documents folder; and any other folder you move to or create in /mnt/home.

An advantage of keeping data-files outside of your SaveFile is that they’re immediately available if you ever want or need to replace your Puppy. [They are never in a corrupted SaveFile/Folder]. Of course you can access them by browsing to them. But you can again link them to /root. However, you’ll first have to delete [Right-Click>delete] the auto-created-by-Puppy-and-empty /root/my-documents folder. You can’t create a symlink in a folder which already has a file/folder with the same name.

One of the other folders you’ll want to move out of /root is the ‘Downloads’ folder which, I believe, is created the first time you download a file using firefox or one of its clones/forks – palemoon and seamonkey. The procedure set out above is exactly the same with regard to the Downloads folder. But rather than move it to /mnt/home you could move it to /mnt/home/my-documents.

You can create any special folders you think may be useful --videos, music, whatever-- on /mnt/home and symlink them to /root. Open a window to /mnt/home. Right-click an empty space and from the popup menu Select New>directory. Give it a name. Then drag it into /root and select Link(relative).

With the Downloads folder outside of /root it is easier to test pets without actually installing them. You can left-click a pet to “install” it, but until a Save is executed it is only in RAM. Menu>Exit>Restart-x (AKA Graphical Server) will cause Puppy to re-catalog what is currently on it’s system. You can then run the pet or examine its binary with ldd* to determine if any library is missing. If a pet can’t be run, rebooting without Saving clears it completely from your system. Libraries which ldd showed as missing, if located, can be installed and the application tested again. Once you’re satisfied with a pet, you can reboot without Saving, browse to your Downloads folder, install the application and any necessary dependencies and immediately Save. Alternatively, applications which conflict with others can sometimes be converted into SFSes, loaded when needed, unloaded when not. [Look for posts about creating SFSes].

* To use ldd, browse to the location of a binary, open a terminal and type 'ldd NAME_OF_BINARY'. Some Puppies have Menu>Utilities>List dynamic dependencies. Most Puppies permit you to Right-Click a binary and select ListDD from the popup menu.

Puppy Package Manager is an application requiring special handling. The records PPM uses to determine what repos are available and their contents are files in the /root/.packages folder. Note the “.”/dot, signifying a hidden file or folder. Left-click Rox’s “Eye” to reveal them. Being in /root, an updating of those records will only be kept if a Save is executed. Bringing PPM up to date is among the first steps I take after creating a SaveFile/Folder. Before exploring the possibility of adding new applications by employing PPM, I’ll update it again immediately after booting into Puppy. However, the first time I run PPM, I make the following system changes before Saving:

Click the Configuration Tool (Crossed-Tools icon at the top-left), then click the Options Menu. Place Check-marks for the following:
Always redownload packages when they preexist – required to create self-sufficient SFSes; also lessens the occasions when PPM halts, seeking input.
Do not delete downloaded packages after installation – as initial ‘install’ is only for testing
Then, where it says “Save PKGs in:” change the location from /root to /mnt/home/Downloads. That location is on Storage and, being the same location where browsers download files, provides for consistency. But any folder on /mnt/home will do and, if you are not conscientious about moving files out of ‘Downloads’, perhaps be better. Perhaps a folder named Testing.
I don't allow PPM to AutoInstall. Depending on the circumstances, I use the tool on PPM's Top-Right to select either "Download Packages (No Install)" or "Download all (packages and dependencies)".

Web-browsers: Puppy Devs will usually include some Web-browser which makes it easy for you to get online almost OOTB. I recommend, however, that you replace or supplement the included web-browser with one (or more) of the portable web-browsers you’ll find here viewforum.php?f=90 specifically titled “Portable”.

“Not-portable” firefox, seamonkey and palemoon place their profiles (settings, addons, bookmarks) in hidden folders in /root. To change or preserve them, you have to execute a SAVE. When you visit a website it downloads files to your computer (so that it doesn’t have to do that again the next time you view its webpages). The above “Not-portable” web-browsers locate those files in a hidden cache folder, also in /root. Web-caches can quickly add up to hundreds of megabytes. By default, they will be using RAM, reducing the amount of RAM you have for actual work; slowing the responsiveness of your applications and may even result in a crash of your operating system.
Portable web-browsers can be run from anywhere. You can locate their folders on /mnt/home. They are designed to locate both cache and profiles within their own folder.

If you are not using a portable web-browser, I recommend moving its cache folder out of /root to somewhere on /mnt/home and symlinking it back, using the same technique as above described for the /root/Download folder.

Edit March 2021: I've had 2nd thoughts about portable web-browsers. They're great for maximizing the amount of available RAM to view websites. But unless you take steps to "harden" your system, and/or use web-browsers designed for privacy and/or security you may be compromising your system. Take the time to examine the Additional Software >Browsers Section for security oriented Browsers such as Ungoogle-Chromium, LibreWolf, or a properly configured Iron; for the discussions about addons/extensions which enhance privacy/security; clear cache often, always on closing; and, at least, consider running web-browsers as Spot.

Running Web-browsers as Spot: This thread explains the concept, benefits and limitations, viewtopic.php?p=1024#p1024. Depending on how the Web-brower was build or configured the Spot folder will either be /root/spot or /home/spot. If the application running as spot is, itself, locate within the Spot folder, to preserve any changes –new bookmarks, addons, etc-- a Save will be required. Cache files will also be in the Spot folder. As you don’t want to preserve them, you’ll want to delete them before executing a SAVE.
Spot's Downloads are a different story. They will be in the /spot/Downloads folder. The web-browsers which peebee publishes (and others using his technique) enable downloaded files to have root privileges. You can just move them. But the downloaded files using the web-browsers Mike Walsh publishes do not have root privileges. Mike has published a 'permission changer’ which not only moves files out of /Spot/Downloads, but changes their permissions. It can safely be used with any web-browser since the file you end up with has 'root-permissions' and is in your 'regular' Download folder. You can find a copy of the ‘permission changer’ at the bottom of this post. viewtopic.php?p=1024#p1024

Remember, you can set a Bookmark to any folder in any file-manager. Additionally, AFAIK, all recent Puppies using Rox as file-manager provide a “copy-to” function on the Right-Click menu. If you are going to do a lot of uploading with a Web-browser running as Spot, you may want to establish its Uploads folder as a Right-Click copy-to Location.

One other thing you might want to consider. Nic007 has published a Suite of useful apps, https://forum.puppylinux.com/viewtopic.php?f=106&t=1694. Among them is Save2SFS. Using it, you can store your changes in a READ-ONLY sfs. Thereafter, you can operate WITHOUT a SaveFile/Folder: an operating system almost invulnerable to malware; or with a very small SaveFile –perhaps just holding the instruction as to which SFS to load at bootup-- until you find some new application you just can’t live without. Then you can, again, create a new adrv or ydrv,

[williams2]

Then you can, again, create a SaveFile/Folder and again convert it into an adrv or ydrv

To be clear, you don't really need a savefile/folder to make an adrv/ydrv

The file system in a savefile would be mounted on /initrd/pup_rw/

If your Pup is running in ram, with no savefile, any changes will be made to the tmpfs file system in ram,
exactly the same way that a savefile works, mounted on exactly the same dir, /initrd/pup_rw/

I think save folders are also mounted on /initrd/pup_rw/, I've never used a save folder. I've never needed to.

So, whether you are using a save file or a save folder or ram only with no savefile/folder at all,
a remaster script to create an adrv/ydrv sfs should work.

Note, some Pups may have different names. For example, I think Fatdog uses /aufs instead of /initrd

For example, from my remaster script:

Code: Select all

rsync -av /initrd/pup_a/ /tmp/a1
rsync -av --exclude=.wh.* /initrd/pup_rw/ /tmp/a1
# ...
cd /tmp
mksquashfs a1 out.sfs

[mikeslr]

Hi william2,

Thanks for providing supplemental information. And especially thanks for the code example. As you know, I never claim to have any ability with computer languages beyond sometimes being able to follow their logic. And that often requires a good bit of googling for the significance of commands and arguments they can use.

As far as I can remember, this was the first time I’ve run across the ‘rsync’ command. [Coincidentally, shortly after reading your reply I stumbled into Barry K’s blog and discovered that he had used rsync in an "update" script]. Rsync – very powerful and efficient. In its absence, a lot more code seems to be required to accomplish the same objective.

And, of course, logic does suggest that the intermediate step of writing to a SaveFile, only to copy the contents to an adrv or ydrv is unnecessary. Unless, of course, you’re lazy or pressed for time. Both effort and time are required to capture every desired change into a remaster or modification. That suggests how important the efficiency of rysnc is to your approach.

[nic007]

The file system in a savefile would be mounted on /initrd/pup_rw/

Just a mention. If your savefile is on a flashdrive (or on harddrive and you boot with pfix=ataflash) the existing savefile is actually mounted at /initrd/pup_ro1 and the changes to the session (before saving again) at /initrd/pup_rw. So in this case if you save to an sfs file during a session, you need to save the contents of both /initrd/pup_ro1 and initrd/pup_rw. Of course - if you only want to replace your savefile/folder (or just save your changes if you do not have a savefile/folder) with an adrv/ydrv a full remaster is not necessary. This is where my Save2SFS tool (one of the tools in my suite) comes in handy. I have made that tool available to the community and is absolutely okay to use. Personally, I use my own refined saving script. My script saves the changes to an adrv, automatically names the adrv correctly, replaces the old adrv and backs up the new adrv to another location. Example:

Code: Select all

#!/bin/sh
. /etc/rc.d/PUPSTATE
. /etc/DISTRO_SPECS
ADRVSFS="$DISTRO_ADRVSFS"
WrkDir="/tmp/adrv"
NewAdrv="/mnt/$PDEV1/$PSUBDIR/$ADRVSFS"
BackupF="/mnt/$PDEV1/Backup/$ADRVSFS"
rm -r $WrkDir
wait
mkdir $WrkDir
cp -a /initrd/pup_a/* /initrd/pup_rw/*  $WrkDir
cd $WrkDir
rm -r ./etc ./tmp ./dev ./mnt ./initrd ./lib/modules/* ./lib/firmware/* ./usr/share/doc/* ./sys ./root/.wine/* ./root/.thumbnails/* ./root/.cache/* ./root/.Trash/* ./root/.XLOADED ./root/.pmusic ./var/log
alsactl --file /etc/asound.state store
cp -a /etc $WrkDir
rm $WrkDir/etc/.XLOADED  
rox -d $WrkDir
Xdialog -center -msgbox "Check and/or edit if necessary.  Click 'OK' when ready to proceed" 0 0
mksquashfs $WrkDir $NewAdrv -noappend -comp gzip
cp -a $NewAdrv $BackupF  
rox -D $WrkDir
rm -r $WrkDir
Xdialog -center -title "SUCCESS!!!"  --no-buttons -infobox "New $ADRVSFS created.  Exiting" 0 0 2000
   
exit

[williams2]

My Pup boots to ram only, no savefile, no drives mounted (pfix=ram).

It does not have Waterfox installed at all.

I installed Waterfox to /opt
I configured it the way I like.

Then I made a tar file of the waterfox dir in /opt
and a tar file of the Waterfox configuration files in /root/.waterfox/
and saved the tar files to my hard drive.

I can restore the Waterfox files from the tar files.
i wrote a simple script to restore and run Waterfox, like this:

Code: Select all

#!/bin/sh
notify-send -t 5000 "starting Waterfox ..."
rm -rf /root/.waterfox
rm -rf /root/.cache/waterfox
rm -rf /opt/waterfox
if ! test -f /opt/waterfox/waterfox
then
 echo -n 'unzipping Waterfox to /opt ... '
 tar -C /opt/ -xf /mnt/home/PUP1/waterfox.tar.gz
 tar -C /root/ -xf /mnt/home/PUP1/waterfoxcfg.tar.gz
 echo 'done'
fi
export LD_LIBRARY_PATH=/usr/lib/apulse:$LD_LIBRARY_PATH
test -z "$1" || exec /opt/waterfox/waterfox "$@" &>/dev/null
exec /opt/waterfox/waterfox file:///root/.links/bookmarks.html &>/dev/null

This script completely deletes all of the Waterfox files in /opt and all of the config files in /root/.waterfox and all of the files in /root/.cache/waterfox. So that every time I start Waterfox, it is exactly the way that it was the last time that I saved the tar files.

This is very similar to booting Puppy to ram, no savefile, with an adrv.sfs file.

You could make an sfs file of /opt/watefox and mount it on /opt/waterfox. That would use about 200mb less ram, and would make /opt/watefox read-only. Copying the Waterfox files to ram in /opt makes it easier to update to the latest version, and it runs a little faster.

Or you can install Waterfox then remaster the adrv.sfs file. Then every time Puppy boots, Waterfox will be installed and configured exactly the way it was when Puppy was last remastered. but Waterfox can change as it is being used. Running Waterfox from the script above starts Waterfox the exact same way each time it runs.

You can do the same thing with Firefox, of course.

[mikeslr]

Hi williams2,

I officially thanked you for your feedback using the widget, if that's what it's called. Nice feature on this forum. Makes life easier and probably conserves space.

If you get a chance, take a look at this post about creating AppImages. viewtopic.php?p=3250#p3250, I think the representations about mounting thru /tmp and its effect is correct.

I would also think that you could copy /opt/waterfox & /root/.waterfox/ into a folder that create-portable would package as an AppImage. Browsing to and Left-clicking the Appimage would start it, as would a simple bash-script. But note as fredx181, the author of Create Portable AppImage, posted, it doesn't always work. I don't recall trying it with web-browsers.

[charlie6]

Hi,
I resisted to open a new thread. My apologizes if the present post could seem far from this threads relevancy.
- Context: running Fossapup64-9.5 + fossapup64save-file.4fs file from a usb stick, PUPMODE=13, save interval=0, created using the embedded Menu/setup/StickPup;

- What happens: to save my session, before doing Menu/exit/shutdown, I NEED to click on the SAVE desktop icon to get my session saved; otherwise, when Xorg is out, the session cannot be longer saved (the default "60seconds timeout --> session not saved" applies by default); I have no possibility to select SAVE/NO SAVE at this step by using the TAB or arrows keyboards keys;
that «SAVE ...NO SAVE» dialog-box-on-blue-screen does not work as expected...as if the keyboard has no longer effect; the TAB, arrow left/right, ENTER keys do not respond.

- What I did:
1stly: search the Puppy forum about this;

2ndly: I tried to substitute the rc.shutdown from BionicPup (size 14K - which I know it for working on another usb-stick) into FossaPup (size 15K) without change; rc.shutdown seems no to be the "culprit".
There is indeed no such behaviour using that BioniPup-USB-stick on the very same hardware (desktop i5intel-PC+ usb keyboard).
To mention: both FossaPup64-9.5 and BionicPup64-8.0 use StickPup-v20.

3rdly: using the FossaPup64-usb-stick (as also the BioniPup-USB-stick) on another PC (intelCoreDuo-laptop): that «SAVE ...NO SAVE» dialog-box-on-blue-screen works OK.

- My question: whether does this to be a kernel-vs-hardware problem; or how to fix this?

Thanks anyway for your time and a very appreciated answer!
Best regards, Charlie

[user1111]

I boot a minimal linux system, around 5MB combined vmlinuz and initrd that boots busybox init. Just a few additional programs such as OpenSSH and wifi net connect support. The kernel is compiled to boot into a framebuffer cli system. That serves much of my needs, I ssh into a ssh server (hashbang) from where I have a tmux session with windows for irc, boards (including BBS's), mutt email ...etc.

For web browsing I can vnc through a ssh tunnel to a server (my old desktop system that is now connected to the main TV) to run a browser. i.e. on the server running ...

Code: Select all

#!/bin/sh
while :; do
	google-chrome-spot &
	CPID=$!
	sleep 5
	window_id=$(xwininfo -root -tree | grep google-chrome | grep spot | tail -n1 | sed "s/^[ \t]*//" | cut -d ' ' -f1)
	x11vnc -id $window_id -forever &
	XPID=$!
	wait $CPID
	kill $XPID
	sleep 5
done

keeps a chrome browser session available where I can fbvnc (framebuffer vnc) into that for browsing ...etc.

My minimal boot has the usb unplugged as soon at its booted (boots in just a second or two), and basically is just receiving framebuffer (screens) data from the server that are copied into the framebuffer (local display). The server session is a read only boot system, so each time the system reboots its all back to 'clean' again. The act of ssh from the client to that server with pre-set ssh keys is also a validation that there's no man-in-middle attack being deployed against you.

Like others, booting and not saving, using a pre-configured known 'clean/pristine' system is great IMO. Whenever I use other systems where all changes are preserved as and when they occur it almost gives me a cold shiver and throws thoughts to the front of mind such as 'this system could have been penetrated at any time in its past usage period'.

[williwaw]

My Pup boots to ram only, no savefile, no drives mounted (pfix=ram).

....Like others, booting and not saving, using a pre-configured known 'clean/pristine' system is great IMO. Whenever I use other systems where all changes are preserved as and when they occur it almost gives me a cold shiver and throws thoughts to the front of mind such as 'this system could have been penetrated at any time in its past usage period'.

Presuming that one runs a browser with a "static" configuration, and/or runs in ram or without persistence,

Are there any security reasons an outdated browser should not be used?

[user1111]

My Pup boots to ram only, no savefile, no drives mounted (pfix=ram).

....Like others, booting and not saving, using a pre-configured known 'clean/pristine' system is great IMO. Whenever I use other systems where all changes are preserved as and when they occur it almost gives me a cold shiver and throws thoughts to the front of mind such as 'this system could have been penetrated at any time in its past usage period'.

Presuming that one runs a browser with a "static" configuration, and/or runs in ram or without persistence,

Are there any security reasons an outdated browser should not be used?

Your running system may likely reveal keys/id's (wifi SSID and password used, ssh keys, servers keys...etc. 'preserved' somewhere during the session for ease/automation of reconnection), and/or reveal other LAN systems/devices, and/or have the capacity to low level mount drives to gain access to the boot loader or read only sfs - that can be modified to inject additional 'functionality'; And/or listen to LAN traffic; And/or provide a gateway to the router configuration ..etc. etc.

Fundamentally hacks exploit 'bugs' and older software versions will have widely known bugs. Once 'in' often a small daemon may be established that repeatedly initiates a 'what should I do/try next' loop back to the hackers server, feeding back the result of the last action and that with a appropriate database/automation may facilitate rapid permission elevation and spread.

ssh keys and known hosts ...etc. might be copied to their server for brute force cracking at their leisure.

If a system is hacked then that can be monetised to local interest. It can take relatively little information to establish identity theft that for the victim can lead to a decade+ of distress. If a 'crew' are provided with the approximate location for a known SSID and access password for instance then they might do all sorts of things with that, reconfigure the router to their advantage, 24/7 record LAN activities ...etc. ... to then analyse/exploit that however they might. Perhaps even something as simple as figuring out a 'good' time to burgle the home.

Simplicity is often the preferred choice. If for instance your neighbour hasn't changed their routers default userid/password and you have, then they are more inclined to become the victim. Open doors/windows attraction over closed doors/windows. Older browsers are similarly a attraction element. Many browser providers provide lists of past bugs and associated graded security risks - pretty much highlighting where hackers might investigate further in order to add additional 'functionality' to their databases.

That all said, don't lose sleep with worry, as competence is relatively rare. Of the honeypots I've run in the past, more often those that 'break-in' reveal pretty low levels of competence in their subsequent actions. The greater competence tends to use a much broader range of 'attack' methods - typically to gain sufficient data/personal-information to establish identify theft - that can lead to relatively rapid securing of thousands $$$'s - and then vanish leaving the victim to argue that it wasn't actually them.

[williwaw]

My Pup boots to ram only, no savefile, no drives mounted (pfix=ram).

It does not have Waterfox installed at all.

I installed Waterfox to /opt
I configured it the way I like.

Then I made a tar file of the waterfox dir in /opt
and a tar file of the Waterfox configuration files in /root/.waterfox/
and saved the tar files to my hard drive.

I can restore the Waterfox files from the tar files.
i wrote a simple script to restore and run Waterfox, like this:

Code: Select all

#!/bin/sh
notify-send -t 5000 "starting Waterfox ..."
rm -rf /root/.waterfox
rm -rf /root/.cache/waterfox
rm -rf /opt/waterfox
if ! test -f /opt/waterfox/waterfox
then
 echo -n 'unzipping Waterfox to /opt ... '
 tar -C /opt/ -xf /mnt/home/PUP1/waterfox.tar.gz
 tar -C /root/ -xf /mnt/home/PUP1/waterfoxcfg.tar.gz
 echo 'done'
fi
export LD_LIBRARY_PATH=/usr/lib/apulse:$LD_LIBRARY_PATH
test -z "$1" || exec /opt/waterfox/waterfox "$@" &>/dev/null
exec /opt/waterfox/waterfox file:///root/.links/bookmarks.html &>/dev/null

This script completely deletes all of the Waterfox files in /opt and all of the config files in /root/.waterfox and all of the files in /root/.cache/waterfox. So that every time I start Waterfox, it is exactly the way that it was the last time that I saved the tar files.

This is very similar to booting Puppy to ram, no savefile, with an adrv.sfs file.

You could make an sfs file of /opt/watefox and mount it on /opt/waterfox. That would use about 200mb less ram, and would make /opt/watefox read-only. Copying the Waterfox files to ram in /opt makes it easier to update to the latest version, and it runs a little faster.

Or you can install Waterfox then remaster the adrv.sfs file. Then every time Puppy boots, Waterfox will be installed and configured exactly the way it was when Puppy was last remastered. but Waterfox can change as it is being used. Running Waterfox from the script above starts Waterfox the exact same way each time it runs.

You can do the same thing with Firefox, of course.

@williams2
could you clarify the way you find it easiest to update?

Copying the Waterfox files to ram in /opt makes it easier to update to the latest version, and it runs a little faster.

(copying is neither untar or mounting a sfs)
thanks

[williams2]

copying is neither untar or mounting a sfs

cp is not rsync is not tar is not unsquashfs etc etc

Of course, you can copy files and dirs using tar:

Code: Select all

tar cf - * | (cd /tmp/ ; tar xpf -)

could you clarify the way you find it easiest to update?

I tar the dir containing the firefox executables, /opt/firefox/, to a tar archive file.
I tar the dir containing the firefox configuration files, /root/.mozilla/, to another tar archive file.

My FF start script deletes /opt/firefox/ and /root/.mozilla/ and /root/.cache/mozilla/
which deletes anything that might have been put in those dirs, whether malicious or not.

Then the FF start script untars (extracts or copies) the FF files in the tar archive files to /root/ and starts the FF executable.
So everything in the FF dirs is exactly as it was when I last tarred the FF files.

I run Puppy without a savefile, pfix=ram, so the save layer is a tmpfs file system in ram, so the FF files are untarred to ram.
So all I have to do to update FF to the latest version, is click OK when it automatically asks me if I want to update FF.
If I want to make the update permanent I need to tar the FF files again, but I just run a simple script to save the FF files to the tar archive.

I can mount a FF sfs file directly to a mountpoint like /opt/firefox/, but then files in /opt/firefox/ would then be all read-only, so to update firefox I would need to delete the mountpoint and extract the files from the sfs file, then run firefox from the now writable files in /opt/firefox/, then make a new sfs file. It's much easier to just run FF from the files in /opt/firefox/ that are in the tnpfs save layer and therefore writable.

When I boot Puppy, the system is a pristine copy of what was there when I last remastered it.
When I start FF, every time I start FF, FF is exactly as it was the last time I saved the FF files to the tar archive files.

[user1111]

Barry's EasyOS has a nice feature that uses the recent kernel lockdown addition. You can boot the main system, configure it as you like and then reboot into the lockdown mode where the HDD's aren't even visible, and any changes made are lost at shutdown, so you boot the exact same system time after time. To make changes, just reboot the main session again, make the changes and then revert to booting the lockdown choice again thereafter to 'see' the changes preserved.

kvm/qemu is another choice, where you can boot the same partition that you normally boot from, so for instance you see the exact same grub4dos menu.lst file etc. and where if you include the -snapshot qemu parameter then everything is read only, despite appearing to be rw whilst using it. Which even includes all of your HDD's So for instance if you have a sda4 with some data files on it, you can see/edit those, but at shutdown/reboot any changes made are lost. It uses copy on write (CoW) methods to do that, similar to the normal layered file-system that Puppy users are familiar with.

Fundamentally having a clean/pristine and configured as-you-like-it, is primary, as that way any virus/corruption that occurs during one session is simply wiped out via a reboot. If you store data separately and also use a layered approach to that, such as Fatdog's multi-session saving, then you have a audit trail of any changes to your data as well. Whilst you can merge both OS and data under the same single umbrella, generally its better to keep the two separate IMO as then the data is portable (can be accessed/used by whichever OS you prefer to boot at the time).

[user1111]

I did try using qemu to just boot single elements, such as a browser running on a dedicated browser only box, but found that it didn't work as well as booting the entire system. With single program qemu's menu drop-downs for instance showed as all black squares rather than showing the actual menu (menu was still 'there' i.e I could click where menu entries would otherwise normally show, and it functioned as normal). Likely that was just my incorrect configuration/use, but I couldn't figure out where I was going-wrong. With full system qemu's that problem doesn't show at all.

If you have a swap partition/file, I'm finding that having multiple concurrent full systems qemu sessions running works well.

s.jpg (121.02 KiB) Viewed 2323 times

Yes swap gets used, and there can be a delay when switching between one OS and another, but that lag is relatively small (a few seconds). At least that is the case on my 2 core 4GB laptop with fatdog booted and another fatdog qemu session along with tiny core and OpenBSD qemu sessions.

I'm using qemu serving vnc rather than directly to a X window, so other boxes can equally vnc into those. Or other boxes could be running qemu serving vnc and I can vnc into those. So with a spread of qemu sessions across a spread of boxes you could have many OS's all accessible concurrently. That's where ssh/sshfs comes in useful, i.e. for setting up file/folder sharing - such that rox-filer/whatever can just drag/drop files around (between systems). Personally however I prefer mc for that.

With kvm/qemu serving vnc, the server doesn't even have to have X running, it can be just a cli system (which can help with keeping more memory available for the qemu sessions that the server might be running). On the server (desktop system) I have connected to our TV, I have that serve vnc, so I can also access that from my laptop and/or phone, again concurrently. So for instance I can be viewing a mp4 on the TV and use a two finger swipe on my phone that's vnc'd into that, to raise/lower the volume. My sons can also remotely vnc into the server to 'take over' the display/control (useful for when my phone and laptop are off, as even when not viewing the desktop screen (viewing a regular TV channel), sounds can still be played to attract attention to get me to switch over to displaying the server).

[williwaw]

Barry's EasyOS has a nice feature that uses the recent kernel lockdown addition. You can boot the main system, configure it as you like and then reboot into the lockdown mode where the HDD's aren't even visible, and any changes made are lost at shutdown, so you boot the exact same system time after time. To make changes, just reboot the main session again, make the changes and then revert to booting the lockdown choice again thereafter to 'see' the changes preserved.

when running EasyOS in lockdown, there is now this on my desktop so I dont have to do the multiple reboots anymore.

Screenshot.png (11.65 KiB) Viewed 2301 times

[user1111]

Yes that's very neat. In the lockdown booted system no disks are shown/accessible, BUT if you attach a usb ... that does become visible, such that you can, as you say/indicate, run a save.

[williwaw]

BUT if you attach a usb ... that does become visible, such that you can, as you say/indicate, run a save.

Barry describes the functionality as such, when using (or possibly reinserting a usb), but when booting from a frugal install in lockdown mode, its always there, and seems to work when ever it's clicked.

[mikeslr]

It seems there's another approach worth considering. A couple days ago a newby posted a question about anti-viruses. So the question of security was on my mind when Mike Walsh published a new version of iron running in a chroot, viewtopic.php?p=19726#p19726
So I downloaded and sfs-loaded it.
Using it, iron runs from a top-level folder named cont. If I'm not mistaken, almost the entirety of the files from --IIRC-- tahr xenial 32-bit's puppy_tahrxenial.sfs [see Mike Walsh's post next following] are in the cont folder, including a subfolder named root. Downloads are to /root/Download but it's the one in the /cont folder. Any effort to download files outside of /cont appears to succeed but results in a failure as indicated by the following screenshot.

Download-Not-in-cont.png (21.67 KiB) Viewed 2142 times

.
Similarly, attempts to upload files from the other than 'cont' fail, as the web-browser's file-manager can not even see the file-system beyond its mount point at 'cont'.
rufwoof had indicated that one of the things to be concerned about was the ability of a potential hacker to see files beyond the contained environment and suggested that a possible test was to enter file:///sys/devices/virtual/dmi/id in the URL box. Doing that in the chrooted iron's URL box produced the following:

chrooted-iron.png (19.47 KiB) Viewed 2142 times

I don't know if this is a complete solution. But it seems to go a long way toward that.
If I'm not mistaken, running a web-browser in a chroot was published (IIRC, originally by watchdog or s243a again see Mike Walsh's post) as a 'Proof of Concept'. So no effort was made to remove unnecessary files from tahrXenial's main sfs; or to lock it down. With regard to the former --as I intend to link this post to the thread started by the above mentioned newbie and his computer may not be as robust as mine-- the follow information about resource usage may be of interest. It is part of a report by Pup-sysinfo with Iron-88-chroot running under Xenialpup (32bit) with a google search open to 20 high-resolution images.

Buffers: 123 MB
Cached: 1009 MB
Total Swap: 0 MB
Free Swap: 0 MB
Actual Used RAM: 213 MB Used - (buffers + cached)
Actual Free RAM: 15882 MB Free + (buffers + cached)
Linux Kernel: 4.14.63-rt37 (i686)
Kernel Version: #1 SMP PREEMPT RT Sun Sep 9 19:47:42 EDT 2018

Things to note: the kernel is a real-time kernel published by Sailor Enceladus rather than the stock kernel. The CPU is quad-core i5-3470 CPU @ 3.20GHz. These may lessen the need for RAM when effecting changes. And only one web-page (albeit a display of images meeting my search criteria) was open. Each additional tab/window is likely to require at least another 100 mbs of RAM.

[mikewalsh]

@mikeslr :-

FYI - in case you hadn't picked up on it - the 'chroot' Puppy is now Xenialpup 7.5. I upgraded from Tahr when it became apparent that it was starting to struggle with some of the requirements for the current 'clones'.

It may have been explored before I joined the community, I don't know.....but this was the moment when I first became interested in the 'chroot' concept:-

http://www.murga-linux.com/puppy/viewto ... 00#1034400

.....during the period when we were playing around with Darry's updated "Phoenix" 4.3.11. And this is when I first demo'ed the original Iron-chroot package, later in that same thread:-

http://www.murga-linux.com/puppy/viewto ... 64#1035264

That one had the 'standard' Iron browser package unzipped & manually installed. Later, when I was building the portables on a regular basis, it struck me that, with them being self-contained, using them in the 'chroot' package would make upgrading simpler. Which is what I've done ever since.

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

I still stand by what I said. Since you're running one Puppy inside another, these are not really suitable for Puppians still running 'traditional' Puppy boxes.....RAM-constrained, limited resources, etc; after all, you still need enough RAM for this to work properly.

I couldn't have done this with my older hardware; I just didn't have the resources. In my case, I was running the chroot from an externally-mounted partition; even so, things were a bit tight when I was running the browser. I didn't have a lot left to play with..!

As has been stated elsewhere, the general standard of Puppy hardware resources is steadily creeping upwards. Not many are still using really old machines with, say, 256 or 512 MB of RAM any longer. Most of us are blessed with multiple GB of RAM now. In m own case, I'm now as far from a traditional Puppy box as it's possible to get; 32 GB DDR4, a 9th-gen, "Coffee Lake", quad-core Pentium Gold, over 5 TB of storage......'future-proofing', to a large extent, while the readies have been there. And a discrete Nvidia GPU to round things off nicely.

Means I can still play around with lots of Puppies.....and as many applications as I feel like using!

Thanks for the 'testing', BTW. Useful results, and info. In most cases, individuals have to trim distros down a lot to make a 'chroot' viable; in our case, with Puppy being so small, there's no point. You just use the entire OS as-is.....

Mike.

[mikeslr]

Hi Mike,

You're right regarding the history of exploring chroot. Your work, watchdog's and darry's, on a chrooted iron predates by two years +/-, http://www.murga-linux.com/puppy/viewto ... 24#1034400 & the posts following the post my flaky memory sort of recalled, http://www.murga-linux.com/puppy/viewto ... 01#1053201.

Note the time of my post. It was getting late and I wanted to post the meat of my exploration before it became blurred. So, I skipped hunting for the originating posts and used the scapegoat "IIRC" --which anyone familiar with my posts knows implies a big IF. And you're mentioning upgrading the chroot to xenial sort of 'rings a bell' now.
Hunting for the 'origin' also turned up the post about sluggishness on low powered systems. I had kind-of recalled that. Which is why I provided the cautionary details about the system I was running.
I suspect what's involved is the actual effect of caching data which was copied into RAM. The 1009 MB my system reported as cached must be somewhere; and even if compressed it must still occupy some space and require some resources to compress, decompress and access in order to be used.
My exploration of stripping a Puppy of unneeded files suggests that it is essentially an exercise in futility, https://forum.puppylinux.com/viewtopic. ... sqtQ8cBu3I. But that exploration did not compare the over-all performance difference chrooting into a bare-bones system and one designed to do anything might have. Caching 1009 Mbs must have some effect. Perhaps only having to cache 500 Mbs would have less.

[user1111]

My Pup boots to ram only, no savefile, no drives mounted (pfix=ram).

....Like others, booting and not saving, using a pre-configured known 'clean/pristine' system is great IMO. Whenever I use other systems where all changes are preserved as and when they occur it almost gives me a cold shiver and throws thoughts to the front of mind such as 'this system could have been penetrated at any time in its past usage period'.

Presuming that one runs a browser with a "static" configuration, and/or runs in ram or without persistence,

Are there any security reasons an outdated browser should not be used?

Fundamentally, booting the exact same system where changes aren't preserved (but where that base can be safely modified to incorporate changes) is the ideal way IMO. Data and system separation. Where the system can even be a remote 'disposable' system. Nowadays for instance you can rent a 'virtual' box relatively inexpensively, and if set up to boot the same 'clean' system each time then more often that will have gigabit download/upload speeds and high end processing/display power - that can all be accessed/run remotely using a low power end system, where just the display and interface (mouse movements, key presses) are conveyed, and where you store your data. In effect the old terminal/server setup, but graphical rather than textual.

No need for virtual separation such as chroot, as there's physical separation which is more assured.

Under that setup it doesn't really matter what browser you run, as the risk it at the servers end, locally you just see what the server sees (display) and control it with the mouse/keyboard. Only stuff/data you actually transfer between the two might involve risk. Would still matter however if you booted the clean system and browsed around and had that being compromised before then also using it to go to your banks web site/wherever. But if your procedural process is to always 'reboot' into a clean session before going directly to the banks web site then more likely that would be a clean transaction.

A few months back I tried renting such a system however and the delivery date was August, around a 8 month wait time so I never actually bother to place a order. In truth, I don't really have the need for gigabit internet speeds and/or massive gui based processing power, so was more a toy than a need. And I already use such physically diversified processing for instance I can vnc into other boxes owned/controlled by me, or that are free such as tmux/ssh based (textual) which fills my needs. Great for leaving running in the background and later resuming from elsewhere or from different devices and is very much the original Unix distributed processing way of doing things.