Puppy Live CD with Non-Root user to prevent Browser Hijacking?

[Neo_78]

I am working in an environment where we frequently have issues with browser hijacking; i.e. an infected URL is visited and an attacker gains access to the browser in order to execute malicious JavaScript.

Is it possible to run Puppy Linux from a Live-CD without installation with a non-root user and to also run the web browser (ideally latest versions of Chrome or Firefox) as a non-root user?

I would also have to be able to install browser extensions under that setup.

The idea is then to boot every time from a fresh, uninfected system.

Appreciate your feedback.

[dancytron]

There is an experimental way to run Puppy as a non-root user, but it's really a one user system.

You should look at Debian Dog or Fat Dog if running the main OS as a different user is a requirement. They are both Puppy-like but true multi-user systems.

All modern Puppies let you run your browser as "spot", a very restricted non-root user.

[mikeslr]

The simple answer is, "Yes". There's an easy way, and a better way.
The easy way: Most Puppys can be burned to a CD: you'll have to ask how with respect to some newer one. But before burning them you'll want to remaster so that your web-browser is among the files within your READ-ONLY media. Some web-browsers you'll find on the Additional Software Forum, viewforum.php?f=90 are configured to 'run-as-spot', a limited User who has no access to folders other than its own. Other web-browsers, which OOTB run as /root, can be configured to run-as-spot. Any web-browser available as a 'portable' can be located in /opt. Remastering will put them in READ-ONLY media. But, before remastering, you'll probably want to install MikeWalsh's spot2root application so that you can get the things you want out of the Spot folder. Remastering applications are discussed below.

The better way: There are several possibilities, they enable running secure operating systems with secure web-browsers from either a USB-Key, or even (less secure) a hard-drive. I have no personal knowledge of burning them to CD/DVD.
Explorations discussed on this Forum indicate that while 'running as spot' is as effective as the use of firejails under other operating systems, both can potentially be evaded. [The best work-around is to frequently reboot: Puppys 'run-in-RAM'; rebooting clears RAM; so any infestation gets wiped and their components can't reach a stage where they can be assembled].

puli, viewtopic.php?t=484 can be booted from a USB-Key, and the Key then unplugged. It is unique among Puppys as it also provides modules for detecting attempts to infiltrate and provides counter-measures. Read all the links from that post and the thread which follows.

EasyOS, viewtopic.php?p=45044#p45044 runs Web-browsers, other applications, and even other operating systems in containers. Containerized applications have no access to the rest of your system. A great deal more information can be found here, viewforum.php?f=63

A Frugal Puppy operates in RAM, reading into RAM the contents of READ-ONLY files on storage, with one exception: the SaveFile/Folder you create to hold customizations, settings and user-installed applications. That exception can be avoided by employing the Save2SFS module of nicOS-Utility-Suite, viewtopic.php?t=1694. It will create either an adrv or a ydrv, or both; and both being READ-ONLY. It will 'capture' the contents of your SaveFile/Folder and/or the changes you've made but haven't yet Saved. After creating either or both adrv or ydrv, you discontinue use of a SaveFile/Folder. If your Puppy is on a USB-Key, after it boots to desktop you can remove the USB-Key. Hard to infect something which isn't there.

Of course, to make changes or add additional applications you'll have to plug the USB-Key in again. [The same is true of Puli]. Best to reboot before making such changes and making the changes before going online. Re-booting clears RAM of anything which might be present. Of course, before rebooting you'll want to have downloaded any packages you want, and only from trusted locations checking, where possible, their integrity using Menu>Utility>GtkHash.

My personal favorite is to run another operating system in a Chroot. Details and instructions for creating them are provided here, viewtopic.php?p=33971#p33971. As the first paragraph of that post states: "Why a Chroot? Because unlike other isolation mechanisms any Puppy can use it." I should have added, and any Puppy can be used to create the Chrooted operating system.

The Chroot.sfs, itself, is a READ-ONLY system. In theory, a Chrooted operating system is slightly less secure than Puli or EasyOS. Although your media remains mounted, it is virtually impossible for a hacker infiltrating via a Web-browser running from the Chroot to escape the Chroot into your actual operating system. [SFS-loading the Chroot.sfs from a partition different from that of your Puppy's system files adds another layer of protection: It's partition is mounted, but your operating system's partition is not]. However, it is also more flexible. If you need any special application to be within the Chrooted operating system, then before making use of its core/base system to created the Chroot.SFS, you can run that Puppy as an operating system, install that application and Remaster. There's a remaster module in the nicOS-Utility-Suite; and two others amethyst provided from the link noted above. They all work well and easily.

[rockedge]

VoidPup32 can be run as a true multi-user PAM system though still in an alpha stage of development. I think @wiak was able to set it up and login as a true non-root user.

[williwaw]

there are a number of possibilities that might work for you.

easyOS has containers
pretty much everything in the kennels can run in ram, whether from cd or usb
if rebooting, your can choose to reload as pristine with out changes having been saved

why do you need multi user capabilities if rebooting fresh? just curious, as that requirement might be redundant

[JASpup]

There are two non-root users, Spot and Fido.

I'm in Spot right now. Note the tick box when Quick Setup loads at boot.

You can also enter Spot manually when started as root.

[mikewalsh]

I will just add here that the one disadvantage of including any up-to-date browser in a re-master is that the browser doesn't remain up-to-date for very long!

Since a re-master is making the entire thing "read-only" (because of the ISO9660 file-system used in ISOs), you cannot keep the browser up-to-date.....the update will not "stick". As soon as you shut-down/reboot, the RAM is cleared and your changes with it.....and since you want to be running with a fresh, pristine OS every time, you cannot risk creating a save-file/folder.....

(*shrug*)

It's a bit of a chicken-and-egg situation. T'other Mike's reference to Nic's utility for creating/re-building adrvs & ydrvs might be the only way round this, since those files are re-created "read-only" every time changes are saved.

If you don't need Google services - like sync, etc - I'd recommend running my Ungoogled-Chromium-portable from a flash drive along with your 'Live' Puppy; this prompts you to clear the cache every time at shutdown, since Ungoogled Chromium won't do this OOTB. You can find it here:-

viewtopic.php?t=1499

Just a thought.

Mike.

[Feek]

I will just add here that the one disadvantage of including any up-to-date browser in a re-master is that the browser doesn't remain up-to-date for very long!

Since a re-master is making the entire thing "read-only" (because of the ISO9660 file-system used in ISOs), you cannot keep the browser up-to-date.....the update will not "stick". As soon as you shut-down/reboot, the RAM is cleared and your changes with it.....and since you want to be running with a fresh, pristine OS every time, you cannot risk creating a save-file/folder.....

(*shrug*)

It's a bit of a chicken-and-egg situation. T'other Mike's reference to Nic's utility for creating/re-building adrvs & ydrvs might be the only way round this, since those files are re-created "read-only" every time changes are saved.

If you don't need Google services - like sync, etc - I'd recommend running my Ungoogled-Chromium-portable from a flash drive along with your 'Live' Puppy; this prompts you to clear the cache every time at shutdown, since Ungoogled Chromium won't do this OOTB. You can find it here:-

viewtopic.php?t=1499

Just a thought.

Mike.

Mike, I'm not a Tech-Expert.
I experimented with "read-only" Puppy/dog systems and nowadays I use them as my main OS.
Here is my little experience:

when I started with Puppy I burned the .iso of Bionicpup64 to a CD. After boot and basic settings (wifi etc.)
I was able to update the built-in Palemoon browser successfully (then Palemoon stated that I'm using the latest version).

Now I use (not only) Bionicpup64 booting from harddrive without save (pfix=ram) with Firefox (installed from Quickpet).
The savefolder (with updated Firefox) was converted into adrv about half a year ago.
Firefox has its "one-click" built-in updater (settings->help->about Firefox).
The update of Firefox before use (beginning of each session) works fine even after half a year and doesn't take long.

So I think that it is possible to have up-to-date browser in read-only system without need to do remastering every time.
(I have no experience with Chromium-based browsers in this regard)

[mikeslr]

Nice tip, Feek, about updating firefox READ-ONLY each time. I hadn't thought of that. Does the up-date require a Menu>Exit>Restart-X to be effective?
I'm not sure about MikeWalsh's recent 'Chromium-Clones'. [Still working on my first cup of coffee: have a vague recollection that some newer versions may update. But that may be wishful thinking. And, wanting to keep this short, I'm not going to search to make certain].

Iron is my favorite among the Chromium-Clones; its OOTB configuration setting are almost identical to Ungoogled Chromium. But Iron is easier to customize. As far as I know it doesn't update. It also is somewhat slow about publishing new versions.
I mentioned that nicOS-Utility-Suite's Save2SFS can create either an adrv or a ydrv or both. Here's the difference: if you create a ydrv it capture's the adrv. So what I do is replace the SaveFile/Folder with a ydrv. Then setup Iron-portable in /opt and create an adrv. To update, I copy the profile folder --containing extensions-- from the old to the new Iron folder; delete the old iron folder and replace it with a new iron folder having exactly the same name: then run Save2SFS creating a new adrv. Doesn't take very long.

I also want to correct a mis-statement I made. AFAIK, a Chrooted web-browser is as secure as a containerized one. But it's not as good at maintaining privacy as EasyOS. The Chrooted operating system still uses your computer's specifications --enabling 'finger-printing'. BarryK's module for creating containerized OSes avoids that.
To achieve both security and privacy, I configure web-browsers as I spelled out here: viewtopic.php?t=2335. Although that post was about firefox, many of the same configurations and add-ons are available under 'Chromiums' or, if not, there will be equivalents. The following is a screenshot of those extensions I currently have in Iron. Most work automatically, so don't have to be 'pinned' taking up space in the toolbar.

Chrome-Extensions.png (113.97 KiB) Viewed 2854 times

Note the Undo closed tab extension. OOTB, Iron doesn't have that.

[Feek]

mikeslr,
a certain time ago I read some posts (btw. many of them were from you) about running a Puppy completely in ram (without save).
I was thinking about many aspects about how it could work.
One of the aspects was how to update a browser.

I thought that the updating of the browser in ram is well known among the puppy users.

The update does not require a Menu>Exit>Restart-X.
Only the restart of the browser is required (user is asked to do it immediatelly after the update).

The above works for me with Palemoon (built-in) and Firefox (installed from Quickpet).

Btw., I never tried Iron browser but your review about it looks good.

[Neo_78]

I really appreciate your detailed input and ideas on this topic. I have to admit that I am surprised how friendly and helpful the Puppy Linux community is.

To provide a little bit more background:

I am currently running a Ubuntu derivate as a virtual machine (Virtualbox) on a Ubuntu host and I use a non-root account for work. Non-root because if the attacker gets into the account at least permissions are quiet limited and I think that is also the general security consesus in the Linux community that a non-root user should be used when connecting to the Internet. At least it will create more work for the attacker. So in this way I can start work with a fresh system every morning (in theory). Unfortunately, the attacker is able to escape the VM and infect the host machine using the browser as an initial attack vector. Using a decent hardware firewall limits the attacker to a certain extent, but will still allow some malicious activities in the browser. The older the browser version, the better the possibilities for the attacker, which is my experience.

On that basis, I would like to use a read-only system that allows me to boot a fresh, uninfected OS every morning with a sufficiently up-to-date browser (Firefox, Chrome or Edge), no hard drive connected. I would have to be able to install the extensions ublock and noscript. There is no need to save any files or configurations. I want to make it impossible to modify and root the OS. I was under the impression that a CD would be safer than a USB-stick, because it would be much more difficult to corrupt the data. I don't mind creating a new image every month to get an up-to-date browser version if a live update feature is not possible.

Based on this use case scenario, which of the mentioned solutions would you recommend?

[rockedge]

I would set up the Puppy with the newest Firefox (for example) and then remaster it. Once remastered burn a CD-ROM that is finalized after the burn.

Boot every time from the CD-ROM and use no save file or folder. You will be able to update Firefox from the the internal menu and with a simple browser restart. No need to reboot, but then you will need to remaster and burn a new CD-ROM (or DVD) to preserve the updated firefox. You do not need to go through every update and save them with a new remaster, only updating when a major version change occurs should suffice.

This is a very safe system, but a little old fashioned. Another option is to use a "portable" browser from a system booted from an ISO directly.

Another possibility is using SFS-Load-on-the-fly to always use the latest browser provided in a squash file form and again boot the OS from a read only CD-ROM or ISO file directly.

There are other variations that could be considered, but for ease of use and reliablity the above should be easy to automate or run manually on a regular basis.

[Neo_78]

Is there a guide how to remaster and then burn the image to a CD?

I basically downloaded FossaPup64 9.5 and burned a Live CD. Is it possible to remaster from that Live CD and then burn a new CD?

[rockedge]

Yes it is possible.

Boot from the CD and then reboot and create a save folder. This is temporary.
Once the system is re-booted setup the Fossapup64 the way you want it. Add in (as an example) Firefox and what ever desktop customization's you've made.

There are remastering and disk burning tools already present in Fossapup64 which can be found in the menus.

Start the remastering program and follow the prompts which will guide you along. Also there is a wealth of information on this forum and the old forum all about remastering. A good search tool is https://psearch.puppylinux.com for finding information across both forums, new and old(er).

once the ISO is finished burn this onto a CD-ROM (or DVD) and boot this system. Then simply delete anything left over from the remastering that isn't the new ISO from the any HDD's

This a really rough outline, if you run into difficulties post again here what questions you may have, and we'll help get this done. And that you can do it again as you progress refining the system you want.

[mikeslr]

I really appreciate your detailed input and ideas on this topic. I have to admit that I am surprised how friendly and helpful the Puppy Linux community is.

To provide a little bit more background:

I am currently running a Ubuntu derivate as a virtual machine (Virtualbox) on a Ubuntu host and I use a non-root account for work. Non-root because if the attacker gets into the account at least permissions are quiet limited and I think that is also the general security consesus in the Linux community that a non-root user should be used when connecting to the Internet. At least it will create more work for the attacker. So in this way I can start work with a fresh system every morning (in theory). Unfortunately, the attacker is able to escape the VM and infect the host machine using the browser as an initial attack vector. Using a decent hardware firewall limits the attacker to a certain extent, but will still allow some malicious activities in the browser. The older the browser version, the better the possibilities for the attacker, which is my experience. Emphasis added.

On that basis, I would like to use a read-only system that allows me to boot a fresh, uninfected OS every morning with a sufficiently up-to-date browser (Firefox, Chrome or Edge), no hard drive connected. I would have to be able to install the extensions ublock and noscript. There is no need to save any files or configurations. I want to make it impossible to modify and root the OS. I was under the impression that a CD would be safer than a USB-stick, because it would be much more difficult to corrupt the data. I don't mind creating a new image every month to get an up-to-date browser version if a live update feature is not possible.

Based on this use case scenario, which of the mentioned solutions would you recommend?

“Unfortunately, the attacker is able to escape the VM and infect the host machine using the browser as an initial attack vector.” As this seems to have happened multiple time, the possibility of ‘an inside job’ can’t be ruled out. And as the browser is the vector of the attacks, you also have to consider that your current system is already compromised: any information you send or receive using that system will be known to the attacker.

Rockedge’s approach will certainly work. But there are a couple of ‘system problems’ you may or may not have considered.

In passing let me make a note of why Linux generally frowns on ‘running as Root/Adminstrator’. Most Linux systems are designed as a ‘Unity’, constantly reading from and writing to the media on which they boot from. To achieve security, they originally granted Users limited privileges which can be ‘elevated’ only if you give the password. [IMHO, pretty weak once a keylogger employing blue-tooth or wifi captures your passwords]. Firejails were devised to provide an additional measure of security: an application run via a firejail supposedly can’t escape it. But, as I mentioned, exploration on this forum suggests that firejails are no more, nor less, effective as running applications under Puppys ‘as spot’; ‘spot’ being a User whose access is limited to its own folder and whose privilege is limited to the applications within that folder. Neither ‘spot’ nor firejails will prevent a hacker from knowing and or corrupting the information received. And both their restrictions can be overcome.
The primary security provided by Puppys is that they can be configured to never access –or need to access-- the storage media from which their READ-ONLY files are read on boot-up. Although a hacker can’t corrupt READ-Only files, with Root privileges –whether or not a password is needed to use them-- a hacker can ‘wipe’ an entire system from a computer’s hard-drive. However, an unplugged USB-Key is just as immutable as a READ-ONLY CD/DVD.

Once elevated to root status, everything on a computer is ‘fair game’ as hard-drives and partitions can be mounted. Only an operating system employing containers or a chrooted operating system provide appear to be able to prevent such mounting. Xephyr, mentioned below, can provide containerization to an operating system. And as I mentioned previously, Puppys run in RAM; and clearing RAM often can prevent malware from being assembled even in RAM.

In other words, the steps you would take to protect an operating system may not be sufficient to protect the computers they run from.

Your operating system on a CD/DVD will certainly not be Write-able. The same, however, is true of systems written to USB-Keys using several of the common ‘USB-Burners’. These will format the USB-Key as a READ-ONLY ISO9660 device. https://wiki.osdev.org/ISO_9660.

[We know about that because USUALLY, we want to avoid that; to have some means by which we can savce settings, customisations, and install other applications into our operating systems. See, for example, my post about using rufus under Windows, viewtopic.php?p=40522#p40522. The “dd” command will do that under AFAIK any Linux operating system; but may first require the installation of some libraries. https://linuxhint.com/make-disk-images- ... and-linux/; https://www.geeksforgeeks.org/dd-command-linux/. We’ve made the use of ‘dd’ simple under Puppys: bigpup published a pet, viewtopic.php?p=11559#p11559 and MikeWalsh a portable, with graphics and instructions, https://oldforum.puppylinux.com/viewtop ... 1#p1031161.

With your network potentially compromised, and the information we provide here potentially known by your hacker I would suggest that you create a CD/DVD or USB-Key on a computer which you have reason to believe is (a) not part of that network; and (b) not potentially compromised. If necessary, EasyDD can be used to duplicate that product.

Once you have that product, you’ll have another obstacle: how to get information into and out of it on while using a compromise network.

The Puppy I would use to create my system is Puli, for a couple reasons beyond that it includes intrusion detection with counter-measures. The latest version of Puli is a remastered Bionicpup64. That means any application which runs under Bionicpup64 –any application not already builtin-- can be included in a Puli system by creating an adrv.sfs or ydrv.sfs, both READ-ONLY. See my ‘Unorthodox’ instructions here, viewtopic.php?p=32145#p32145. [You can also swap Puli’s kernels to the latest available to Puppys, which include patches and mitigations against known malware]. And Bionicpup64, thus Puli, can use the latest versions of both firefox and chromium(‘google-chrome’/clones) such as Ungoogle-Chromium and SWIron. It can also use OscarTalk’ VPN-ONOFF with any VPN server offering the openvpn system. Once you’ve booted to desktop you can –are supposed to-- unplug the USB-Key it booted from. Even if you don’t ALL drives and their partitions are Unmounted, and can NOT be mounted, while you are online. Puli also offers a version of Xephyr which –if I read this post correctly-- can run web-browsers in a ‘sandbox’ environment, viewtopic.php?p=19463#p19463: doubly 'sandbox' if run-as-spot.

The problem with Puli is getting information out of it. Once you are ‘off-line’ drives/partitions can be mounted. The one you mount should NOT be the one on which your system is located. I’d go either ‘old-school’ or ‘new-school’. In the same ‘Sandbox’ I’d include both a browser and an encryption application such as pzip. Each person needing to receive information would have his or her own password; only you would have knowledge of all. Once off-line you could encrypt information to be transmitted and either write it to a 2nd USB-Key –not the one from which your system booted-- to be hand-delivered; or uploaded to an email address –such as Proton’s-- via VPN: an encrypted message over an encrypted system. ProtonVPN offers both free and paid versions. And there are others reputable providers. But be careful with other ‘Free VPN providers’. Read the ‘fine’ print. Many have compromised nodes thru which information passes. I’d be especially leery about Opera’s free VPN considering who now has a substantial financial stake in that company.

p.s. Puli provides xvkdb --a virtual keyboard operated with mouse-clicks-- to deter key-logging. That application, however, can be installed into any Puppy.

[Neo_78]

I am currently using a mobile device with a mobile connection, which is not part of the local network. So I don't think that the attacker is aware of this post. The Puppy images will be created on a laptop, which is also never connected to that network. I keep the work machine always separate and consider it permanently infected despite shredding the hard drives. I also have the local router formatted after each incident by my ISP, just in case. Unfortunately, the ISP does not allow local access to the router. I cannot go into details, but the whole thing started in the Covid crisis when everyone started to work remotely and our systems department was outsourced offshore. So after testing and observing the attackers behaviour, there is no doubt that this is an inside job. Welcome to the new shiny world of the home office...

I am not too technical, but I will try to create CDs with both the remastering solution and Puli.

Regarding the "easy" remastering solution:

Will an attacker not be able to wipe the RAM and shut down the system as standard Puppy is run as root although a non-writeable Live CD is used?

I really appreciate everyones help and input.

Thanks, guys.

[rockedge]

Will an attacker not be able to wipe the RAM and shut down the system as standard Puppy is run as root although a non-writable Live CD is used?

What would the attacker gain by attempting to wipe the RAM? Does the attack vector include crashing the system? What are the apparent goals of the attack? Unless the hacker had direct physical access to the machine running this Puppy Linux it would be difficult to flush the RAM if not impossible.

Please feel free to ask if you need more help or more detailed instructions. We can help you get through the steps until you are comfortable completing them. Get you to a point where you can understand exactly what you need to do to run the steps and possibly improve your counter attack as you begin to use what you've built.

Further details of system construction can be discussed via private messages on this forum if needed.

[Neo_78]

Malicious, destructive behaviour seems to be the primary goal. Before I had a dedicated firewall, the attacker was able to overload and crash the system and disable the network adapter. Before using a VM, I also had an instance where reboot was not possible, so I guess the system was wiped or modified. Physical access to the system is not possible for the attacker.

[rockedge]

So there was modification done to prevent reboot like destruction of the systems BIOS or UEFI system from a remote location?

[Neo_78]

I don't think the BIOS was modified, but I also cannot exclude it. I had the BIOS flashed to the latest version just in case. I am always using Ubuntu's disc encryption feature and I was not able to unlock the disc and boot after that incidence despite the correct password. I also noticed that the system logs were wiped. Correct, this is a remote attack. Using a VM with a non-root account and a hardware firewall seems to prevent that behaviour.

[Feek]

Just a thought.
You wrote in the first post of this thread:

issues with browser hijacking; i.e. an infected URL is visited and an attacker gains access to the browser in order to execute malicious JavaScript.

AFAIK, any specific URL(s) can be blocked on the level of the operating system.
Whatever URL is placed in "/etc/hosts" file, this URL can not access the operating system (browser).
If you know what specific URL caused your situation, you can block it this way.

Fossapup64 has its own PupAdvertBlocker built-in (working on the same princip).
You can find it in the menu and you can simply activate it.
But I don't know if the list of the URLs is up-to-date here.

I use StevenBlack hosts from github (the author updates it regularly).
Applying this, browsing should be faster (adverts are not loaded) and some known potentially harmful websites should be blocked.
I apply it manually with this script:

Code: Select all

#!/bin/sh
mv /etc/hosts /etc/hosts.default
wget -O /etc/hosts https://github.com/StevenBlack/hosts/blob/master/hosts?raw=true
geany /etc/hosts

It will download the up-to-date list, place it into /etc/hosts and show its content in Geany.
The script also will backup the original file, so it can be restored to the original state with this script:

Code: Select all

#!/bin/sh
mv /etc/hosts.default /etc/hosts
geany /etc/hosts

[Neo_78]

URL blocking at OS level is a good idea. The problem in this case is that the attacker is using a company-internal information system that is accessed via the web browser. They used to share infected Google Workspace documents and PDFs and now moved to URLs in a CRM. And those URLs have to be accessed in order to work in a meaningful way. Under normal circumstances you can block a domain with a browser extension like NoScript. However, if you disable JavaScript or block the domain, the system is not accessible. Someone inside the organisation is facilitating the first step of the attack, but I assume that the attacking host server that is used afterwards in order to control the infected client systems is an outside IP. If there would be a way to identify the attacking IP, a solution might be to block it.

[mikeslr]

"Will an attacker not be able to wipe the RAM and shut down the system as standard Puppy is run as root although a non-writeable Live CD is used?"

I think the best solution would be the use of Xephyr to start the web-browser. I mentioned Xephyr and its availability under Puli in my prior post. But, as I often mentioned, I have the technical expertise of a 6 year old playing with blocks. I may know, or can find out, what those blocks can do. But scripting --the ability to build and configure those blocks from scratch-- 'not so much'. rufwoof and s243a have provided most of the information about configuring and using Xephyr, and that under FatDog, so might require 'tweaking' for Puppys [use https://rockedge.org/psearch/ to find their posts]. But TBH, it would take me hours to internalize the terms used to the point I could visualize what was taking place. And a couple days later it would again be a blur.

On the other hand, actually creating a chrooted operating system from which a web-browser can run is relatively easy. I've detailed how here, viewtopic.php?p=33971#p33971.

[Will have to look for it when I have more time: a couple years ago MikeWalsh published as an SFS Google-Chrome to run-as-spot from /home/spot. Basically, the entire GC folder was located there, with only those files necessary to create a menu entry elsewhere. That entire folder and anything downloaded into it lacked 'root' permissions. Applications in the home/spot folder could not make use of files with 'root' permissions. And 'Root' could not use files with 'spot's' permissions. Along with the SFS, Mike published an application known as 'spot2root' which the root user could run to get files into/out /home/spot changing permissions during the transfer. I've used his technique to construct other web-browsers that way, and think I've published a recipe].

So what that would give you is a chrooted operating system with a web-brower running as spot from its /mnt/home. Its spot2root would change permissions, but still have downloaded files in the chrooted OS's /root/download folder. From there, (turning on 'show hidden files') you could pick what you choose to move to your actual operating system's folders. As the entire Chrooted-OS exists only in RAM, rebooting clears anything not moved.
I mentioned here, viewtopic.php?p=36685&hilit=chroot+wine#p36685 "Although the Chroot appears to be isolated, that may not be entirely true. pmount doesn’t work; but terminal applications within the Chroot do. At least in theory, a hacker may be able to ‘escape’ the Chroot."

But what would happen if before remastering the Chroot OS you deleted all terminal applications? I could be wrong, but I doubt that the permissions of anything running as spot can be elevated to root in the absence of a terminal applications itself running as root.
Would the web-browser still run? And delete rox? and any other part of the Chroot-OS's infra-structure not needed to run web-browsers?

[rockedge]

Someone inside the organisation is facilitating the first step of the attack, but I assume that the attacking host server that is used afterwards in order to control the infected client systems is an outside IP

Can you please describe what you can about the first step of the attack. What is the insider enabling or providing?

What web server is being used for the CMS?

[Neo_78]

I have sent a PM.

Thanks.

[mikeslr]

It occurred to me that it wouldn't take long for me to set up a test to answer the questions I last posed, basically: If before the folder containing the operating system and the web-browser(s) is dir2sfs to create an adrv/ydrv. sfs providing web-browsers in a chroot terminals, text editors and other undesirable applications were removed from that folder would the browser(s) still function?

I already have a chrooted_browser.sfs which can be used to run its contained web-browsers (Iron and firefox-esr). It can be mounted, its contents copied into a new folder, and applications deleted before repackaging. It's chrooted operating system is Xenialpup64. Starting from scratch, today, I would use Fossapup64 as the base. The web-browsers are not the latest versions and are located in /opt and not run as spot from /home. But it should suffice to answer the first question 'will the browsers function if terminals are removed from the chrooted-OS'?

But I have a couple of personally important things to do first. I'll let you know how it goes later in the day.

[Neo_78]

Thanks for the feedback.

I am trying to remaster a Fossapup 9.5 Live CD for the first time and have couple of questions (excuse my ignorance):

- Which option do I need to choose during the initial boot option menu?

- I checked the package manager but could only find relatively old browser versions, e.g. Firefox 79. Where do I find more recent browser versions for installation?

- There seem to be quiet many applications that I do not need. I would like the system to be as slim as possible to give potential attackers less possibilities. What is the recommended way to uninstall software?

- Once I have installed and configured the system to my liking, I can then use the "Remaster Puppy live-CD" tool to create a new CD, correct?

[mikeslr]

The builtin remaster will only cause confusion. Use one of the remasters here to remaster. viewtopic.php?t=1694. You can use Menu>Setup>Remove Builtins to 'remove builtins' before remastering. [It doesn't really remove them from the READ-ONLY files on storage. What happens is it writes a 'whiteout' file in your SaveFile/Folder so that during remaster the links to the 'removed' file are not follow and they don't make it into the remaster.
But, I wouldn't bother. Anything you remove can be re-installed by your hacker if (s)he can gain access to your MainOS even if the hacker has to re-install it each time. Other reasons for removing built-ins are, essentially, exercises in futility. viewtopic.php?p=4070#p4070. If Fossapup is to be your MainOS I recommend just using Menu>Setup>Menu Manager to turn off the display of unwanted applications on the Menu.

If Fossapup is to serve as the base for the Chrooted OS, you'll want to remove applications in it in a different way. Most of what you'll want to remove are applications which are, or probably are, needed to remaster or even run that system on its own.

As I wrote previously, I explored the possibility of running Web-browsers from a Chrooted OS after removing terminals, editors, and pretty much else I thought could be dangerous or annoying if available to a hacker. Both Iron and firefox-esr functioned. [I forgot to check if it could download/upload files. ]. As I previously mentioned, they could not escape the chroot. It could see files, open some in a text-viewer (I hadn't removed that) but could not edit them. It could not start any other application.

The basic formula for setting up any application in a chrooted OS is detailed here, viewtopic.php?t=3721. You could use the puppy_fossa64_9.5.sfs as the chrooted OS. Left-Click, to mount it, click Rox's Eye to show hidden files, Ctrl-A to select all and drag them into the '/cont folder. To remove files/applications do the following:
Open two File-browser windows to /cont. Use the 1st rox window to file-browse to /cont/usr/share/applications. You can delete the desktop files, after which there won't be a menu display. But before doing that Right-Click the desktop file, open in a text editor and copy the argument following Exec= into pfind (see below). That way you get to delete not only the display, but the application. [Config & icons will remain; but who cares].

In the other Rox window Right-Click an empty space and select Windows> Shell Command. Then enter the command pfind. When the pfind application opens click the "Current Directory" button: Current Directory is recursive; child directories will also be searched. When pfind locates a file you can select it and delete it. Sometimes it will require the 'delete' option twice, complaining about multiple selections the first time. Folders can't be deleted using pfind. You'll have to file browse to them, left-click and select delete. [Maybe a 3rd rox window would be helpful].
A lot of what got deleted had been in /usr/local/apps, /usr/local/bin and /usr/sbin. Puppys make use of a lot of rox-apps and the first two folders relate to them. [I wonder if just deleting those folders would (a) be sufficient and (b) leave a OS which could still support the web-browsers. /usr/sbin contains applications &/or configuration files pertaining to firmware.
My objective was to remove anything which could write, anything which could be used to transmit information out of your computer, and any which could alter your settings (if for no other reason than to create an annoyance]. And, as I wrote, after I finished I was still able to open the browsers in the chroot.
Edit:

cat.jpg (19.54 KiB) Viewed 2450 times

The above photo shows the successful test of whether the chrooted firefox could both download and upload.
@ Neo_78, check your email.

[rockedge]

What I would do:
Step 1. download a Fossapup64 ISO and burn it to disk.
Step 2. boot the disk

Step 3. use the browser provided and download the official Firefox for Linux -> firefox-95.0.2.tar.bz2
Then extract the contents to /opt
a firefox.desktop file needs to be placed or created in /usr/share/applications

Step 4. Test out FireFox. If it runs okay start the remaster process.

This will provide in the new Fossapup64 ISO a Firefox that can update but when Fossapup64 is run in RAM with no savefile or savefolder the updates will not remain persistent.

If a Firefox update should remain. simply remaster immediately after updating Firefox.

Step 5. Once the remaster is finished and burned, test it out with a boot. Once running un-mount and eject the optical disk.

cleanram-0.2.pet

(14.3 KiB) Downloaded 85 times

cleanup_memory.zip

(2.81 KiB) Downloaded 76 times

[Neo_78]

I tried to install Chromium web browser via the quickpet menu but this will install version 83.0.4103.106 (Official Build) (64-bit), which is relatively old.

I think the latest stable release is 96.0.4664.110.

If I understand this correctly, you can get the latest stable Chromium release for Puppy Linux from this respository as a SFS file, correct?

https://sourceforge.net/projects/lxpup/ ... /chromium/

Or is there a .tar.bz2 available somewhere like for Firefox?