Neo_78 wrote: Thu Dec 30, 2021 10:13 pm
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.
]. 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.