Puppy Linux Discussion Forum

Hi All,

Many of you may realize that for the last year or so many of my posts have been about exploring web-browsers and the steps which can be taken to protect the security of your operating system and the privacy of your information. Several of those posts have concerned efforts to structure web-browsers to 'run-as-spot' and fully comply with the objective of spot: denying an application permission to access any file outside of the Spot folder.
Puppies run as Root/Administrator by default. Th mechanism of Spot was developed to provide Puppies with security/privacy obtained OOTB in Multi-User systems: that a User can not access any files beyond his/her own 'Home' folder unless and until the User elevates his/her status to Administrator by giving the required password.
Yesterday I changed the test I used in evaluation. I had thought that Puppy had two web-browsers which, if properly set up, adhered to Spot’s stated restrictions: Mike Walsh's Google-Chrome SFS --not portable-- and firefox. Google-Chrome.sfs is physically located within the Spot folder rather than anywhere as is the case with portables. The tests I had run were (1) "if the web-browser was configured to download files anywhere would downloading other than to the Spot folder fail?” and (2) “While running as Spot, could a Browser’s Menu>Files open a file beyond the access files beyond the Spot folder?”. LibreWolf failed the second test regardless of how I set it up, including locating it within the Spot folder. That failure led me to re-examine Mike Walsh’s Google-Chrome SFS just to assure myself that I had one web-browser that was “Spot Compliant”. Well, I guess I never had tried the 2nd test because I quickly discovered that unlike firefox and its clones/forks, Google-Chrome does not have a File>Open on its Menu-bar, nor anywhere else. How does one upload files iusing GC & clones? Easy: on a page which permits uploads you click the upload button. That opens a GUI enabling file-browsing. Hence, my 3rd and definitive test:
Log into this Forum, start a new post (or go to one you’ve already made and click Edit) then invoke the Attachments>Add routine. Every web-browser I’ve tried gave me access to my mounted drives. Tor did; Opera running VPN did.

Think a different Operating System provides any greater security? privacy? because under it you run as a User with limited privileges? Well, I booted into Linux Mint Ulyana. Iron web-browser required that I provide a password to run it. But once it was running, Atttachments>Add gave me access to my mounted hard-drive.. And worse than under Puppies, Linux Mint Ulyana would automatically mount partitions which weren't already mounted.
If a web-browser permits uploads, it includes some mechanism to access your computer. Do you know of any web-browser which doesn't? Do you know of any operating system which won’t allow a web-browser to?
The tentative conclusion I’ve reached is that you can create hurdles: encrypt files, run as Spot, use Tor, employ a VPN, all of the foregoing. But as long as the information is somehow immediately available to you it is also available a dedicated hacker with sufficient computing resources determined to obtain it.
Not that I can. I can’t program my way out of a paper bag. But I can think of how it can be done. And that means that someone with the determination, knowledge and resources could.
The most effective way to maintain the security and privacy of any information is not to have it readily available such as ‘it’s on a USB-Stick not/no-longer plugged in.’
According to williams2, you can run any Puppy from a USB-Stick and configure it so that you can remove the Stick after it boots to desktop. But you have to have sufficient RAM to hold in memory the operating system, the web-browser, and just the information you then need. The only operating system I know designed to run that way is puli. viewtopic.php?p=2551#p2551 Do you know of any other?

Try your tests in TazPup. I'm not sure if it will do better or not but I did notice that it was more restrictive in isolating Unix domain sockets than puppy.

Do you know of any operating system which won’t allow a web-browser to?

EasyOs allows you to run a browser in a container. The only access it has to the main filesystem is through a shared folder. In your example of uploading, you would have to move the file to be uploaded to the shared folder before the browser can access it. For test 1, you can configure your browser to download to the shared folder, but your browser cannot see beyond that to your main filesystem.

mikeslr wrote: ↑Mon Dec 07, 2020 4:16 pm

Every web-browser I’ve tried gave me access to my mounted drives. Tor did; Opera running VPN did.

Of course, if expressly given permission to do so. Most OS files will be readable/accessible, knowing a OS/version anyone can just retrieve copies from repos, they don't really need to be hidden. Important files such as ssh folder/keys, passwords file ...etc will (or rather should) have restricted permissions. If you mount data drives with global access then that will include spot. If you don't want others/spot to have access then mount with just the owner and group or owner alone having permissions.

Fatdog running seamonkey for instance (run as spot) ... cannot see into /root the permissions are set to prevent such. By default (at least in Fatdog) spot cannot see into /home either.

You might change your /etc/profile umask from 022 to 027 ... so that any new folders created will have 'others' excluded. chmod o-wrx /mnt/sdb1 (or whatever) and again 'others' wont have access to whatever is mounted to /mnt/sdb1. For things you might mount within /etc/fstab you can include a -o umask= ... options parameter to specify the permissions.

rufwoof

one of the appeals of puppy is a simple gui for those users who don't feel confident at a cli.
looking at the gui offerings when right clicking, what might mikeslr do to close some of the holes?

mikeslr wrote: ↑Mon Dec 07, 2020 4:16 pm

According to williams2, you can run any Puppy from a USB-Stick and configure it so that you can remove the Stick after it boots to desktop. But you have to have sufficient RAM to hold in memory the operating system, the web-browser, and just the information you then need. The only operating system I know designed to run that way is puli. viewtopic.php?p=2551#p2551 Do you know of any other?

Both EasyOS and EasyPup have modes that load completely into RAM and you can unplug the boot media.

In the case of EasyOS, the boot media is most likely a usb-stick. You can even make internal drives disabled:

https://easyos.org/user/ultra-secure-web-browsing.html

...that link shows "Copy session to RAM and disable drives" selected at the boot menu, however, it can also be selected from the "Shutdown" menu on the desktop:

https://bkhome.org/news/202008/save-ses ... n-ram.html

With EasyPup, multisession-DVD and disabling internal drives is great security:

https://bkhome.org/news/202012/easypup- ... -mode.html

BarryK wrote: ↑Tue Dec 08, 2020 1:50 am

You can even make internal drives disabled

I usually spin down my internal drive with hdparm -Y <device> mainly to keep the computer quiet . With drives "disabled" would I still be able to do that?

MochiMoppel wrote: ↑Tue Dec 08, 2020 2:39 am

BarryK wrote: ↑Tue Dec 08, 2020 1:50 am

You can even make internal drives disabled

I usually spin down my internal drive with hdparm -Y <device> mainly to keep the computer quiet . With drives "disabled" would I still be able to do that?

You won't be able to do anything to the drives. They will be quiet anyway, as they are not being used.

An extra point about "Copy session to RAM and disable drives" mode in EasyOS, the USB-stick that you bootup in also defaults to disabled, so you don't have to unplug it.

However, you can still save to it, via the "save" icon on the desktop. The trick is that you have to physically unplug then plug it in, and it becomes visible.

So the default is to be completely isolated.

BarryK wrote: ↑Tue Dec 08, 2020 8:27 am

They will be quiet anyway, as they are not being used.

To be clear: Does this mean they are not powered/spinning? My drive, even when not being used, is not quiet, and my problem is that the drive, even when powered down with hdparm, will come to life again after waking from suspend. A drive that is powered down and stays that way would be a very nice feature.

williwaw wrote: ↑Tue Dec 08, 2020 12:09 am

rufwoof

one of the appeals of puppy is a simple gui for those users who don't feel confident at a cli.
looking at the gui offerings when right clicking, what might mikeslr do to close some of the holes?

In the image you posted, right hand lower region ... select the 'Private' choice.

That's subjective however. Some might boot with just a single partition with grub4dos/menu.lst on the same partition as their data folders/files, and I believe that on bootup the permissions might be set by Puppy so that spot can access sda1 (whatever). In which case data should more ideally be within a sub-folder and the 'Private' setting set on that folder, so only root can access that folder/files. But that may entail spot still having access to save files/folders, such that a hacker with spot access could copy saves/changes to their system for inspection at their leisure. i.e. if using a save file then spot shouldn't really be able to view that, or if using a save folder then again spot shouldn't be able to view that. I don't know enough about the various Puppy's as to whether that is viable or not. I did struggle with Puppy security some time back and moved over to Fatdog for such reason (Fatdog is a true multi-user system, Puppy isn't (more of a virtual multi-user system with Spot/Fido ..etc)).

Barry's EasyOS is a good alternative to Puppy style with great separation/security-in-mind capacity. For those that like to repeatedly boot a 'clean' configured system I like how EasyOS can be booted in a 'normal' manner, configured as you like, and then subsequently booted in a 'contained' manner (all changes are lost, no access to drives ..etc. (forget the exact number, but around the 6th or 7th item in the boot menu choice)). And should you want to re-configure, just boot the 'normal' choice again to make the changes. A factor there however is that whilst its good for local/data security (provided used in the correct manner), its not so good for online security. Accordingly I prefer Fatdog for that. With Fatdog's true multi-user you can set up good separation/security of data and it runs emulation and networking very well - which helps with online security (anti-fingerprinting etc.). 2.5.1 (latest) version of EasyOS however now also has emulation working well. Fatdog however still has the edge as its very stable. Security flaws are more often just bugs that entail a security risk. Fatdog is structured whereby its relatively static and built upon/improved with each release. EasyOS in contrast is much more experimental and as such bugs (and hence potential security risks) are much more likely to occur/be-present.

You can't beat physical separation. Recently I've been messing around with x0vncserver and found it to work very well for me. Combines both X and vnc such that you can run a desktop on a 'server' and vnc into that (client) to run the likes of SuperTuxKart type graphics on the client very well (and hence also other 'normal' graphics such as browser/Libre Office ..etc.). With a Live-DVD style Fatdog as the server on one box, then it doesn't really matter what you run on the client box/device, weak or strong security matters much less so on the client ... as that remains (provided run that way) isolated (i.e. do all your network activities through the server, not on client). Which also provides better online security, for instance any fingerprinting to see what device is being used sees the severs fingerprint, not the actual devices fingerprint.

When I originally saw the title of this threat I thought it might have been a Tor type content, suspecting that it might have highlighted how the security of Tor can be a illusion when sites are given script permissions as is very common (many sites simply wont work without script permissions being given). Once scripting on the device is granted its pretty much game-over security wise as the scripts can feed back a plethora of fingerprinting metrics. Ditto if you run chrome that strives to fingerprint/monitor as many as possible. When however the device used to access the net is physically separate from the device being used to view/control things, with only screen contents being conveyed between the server and client then fingerprinting of the client device is much less likely to occur.

Tor tries to hide by bouncing routing around multiple layers that they call onions/garlic to obscure the originator, and by striving to make everyone look to be using the same browser. But if a script permission permits for instance the OS version and other measures to be determined then the whole hiding element is pretty much lost, whilst having endured slower performance in having tried to have hid. And where in not granting script permission makes general usage pretty much intolerable.

A alternative might be to use virtualisation (hardware abstraction). If many boot into a (very) similar virtual system, with a random mac/hostname generated ...etc. then scripts will report back very similar fingerprints. If traffic is routed via a common single point(s) then again identification is obscured. With that arrangement as the 'server' system, any client that connects to that via simple screen buffer copying method, where data is also stored on that client system, will have reasonable security of both online and local (data) elements.

Maybe Puppy client that vnc's into a Fatdog server (old desktop/pi/whatever) that is running emulation (virtualbox/qemu/whatever) that net connects/routes using sshuttle/socks5 proxy/whatever. And where the choice of iso/image that the qemu emulates is a commonly shared/used image. In utilising vnc a benefit is that it doesn't have to be a Puppy client, you could use Puppy to vnc in and use for a while, disconnect and then later vnc in using your phone ...etc.

Assuming, as it likely, others are granted script permissions on the server (Fatdog running a qemu image/emulation), then the script reports back a finger print that is near identical to any others that are using the same setup.

With Tor the 'cost' is slower network flow (bouncing), with the above the cost is slower processing due to using emulation/vnc. And where potentially the capacity to not have your actual (client) device be fingerprinted is better for the emulation/vnc approach.

There's a broad range of vnc type choices out there, that over time have improved, further aided by ever increasing network speeds. NOX for instance looks to be a interesting choice. Similar to x0vncserver, but more modern and with better support for sound - but is limited by licence. For x0vncserver setup/trial see viewtopic.php?p=11883#p11883

For what I outlined earlier, we don't have to use vnc.

Here's one of my kvm/qemu boot setup/run command ...

QEMU_AUDIO_DRV=alsa qemu-system-x86_64 \
-soundhw all \
-full-screen \
-k en-gb \
-usbdevice tablet \
-vga std \
-smp 2 \
-boot d \
-machine type=pc,accel=kvm \
-cpu Conroe \
-enable-kvm \
-m 2048 \
-net nic \
-net user,hostfwd=tcp::2224-:22 \
-cdrom $ISO &

where beforehand I set variable ISO=xxx to whichever ISO image I've opted to boot. Fatdog, Puppy ... whatever ISO. A distinguishing feature there is the use of a UK/GB keyboard (-k en-gb) which is convenient for typing, but is a fingerprint of the location (but granularity being a entire country). That emulates a Conroe cpu, with 2GB of ram (-m 2048), 2 cores (-smp 2) and a standard vga (-vga std). It also has all of the sound being forwarded to the host system (-sound all and setting QEMU_AUDIO_DRV=alsa variable as part of the command). With qemu installed and virtualisation set in your BIOS, you just have to run modprobe kvm-intel OR modprobe kvm-amd (whichever is the appropriate choice for your actual hardware) before running that command in order to load the correct modules for your system (assuming you're running either a intel or amd).

The -usbdevice tablet helps in my case for better aligning the mouse cursors for the host and guest, in other cases leaving that out may be better (trial and error). -boot d indicates we're booting a ISO. The net commands are to use the active hosts network - but where within the guest system that is just seen as a regular ethernet connection, even if the host is actually connected via wifi/SSID. The host forward element just has host port 2222 forwarded to the guest systems port 22 i.e. ssh, so we can ssh into (or sshfs mount) from the host to the guest using host port 2222. If sshd is running on the host then the guest can ssh to the host using ssh 10.0.2.2

If the ISO being booted was the same as many others who were also booting that same qemu boot command and ISO, and each of those had the guest route traffic via a common ssh server (ssh -D 1234 -q -C -N user@some-ssh-host and setting the browser to use that, or by using something like sshuttle), and where data was stored on the host.

The trick is to have many using the same emulation, and same ISO (live-boot dvd), and a common ssh server/routing. Whether the Conroe 2 core 2GB I used above or other choices might be better ??? With qemu emulation you can even emulate non existent hardware, such as setting -smp 4 (4 cores) on a two core system, and it will emulate those 4 cores - as though they actually existed.

If US Mike where booted using that and was routing/connected to hashbang.sh and so also were I and UK Mike in a similar manner, then web sites would see the same common hashbang.sh server IP as the 'origination IP' address for all three of us. If a script were run on each/any of the boxes then that would report back the same hardware/fingerprints (other than US Mike perhaps using a -k en-us keyboard layout). Ideally whatever was booted (ISO) should have the timezone set to be the same. With that setup it would be difficult to pin down to whether US Mike, UK Mike or Rufwoof were accessing a web site. Yes with just three identification of US Mike (due to the keyboard difference) would be possible, but if others were also using the setup in the US then the actual user would be obscured. Or UK Mike and Rufwoof could opt to tolerate using a us keyboard layout - as the differences are relatively few and quickly adapted to with practice. Puppy Borg perhaps, as in Star Trek, 'the collective, we are many'.

Contrast that Puppy Borg with Tor - where by a script reporting back the cpu, OS version, number of cores, available ram, disks and sizes, browser version, installed plugins, download speed, ... and a whole bunch of other factors - that relatively quickly can focus down to being a 'unique' individual !!

This is with the qemu command having the -cdrom ... dropped to instead just point to EasyOS 2.5.1 image file (downloaded the .gz and decompressed it).

On bootup I just pressed enter to select all defaults, including the initial country selection.

Didn't initially boot to gui desktop, had to run xorgwizard in which I just selected 800x600 Vesa mode.

The attached is the 'hardinfo' command report for Computer and Network selections, that produced a html file that I've gzip'd i.e. perhaps details some of which a remote web site with script permissions might see.

If booted the exact same way elsewhere, on different hardware, likely they'd be very similar reports despite the physical boxes/hardware being distinctly different.

EDIT: Meant to check that overwriting the keyboard file with the desired choice, but retaining the US filename/pointers worked, but had shutdown beforehand. Will try that later (cp en-GB en-US type action). Hopefully that will be obscured - and still report the keyboard as being 'US'. Failing that - there's also xvkbd in which you can select the keyboard layout to use to enter text

Tried booting kvm/qemu (using Fatdog) of EasyOS kernel lockdown

Not that unsurprisingly ... didn't boot. So booted again using boot to ram, which booted fine, and using seamonkey to view youtube ...etc. was all comfortably usable. Again with the default boot settings I'd used earlier.

So conceptualising a Borg type system, where many might potentially boot the exact same type (virtual) system, I'm inclined to go with EasyOS as the OS, default US keyboard, a global time/clock for the timezone, a common cpu choice (suggestions ??), 2 cores, 2GB ram (??), 1280x768 display resolution. Perhaps using a cut down version of EasyOS, as being a guest system predominately for network activities, Libre Office ...etc. might be left to the host to support. If available as ISO/image format, booted in a read only (no persistence) default manner, then many might boot/use that exact same image and thereby obscure tracking individuals. Relatively frequent reboots to reset records of up time, data transfer amounts ...etc. also seems appropriate, but not necessarily too regularly, maybe a few times per day type intervals (which would also flush out caches etc.).

MochiMoppel wrote: ↑Tue Dec 08, 2020 9:19 am

BarryK wrote: ↑Tue Dec 08, 2020 8:27 am

They will be quiet anyway, as they are not being used.

To be clear: Does this mean they are not powered/spinning? My drive, even when not being used, is not quiet, and my problem is that the drive, even when powered down with hdparm, will come to life again after waking from suspend. A drive that is powered down and stays that way would be a very nice feature.

That is an interesting question!

I don't know. I assumed that if the drive is powered on but not being accessed by Linux kernel, then it would default to a slow spin. Also, I thought that most of the noise is from head movement.

if hdparm has to be used, it would have to be done in the initrd, before access to the internal drives is removed. Busybox is in the initrd and it has hdparm, so it could be used.

I will run my computers in lockdown mode and see if I can hear the internal drives. If so, I might experiment with hdparm.

Though, anyone can do it. In EasyOS, go to the boot-partition, and click on 'initrd', it will open up, you can edit the 'init' script, then click on 'initrd' again to update it, then reboot.

BarryK wrote: ↑Wed Dec 09, 2020 4:25 pm

I will run my computers in lockdown mode and see if I can hear the internal drives. If so, I might experiment with hdparm.

If you have a computer like mine that turns off its fans when idle then I'm sure you will hear them hissing. Another consideration should be heat and energy consumption caused by a spinning drive.

Though, anyone can do it. In EasyOS, go to the boot-partition, and click on 'initrd', it will open up, you can edit the 'init' script, then click on 'initrd' again to update it, then reboot.

I'm afraid none of my computers meets your recommended spec for running EasyOS. Can your method of "hiding" drives and making them inaccessible be applied to legacy Puppies? I see that file init has a section "LOAD MODULES TO ACCESS DRIVES". Would this be the place to make changes? If I knew what to incapacitate then I could create a boot parameter to boot with or without this option.

MochiMoppel wrote: ↑Thu Dec 10, 2020 3:19 am

BarryK wrote: ↑Wed Dec 09, 2020 4:25 pm

I will run my computers in lockdown mode and see if I can hear the internal drives. If so, I might experiment with hdparm.

If you have a computer like mine that turns off its fans when idle then I'm sure you will hear them hissing. Another consideration should be heat and energy consumption caused by a spinning drive.

Though, anyone can do it. In EasyOS, go to the boot-partition, and click on 'initrd', it will open up, you can edit the 'init' script, then click on 'initrd' again to update it, then reboot.

I'm afraid none of my computers meets your recommended spec for running EasyOS. Can your method of "hiding" drives and making them inaccessible be applied to legacy Puppies? I see that file init has a section "LOAD MODULES TO ACCESS DRIVES". Would this be the place to make changes? If I knew what to incapacitate then I could create a boot parameter to boot with or without this option.

What is my recommended spec?

It has to be a x86_64 CPU, and probably 2GB RAM minimum. If you want to use the "Copy session to RAM", I recommend 4GB RAM, but it will probably still work with 2GB. Computer needs to be able to boot from USB, but if not, EasyOS can be installed direct to a hard drive partition, or rather, a folder in a partition, as a frugal install, and the boot manager edited appropriately.

I have written it into my to-list to look at the init script in the initrd of EasyOS, to see where there is an appropriate place to insert the hdparm command. And yes, it could also be a kernel boot parameter.

mikeslr wrote: ↑Mon Dec 07, 2020 4:16 pm

Many of you may realize that for the last year or so many of my posts have been about exploring web-browsers and the steps which can be taken to protect the security of your operating system and the privacy of your information. Several of those posts have concerned efforts to structure web-browsers to 'run-as-spot' and fully comply with the objective of spot: denying an application permission to access any file outside of the Spot folder.
Puppies run as Root/Administrator by default. Th mechanism of Spot was developed to provide Puppies with security/privacy obtained OOTB in Multi-User systems: that a User can not access any files beyond his/her own 'Home' folder unless and until the User elevates his/her status to Administrator by giving the required password.
Yesterday I changed the test I used in evaluation. I had thought that Puppy had two web-browsers which, if properly set up, adhered to Spot’s stated restrictions: Mike Walsh's Google-Chrome SFS --not portable-- and firefox. Google-Chrome.sfs is physically located within the Spot folder rather than anywhere as is the case with portables. The tests I had run were (1) "if the web-browser was configured to download files anywhere would downloading other than to the Spot folder fail?” and (2) “While running as Spot, could a Browser’s Menu>Files open a file beyond the access files beyond the Spot folder?”. LibreWolf failed the second test regardless of how I set it up, including locating it within the Spot folder. That failure led me to re-examine Mike Walsh’s Google-Chrome SFS just to assure myself that I had one web-browser that was “Spot Compliant”. Well, I guess I never had tried the 2nd test because I quickly discovered that unlike firefox and its clones/forks, Google-Chrome does not have a File>Open on its Menu-bar, nor anywhere else. How does one upload files iusing GC & clones? Easy: on a page which permits uploads you click the upload button. That opens a GUI enabling file-browsing. Hence, my 3rd and definitive test:
Log into this Forum, start a new post (or go to one you’ve already made and click Edit) then invoke the Attachments>Add routine. Every web-browser I’ve tried gave me access to my mounted drives. Tor did; Opera running VPN did.
Attachments-Add-files.png
Think a different Operating System provides any greater security? privacy? because under it you run as a User with limited privileges? Well, I booted into Linux Mint Ulyana. Iron web-browser required that I provide a password to run it. But once it was running, Atttachments>Add gave me access to my mounted hard-drive.. And worse than under Puppies, Linux Mint Ulyana would automatically mount partitions which weren't already mounted.
If a web-browser permits uploads, it includes some mechanism to access your computer. Do you know of any web-browser which doesn't? Do you know of any operating system which won’t allow a web-browser to?

Hi Mike.

What do regular Puppy's do if you for instance enter a URL of file:///sys/devices/virtual/dmi/id ... and if visible click on say the BIOS or motherboard type files, do you see what BIOS name/version, motherboard serial number ...etc. type data?

I have a OpenBSD image file that when booted using kvm/qemu is presented as a just another window and when I install and run Chromium within that it is secured by the usual pledge/unveil/W^R type OpenBSD security mechanisms, so you can't browse around such hardware/other files like you often can with Linux.

Linux as the host kvm/qemu booting OpenBSD as a guest is quite nice as Linux better supports wifi, which the guest then can use as though it were a ethernet connection. kvm/qemu also supports snapshots, so for instance you can boot, set things up, shutdown, and then create a snapshot of that 'clean' version that you can then boot, use, shutdown and throw that snapshot away (start with another 'clean' snapshot' boot the next time you boot. With the option to revisit the main system to reconfigure the 'clean' version to make that the updated/saved version that subsequent snapshots boot.

OpenBSD's chromium is 'cleansed'. At one time a year or two back OBSD were developing both secure versions of iridium and chromium, but focus seems to have turned to just chromium nowadays.

In Fatdog, seamonkey (that runs as spot), I get to see all of the details, BIOS name, version, motherboard type, serial number ...etc. Things that might be used to attack or simply uniquely track you. In EasyOS you can even navigate within its lockdown kernel boot (no hdd's accessible) ... to see details such as which mitigations are or aren't present. If such becomes accessibly simply by granting remote sites 'script' permissions !!! In OpenBSD (that in this image is running within kvm/qemu) such browsing isn't possible

Linux has opted to forego security in order to make userland broader. OpenBSD in contrast comes at it from the other direction. Combining both within the same desktop environment is a nice combination IMO.

rufwoof wrote: ↑Thu Dec 10, 2020 12:32 pm

Hi Mike.

What do regular Puppy's do if you for instance enter a URL of file:///sys/devices/virtual/dmi/id ... and if visible click on say the BIOS or motherboard type files, do you see what BIOS name/version, motherboard serial number ...etc. type data?...

A picture being worth 1000 words:
Bionicpup64 running palemoon as root with file:///sys/devices etc. entered into URL field.

Will see whether running a web-browser as spot is any safer after breakfast and a 2nd cup of coffee.

Have returned.
Mike Walsh's Google-Chrome.sfs is supposed to be constructed to run-as-spot. See, for example, http://www.murga-linux.com/puppy/viewto ... 90#1001490. Under Bionicpup64 Menu>System>Login & Security Manager has the appropriate Check-Mark within the relevant Radio-box supposedly instructing Google-Chrome to run-as-spot. Despite this, entering file:///sys/devices etc. in Google-Chrome's URL field and file-browsing down to the /bios_version folder reveals that my computer has bios version J01 v.02.15.

I've just downloaded/tried bionicpup64 inside a kvm/qemu and I installed it with the run internet programs as spot settings configured, ticking the palemoon browser to be included in that, and ...

... not good!

I shut that down and removed it before investigating further (DOH!) - such as whether it might see into the likes of save files/folders, i.e. potentially 'download' (upload) such files for viewing/cracking at their leisure. Not going to bother with rebooting it again now, as the details already being potentially revealed is enough cause for concern.

Thanks, rufwoof, for an even more revealing test than I had at the beginning of this thread. And Mike, don't feel too bad. We all thought the spot mechanism was effective. You, at least, had the good sense to reach the conclusion that a lot of hard work was being put in for little gain.
Sorry, troops, if another one of my quirks --a deeply ingrained skepticism concerning the perfection of any human endeavor-- got in your way of achieving tranquility.
I'm going to have to spend some time exploring EasyOS. But I'm also going to start another thread unless someone already knows the answer to the question I have. That thread will focus on 'firejail'. And the question I have is whether that mechanism is more effective than run-as-spot.

The reason I think some exploration of that mechanism may be worth pursuing is that, as far as I can tell, at least in theory, any puppy with a recent enough kernel, should be able to use it. A quick glance at pkgs.org reveals firejail versions for Slackware 14.1 and Ubuntu xenial xerus. If a puppy's kernel will support firejails, implementing them involves using profiles files specific to the application you desire to isolate. Profiles are just text files, and there seems to be adequate and easily found documentation. FWIW, downloading the appropriate debs under Bionicpup64 --about 8 Mbs-- included 438 profiles. I think I read that as many as 800 profiles were already in the public domain. Under puppies we would probably only be interested in web-facing applications and perhaps wine. Among the 438 profiles I obtained were ones for wine and for the recent emergent web-facing application zoom.
Discussion of firejail could continue on this thread. But I think it better to start a new one: easier to find and can be extended --if worth the effort-- to discuss & provide profile recipes if those available OOTB need to be modified.

Actual gzip'd html file (so can post here)

Just a simple javascript snippet that prompts to open a file. If that can open a file, then so might any other javascript - perhaps with additional functionality to do so automatically and send the content 'somewhere'.

Hi all,

Exploring my own question: "But I'm also going to start another thread unless someone already knows the answer to the question I have. That thread will focus on 'firejail'. And the question I have is whether that mechanism is more effective than run-as-spot."

Caveats: I don't have firejail running under any Puppy. And as usual when I start exploring (or been away from an area a little while --perhaps 2 weeks, maybe just an hour ) -- it's best to adopt the premises that (a) I don't know what I'm doing and that (b) I've done it wrong.

I do have Linux Mint Ulyana installed and updated on the theory that maybe it offers something I can't do under Puppy. Installing firejail and associated files was easy. Firefox --also on that system and up-to-date-- is one of the applications not only having a default profile also appearing OOTB on the firejail GUI. So I started firejail via the menu and selected firefox via the GUI.

So run, firefox would not allow me to download an image other than to its assigned Download folder. [Being OOTB a multi-user system, I could probably, easily, create a second user further isolating firefox]. But applying rufwoof's 'URL-file' test produced the following:

And the information within those folders was available.
So firejail may provide security on par with running-as-spot properly setup under Puppies. But offers no greater privacy.
OOTB, I can think of a couple of thing I may have done wrong. firejail profiles use both white-lists and black-lists and, as I mentioned, are easily customizable. But customizing requires some knowledge. The profile I used was OOTB. It may be possible to edit that to blacklist? access to /sys and every folder that firefox doesn't actually need to perform as a web-browser.
I didn't think of it while running Ulyana. But it's likely that the default firefox-profile its firejail used was similar to that which came with the Bionicpup64's firejail debs. I've attached it. To examine, remove the false 'gz'.

Under the circumstances, I'm not going to start a firejail thread. I'll leave to those more knowledgeable the decision of whether further effort would be useful.

As I've oft said Mike, primary is being aware that proclaimed security is often a fallacy. Don't assume a secure system will always be secure, and even a brief lapse could lead to a persistent security breach, i.e. generally consider your system(s) as being insecure and approach it from that angle. Maintain backups, lock away sensitive data ..etc.

Consider what you're trying to secure. If certain documents/files, then lock them away, perhaps on a totally disconnected box that you separately boot to access those files. For online banking, boot and configure a clean/configured system, and don't save changes. When you boot that and go direct to your banking web site, nowhere else before or after, then more likely that session will be secure. For general browsing/fun, just accept insecurity, and perhaps start with a clean session daily, use that and shutdown without saving at the end of the day, and whilst that might have been compromised during the day, potentially that wont be a persistent breach. Treat it as you would if using a public library PC to browse. Addressing privacy - the big trackers who make $$$'s out of spying/tracking, well you're up against great minds that given the potential broad range of attack vectors will more than likely see them win out, leaving only the option of non-participation/off-grid as a means to avoid that.

The structure of Puppy mostly addresses that broad range of security factors, and in particular the ability to frugally boot/configure/save, and then reboot/use/not-save. Likely adding in additional layers will serve only to create lag without really addressing the 'security risks' (Tor will just cause lag/loss of functionality; Containment may help with securing personal data at the expense of greater complexity (and additional code in itself = greater attack surface)); Barry's EasyOS however goes a long way in eliminating such complexities.

Yes you can reduce tracking. Install chrome and give it permission to run in the background; And/or use Google search instead of DuckDuckGo/whatever; And/or log into any Google/subsidiary services ...etc. and total tracking is pretty much assured. Using alternatives helps reduce that, but there are no guarantees of total avoidance excepting for limited/specific communications/cases set up specifically for that purpose.

Thanks, rufwoof. [FWIW, I also clicked the Thanks button related to your last post]. The conditions you described and the practical solutions you suggest are what my right-brain (instant gestalt impression derived from life-experience) had envisioned before my left-brain (analytic examination of the factors involved) focused on the question.
What has become clearer is the certainty of uncertainty. Perhaps another quirk: I find that somehow reassuring. As a species we are really good at dealing with that condition once we recognize its presence. After all, one of the first things we each learn to do is to move forward by making small adjustments so as to not fall on our face.

MochiMoppel wrote: ↑Tue Dec 08, 2020 9:19 am

BarryK wrote: ↑Tue Dec 08, 2020 8:27 am

They will be quiet anyway, as they are not being used.

To be clear: Does this mean they are not powered/spinning? My drive, even when not being used, is not quiet, and my problem is that the drive, even when powered down with hdparm, will come to life again after waking from suspend. A drive that is powered down and stays that way would be a very nice feature.

@MochiMoppel
OK, I have added code to EasyOS, so it applies the "hdparm -Y <drive>" in the init script of the initrd, before the drives get "disabled". So, if you have booted off a USB-stick, in "Copy session to RAM & disable drives" mode, the internal HDD will be put into deep-sleep mode and will be dead quiet.

I have posted to my blog:

https://bkhome.org/news/202012/put-disa ... -mode.html

...anyone can try this for themselves, as the blog post explains.

rufwoof wrote: ↑Thu Dec 10, 2020 7:59 pm

[....]
When you boot that and go direct to your banking web site, nowhere else before or after, then more likely that session will be secure.

You are presuming that the bank has not been hacked.
This is mostly a reasonable assumption but I fear it is becoming less so.
I have noticed that more and more folks are depending on more and more 3rd party resources in their web designs. This greatly increases the target area for the hackers.

For general browsing/fun, just accept insecurity, and perhaps start with a clean session daily, use that and shutdown without saving at the end of the day, and whilst that might have been compromised during the day, potentially that wont be a persistent breach.

I am thinking that adding a feature to allow a "golden" save file to be copied to a working save file during boot would be a nice thing. It would mean that the user can get all the things installed and working and then call that the "golden" version. All the printers and SAMBA shares etc would be the same each time but the typical day would be like it never happened.

Treat it as you would if using a public library PC to browse. Addressing privacy - the big trackers who make $$$'s out of spying/tracking, well you're up against great minds

You may be overlooking that you are also up against a vast army of idiots. Ants will find a blob of jam you left on the kitchen counter. They are not smart, they are just very great in numbers. The same can happen with a flaw in software. Among a million tries at it, someone will hit the mark.

Now I will go get some coffee and go back to browsing through dodgy sites to see what they have.

I'm revisiting this thread as I wondered to what extent running a web-browser from a chrooted environment might be able to pass rufwoof's test, to wit:
"enter a URL of file:///sys/devices/virtual/dmi/id ... and if visible click on say the BIOS or motherboard type files, do you see what BIOS name/version, motherboard serial number ...etc. type data?" viewtopic.php?p=12097#p12097 or perhaps more semantically accurate fail to be able to.
As a test case, I SFS-loaded watchdog's ff-74.0-qAlight.sfs: from here, http://www.murga-linux.com/puppy/viewto ... 01#1053201 into Bionicpup64 with 32-bit compatibility SFS loaded. Primarily, it was chosen because it was a comparatively recent version of firefox, and firefox --unlike the chrooted iron-- has a module on its menu for accessing files.

I'm posting from it now. Using the 'file>open' module I was able to access files with in the chroot --that is the top-level folder named cnt which is created when the SFS was loaded. But I was not able to access files outside of it. So, the chrooted firefox is at least as effective as firefox when properly run-as-spot.

Well, entering file:///sys/devices/virtual/dmi/id into the 'URL' box appeared to provide access to the information contained at file:///sys/devices/virtual/dmi/id. But I sort of recalled watchdog --or someone-- mentioning that in building the contents of cnt no effort was made to strip unnecessary files. The script which creates the chroot reads:

#!/bin/sh
export LC_ALL=C
mount --bind /dev /cnt/dev
mount --bind /proc /cnt/proc
mount --bind /sys /cnt/sys
mount -t devpts devpts /cnt/dev/pts
cp /etc/resolv.conf /cnt/etc/resolv.conf
cp /var/lib/dbus/machine-id /cnt/var/lib/dbus/machine-id
xhost +
mkdir -p /cnt/tmp/.X11-unix
mount --bind /tmp/.X11-unix /cnt/tmp/.X11-unix
chroot /cnt firefox -profile /usr/local/firefox/profile "$@"

So /cnt/sys is actually 'mount-binded?-- [is that the right term?] to /sys.

I wonder if a more specific --and less all-encompassing-- 'mount-binding' was possible. Certainly firefox doesn't need to know what computer it is run from. If the reason for the chroot is only to run a web-browser, exactly what system folders and files are necessary?

Edit: might be more efficient to mount --bind /sys /cnt/sys then remove folder/files from /cnt/sys which aren't needed; if that's possible.

By the way, the chrooted firefox downloads to /root/Downloads -- but it's the /root/Downloads in cnt; i.e. /cnt/root/Downloads.

mikeslr wrote: ↑Fri Jan 15, 2021 1:49 am

I'm revisiting this thread as I wondered to what extent running a web-browser from a chrooted environment might be able to pass rufwoof's test, to wit:
"enter a URL of file:///sys/devices/virtual/dmi/id ... and if visible click on say the BIOS or motherboard type files, do you see what BIOS name/version, motherboard serial number ...etc. type data?" viewtopic.php?p=12097#p12097 or perhaps more semantically accurate fail to be able to.
As a test case, I SFS-loaded watchdog's ff-74.0-qAlight.sfs: from here, http://www.murga-linux.com/puppy/viewto ... 01#1053201 into Bionicpup64 with 32-bit compatibility SFS loaded. Primarily, it was chosen because it was a comparatively recent version of firefox, and firefox --unlike the chrooted iron-- has a module on its menu for accessing files.

I'm posting from it now. Using the 'file>open' module I was able to access files with in the chroot --that is the top-level folder named cnt which is created when the SFS was loaded. But I was not able to access files outside of it. So, the chrooted firefox is at least as effective as firefox when properly run-as-spot.

Well, entering file:///sys/devices/virtual/dmi/id into the 'URL' box appeared to provide access to the information contained at file:///sys/devices/virtual/dmi/id. But I sort of recalled watchdog --or someone-- mentioning that in building the contents of cnt no effort was made to strip unnecessary files. The script which creates the chroot reads:

#!/bin/sh
export LC_ALL=C
mount --bind /dev /cnt/dev
mount --bind /proc /cnt/proc
mount --bind /sys /cnt/sys
mount -t devpts devpts /cnt/dev/pts
cp /etc/resolv.conf /cnt/etc/resolv.conf
cp /var/lib/dbus/machine-id /cnt/var/lib/dbus/machine-id
xhost +
mkdir -p /cnt/tmp/.X11-unix
mount --bind /tmp/.X11-unix /cnt/tmp/.X11-unix
chroot /cnt firefox -profile /usr/local/firefox/profile "$@"

So /cnt/sys is actually 'mount-binded?-- [is that the right term?] to /sys.

I wonder if a more specific --and less all-encompassing-- 'mount-binding' was possible. Certainly firefox doesn't need to know what computer it is run from. If the reason for the chroot is only to run a web-browser, exactly what system folders and files are necessary?

Edit: might be more efficient to mount --bind /sys /cnt/sys then remove folder/files from /cnt/sys which aren't needed; if that's possible.

By the way, the chrooted firefox downloads to /root/Downloads -- but it's the /root/Downloads in cnt; i.e. /cnt/root/Downloads.

You might want to look at the unshare command as an alternative to chroot. Fatdog64 uses this command as an option in it's sandboxing scripts. The following option for this command is likely very useful:

       --mount-proc[=mountpoint]
              Just before running the program, mount the proc filesystem
              at mountpoint (default is /proc).  This is useful when
              creating a new PID namespace.  It also implies creating a
              new mount namespace since the /proc mount would otherwise
              mess up existing programs on the system.  The new proc
              filesystem is explicitly mounted as private (with
              MS_PRIVATE|MS_REC).

https://man7.org/linux/man-pages/man1/unshare.1.html

The reason being, is that a process started outside of the chroot will not be bound to the chroot. This is a way of excaping the chroot. On puppy rox is already running. If you type rox without the "-n" option then the existing rox process will be used to create your file explorer window but the existing rox process is not contained within the chroot. Once you have the file explorer window open you can use this window to get a shell that isn't bound/(contained within) the chroot.

Hi Mike.

Don't worry about the visibility of the likes of file:///sys/devices/virtual/dmi/id contents using a browser - as the good browsers will block that being remotely viewed/accessed, allowing (or not) only local access. Fundamentally that was perhaps a poor example. Basically the main point is that I disagree with the common statements that its OK to run as root, such as declared in the likes of ...

http://distro.ibiblio.org/fatdog/web/faqs/login.html

https://igurublog.wordpress.com/2010/01 ... -not-root/

http://web.archive.org/web/200806040340 ... age_id=243

But equally Puppy spot is little better as there are a plethora of possibilities for spot to elevate to root, so much so that you might as well not bother with spot, as its relatively trivial for spot to be elevated to root.

For instance run
find / -perm -4000
to see just how many setuid files most Puppy's have ... and there are many.

Or via known program bugs that can be exploited

Or via X. For instance open a terminal (urxvt) as root, I'll use that as a 'target' example. Open another terminal and su - spot ... In the terminal that's running as spot, run ps -ef and note the pid of the urxvt window running as root. Then again in the spot terminal run

export DISPLAY=:0
xdotool search --pid <PID> ... where <PID> is the pid of the 'target' root urxvt

Note the window id that returns and then again in the spot terminal window run

xdotool windowactive <WID> ... where <WID> is the identified windowid
xdotool type whoami
xdotool key KP_Enter

... and you'll see (assuming that xdotool is available) that the root urxvt window has now run the 'whoami' command. Which could have been any command(s). Just one basic example, and where any other window running root could be targeted, such a rox and having that open a terminal window and stuffing commands into that ...etc.

So what - most will say. I don't care if others see what I'm doing or have stored, and I can reboot clean again in seconds to undo anything nasty (frugal/backups). Well how would you feel about someone remotely grabbing a copy of your wifi SSID and password and then flogging/passing those details on to others around your geolocation ... who might then use that wifi connection to do all sorts of stuff - perhaps resulting in the police smashing through your door at 4am? Or trying to explain to a employer that the means by which their servers were compromised using your ssh id/keys ... wasn't actually you?

Other targets might be to copy your ssh keys and/or /etc/passwd and shadow files over to the attackers server, so that they might brute force crack any encryption at their leisure.

The answer is to not run a root, including any programs that may use the internet, even just to call home for potential updates. And to run a userid that is correctly constrained (which spot in Puppy isn't). The closest is EasyOS containment, where even though the userid in the container is named 'root' - its highly restricted (much more constrained than spot in Puppy's). If you look at how that containment is configured you'll see that its pretty complex, uses a combination of pflask (chroot manager), capabilities dropping, unsharing, and a separate X server (Xephyr).

If you want to retain a Puppy type desktop with more appropriate security then EasyOS is a good choice. Use the main level (real root) to wifi net connect, ssh (where no downloads are made), store your data and to block access to your routers admin url, and then restrict access to that data/keys/passwords ..etc. by opening the Buster container and using that to browse, use Libre office ...whatever - and where any penetration into that has barriers blocking getting at your data, keys, passwords ...etc.

Alternatively again use a top level system to wifi net connect, ssh from, store passwords ...etc. and kvm/qemu boot another system within which you use it to browse/do-stuff.

Linus doesn't even give too much regard to Linux security, prioritises userland over security, and there are just too many holes in Puppy security. Starting from your base of a browser in a chroot ... you'd more likely go on to just extend things until you ended up with something like EasyOS containment - not much point in reinvesting that wheel all over again.

Or ... not bother. Many seem content to not concern themselves and get away with using Puppy as-is. I have seen lists of locations and ssid's/passwords circulating around and many don't even bother change or even set passwords on their routers - so there are plenty of 'easy targets' that seemingly infrequently actually get exploited. Much of security is the publishing of potential exploits/failings, much less rare are actual application of exploits. Why for instance bother stealing some bandwidth using a cracked ssid/password when you can more often just connect to a open-wifi. Why bother crack into someone's PC/data when more often they'll just be reams of useless content. Keep your personal data/content separately (off the browser system) and that's secured. Change your passwords periodically. Only use low value cards for any online transactions, have another 'offline' account for larger sums. Online stock/brokerage accounts for instance typically only permit transfer in and out from a pre-defined/fixed account such that 'getting at' that money is difficult (the security is predominately to stop others accessing the account and screwing up the portfolio/holdings). When making a payment online strive to boot into a known clean system, as though freshly installed, and when you go direct to the site using that, nowhere else before or after, then most likely that will be 'clean'.