Running Browser as spot under non-root user desktop?

[Neo_78]

If you have created a non-root user in FatDog and you are logged into the desktop as this user, your browser (for instance Chrome) will be executed as that non-root user.

If you are logged in as root, the default behaviour is that your browser is executed as spot:

https://distro.ibiblio.org/fatdog/web/faqs/spot.html

Is there a way to run browsers as spot while being logged in as your non-root user?

[step]

If you have created a non-root user in FatDog and you are logged into the desktop as this user, your browser (for instance Chrome) will be executed as that non-root user.

If you are logged in as root, the default behaviour is that your browser is executed as spot:

https://distro.ibiblio.org/fatdog/web/faqs/spot.html

Is there a way to run browsers as spot while being logged in as your non-root user?

No, Fatdog64 doesn't provide that feature.

[Neo_78]

Is this technically not possible or what is the exact reason @step?

Does command execution as user spot require root permissions?

[step]

Is this technically not possible or what is the exact reason @step?

It is technically possible. It's just that this feature isn't implemented as a Fatdog64 convenience the way that running root's browser as spot is.

Does command execution as user spot require root permissions?

No, it requires to be able to impersonate that user. The root user can impersonate any user. For regular user A to be able to impersonate regular user B in Fatdog64, A needs to become user B, which can be done with command su + B's password. Run su --help in a terminal for usage information. The su command is busybox's su, not the util-linux's kind.

[Neo_78]

Thinking about this setup further, I tried to access firefox as another non-root user via ssh in localhost. I started sshd from the control panel and then executed as root in the terminal the following command:

Code: Select all

ssh -X mywebuser@localhost firefox

This will prompt for the user password of mywebuser as expected, but will then fail execution with the following warning and error:

Code: Select all

Warning: untrusted x11 forwarding setup failed: xauth key data not generated

Is this because x11forwarding needs to be enabled in /etc/ssh/sshd_config?

The next error is the following:

Code: Select all

Error: no Display environment variable specified

Why this error and how do you set a display environment variable?

I also tried to start sshd as normal non-root user with sshd start but get the following error:

Code: Select all

sshd re-exec requires execution with an absolute path

Is it generally possible to start sshd as a non-root user?

Also, how do you restrict ssh access to your localhost and ensure that remote access is not possible; ie no one can access your system via ssh from the internet while you run sshd in localhost as a non-root user?

Would it be sufficient to set ListenAddress 127.0.0.1 in /etc/ssh/sshd_config?

Do you know what the best way is to configure different ssh configurations for different users?

Thanks for your feedback!

[fatdoguser]

Yes ListenAddress 127.0.0.1 should be enough

Is it generally possible to start sshd as a non-root user?

Possible, but not easily so. Port 22 that ssh uses is a privileged port (in range 0..1024), so not available to mere mortals. Also the configuration files in /etc/ssh aren't supposed to be editable by others.

In /etc/ssh/sshd_config you can include Match User spot ... type conditional blocks, such as only permitting one specific userid certain options (or not) such as X11Forwarding yes that others are denied by a X11Forwarding no ... in the prior main block.

With iptables you can set a rule to only allow one IP, deny all others

Code: Select all

iptables -I INPUT -p tcp ! -s yourIPaddress --dport 22 -j DROP

Yet another alternative to your localhost usage case might be to simply drop some of root capabilities

Code: Select all

/sbin/capsh --drop=cap_sys_chroot,cap_sys_admin -- -c /bin/sh

within a terminal and you can run 'seamonkey' or whatever (as root), but that root wont be able to use chroot, nor mount unmounted drives etc. From the terminal you run that from you'll be able to 'exit' back out again, but any remote attempt to do so would drop into a black hole. As would a breakout from seamonkey leave that as root, but with limited capabilities. There's a wide range of capabilities that can be set/dropped

capsh --print # shows capabilities
capsh --explain=cap_sys_chroot # describes a individual capability

.... are useful start points

[m1k3]

Yet another alternative to your localhost usage case might be to simply drop some of root capabilities

Code: Select all

/sbin/capsh --drop=cap_sys_chroot,cap_sys_admin -- -c /bin/sh

within a terminal and you can run 'seamonkey' or whatever (as root), but that root wont be able to use chroot, nor mount unmounted drives etc. From the terminal you run that from you'll be able to 'exit' back out again, but any remote attempt to do so would drop into a black hole. As would a breakout from seamonkey leave that as root, but with limited capabilities. There's a wide range of capabilities that can be set/dropped

capsh --print # shows capabilities
capsh --explain=cap_sys_chroot # describes a individual capability

.... are useful start points

Is this more secure than running a program as spot?

[Imran]

Hmm, wouldn't the easiest solution be to give your regular login user sudo privileges to execute the run-as-spot program as root, without prompting for a password?

Again, on the lines that your regular login user is your last line of defence. If it is compromised, then safeguarding root is of minimal utility (the whole desktop vs server argument)

[fatdoguser]

Yet another alternative to your localhost usage case might be to simply drop some of root capabilities

Code: Select all

/sbin/capsh --drop=cap_sys_chroot,cap_sys_admin -- -c /bin/sh

within a terminal and you can run 'seamonkey' or whatever (as root), but that root wont be able to use chroot, nor mount unmounted drives etc. From the terminal you run that from you'll be able to 'exit' back out again, but any remote attempt to do so would drop into a black hole. As would a breakout from seamonkey leave that as root, but with limited capabilities. There's a wide range of capabilities that can be set/dropped

capsh --print # shows capabilities
capsh --explain=cap_sys_chroot # describes a individual capability

.... are useful start points

Is this more secure than running a program as spot?

Generally the simplest security choice is to ensure that you keep your data and other sensitive files (ssh keys etc.) isolated/secure. If neither spot nor sys_adm capabilities dropped root can mount that drive/device then to a large extent they're comparable in protection. In other areas however and spot is inclined to provide better protections.

A relatively safe choice is to leave fd64.sfs unchanged, and use a save folder rather than save file. su - spot and see if you can see (read) your /mnt/sda2/fd64.sfs and/or save file, if so then equally a browser flaw that permitted remote spot access could copy those to their system, little different to being handed a full system backup copy. Better still is to simply keep all sensitive files outside of fatdog, on a separate device, where the best protection is having to physically plug/unplug that device for access. Failing that the next best thing is having a barrier to being able to mount that device via software.

[m1k3]

@Imran, not sure who you were replying to but I don't use a regular user at all (except spot). I more or less have the same view as the FD devs on root. What I do is create a new symlink to /usr/bin/program-spot for all programs that access the internet so that they run as spot and I stay logged in as root 24/7. I also have the firewall set up to deny all incoming connections (which is default for eztables anyway I think) and have wireguard running.

@fatdoguser Thanks for the info and advice. I keep almost all of my files on the USB flash drive itself (not the save file) and symlink to those directories on sda2 in root home. Anything sensitive is kept in my Documents directory which is encrypted. Passwords, key files, etc. are in Bitwarden. Good idea testing with su -spot though.

[Imran]

@m1k3 my bad. I was referring to the very first post in this thread, and I didn't notice that the discussion had shifted to new participants:-)

[m1k3]

@Imran my bad too, I should have realized that.

[fatdoguser]

@fatdoguser Thanks for the info and advice. I keep almost all of my files on the USB flash drive itself (not the save file) and symlink to those directories on sda2 in root home. Anything sensitive is kept in my Documents directory which is encrypted. Passwords, key files, etc. are in Bitwarden. Good idea testing with su -spot though.

If you boot loading Fatdog into ram, so there are no drives mounted, then instead of booting directly into X add the pfix=nox boot parameter to the kernel boot.

Normally from there you'd run xwin to start the X session, if however you wrap that into a capabilities dropped encasement such as

caspsh --drop=cap_sys_chroot,cap_sys_admin -- -c xwin

then X will start up, but click on one of the drives to try and mount/open that ... and it will refuse. As will trying to chroot / fail.

You have to ctrl-alt-F2 (or any other cli tty) and mount /dev/sda2 /mnt/sda2 (or whatever) and only then will the X/gui session be able to open that filesystem.

i.e. you could selectively define which drives X was allowed to open or not, such as by mounting the drives before running the capsh .... command to start X.

Interestingly I note that even with capabilities dropped for sys_admin, that gparted within X still opens - seems to have access, indicating that additional capabilities need to be identified/set if you wanted more total isolation. I didn't however try making any changes so perhaps gparted might fail if a change was attempted.

That could be automated, i.e. edit/modify /etc/profile, perhaps to add a pfix=securex capture in addition to the existing pfix=nox action, and if set then mount selective drives that your don't mind X having access to and start xwin within the capsh encasement, leaving other drive(s) that aren't mounted and that cannot be mounted from within X, only from a ctrl-alt-Fn/tty cli (a root with full access, no capabilities dropped).

Running seamonkey within that still works, even though it runs as spot, as there's no chroot involved for that. Running chrome as root with a --no-sandbox also works, but where that root is restricted by the dropped capabilities.

A reasonable choice might be to boot with that continually, perhaps having sda4 as your data partition that from within X that couldn't usually be accessed, you have to ctrl-alt-Fn and mount it via cli, after which X can see then see the content, and perhaps use Fatdogs/rox right click Encryption to have a top level encrypted folder within that drive within which all your data files/folders were stored. Once done opening and editing, close the encrypted folder and ctrl-alt-Fn and umount that drive. For convenience perhaps add a alias into /etc/shinit to make mounting of sda4 a short keycode sequence ... such as alias m4="mount /dev/sda4 /mnt/sda4" and alias u4="umount /mnt/sda4", so when in cli you only have to type ma <enter> to mount sda4, or u4 <enter> to umount it.

Be mindful that with sys_admin capabilities dropped you wont be able to mount anything else either within that X, such as loading sfs's will fail. Again you'd still be able to do so from the ctrl-alt-Fn (cli) ... load_sfs.sh load ....

[fatdoguser]

Just tried that with a save folder style boot, where sda2 remains mounted. Changed /etc/profile ... near the bottom to add the "secure" ... case switch below the existing "nix" switch, and added pfix=secure to my menu.lst kernel boot line

Code: Select all

case "$pfix" in
	*xorgwizard*)
		#{ rm /etc/X11/no-xorg.conf; rm /etc/X11/xorg.conf; } 2> /dev/null
		if ! pidof X Xorg > /dev/null; then
			# run in another vt so our display is not clobbered with messages from background processes
			busybox openvt -sw /usr/sbin/xorgwizard 
			chvt 1
		fi
		;;
	*nox*)
		# dont start X
		return
		;;
	*secure*)
			! pidof X Xorg > /dev/null && [ -z "$DISPLAY" ] && 
			[ -z "$DONT_START_X" ] &&
			[ -z "$SSH_CONNECTION" ] && 
			capsh --drop=cap_sys_chroot,cap_sys_admin -- -c xwin 
		;;
esac

I just duplicated the xwin start code at the very bottom of /etc/profile but added the capsh code before the xwin command.

Boots, and sda2 shows a fatdog icon in the drive icons top left (i.e. its mounted, and can be opened within X, so anything on that is open - but if they're just iso's or fd64.sfs ... etc. type files they're public anyway). Clicking other drives and they remained closed/inaccessible, you have to ctrl-alt-F2 and run a mount /dev/sdXX ... command to open them up (a tip for when running in cli ctrl-alt-F2 is to run "setfont big" if the font size is uncomfortably small).

So you still have all of the regular security, browser/network programs all running as spot as per regular Fatdog, but with the additional layer of even if there was a browser flaw that enabled remote cli access to spot, and they then exploited a flaw that enabled them to gain root permission, then that root is unable to chroot (break out of the chroot) or mount your data partition (assuming you left it umounted). And if the content of that is additionally encrypted (rox right click context) then that's yet another barrier (and also is protective against if your laptop is lost/stolen).

Too much security? Well zero day browser flaws do periodically occur, as can outdated versions of browsers have known flaws that might be exploited, so spot then becomes the next hurdle. With many programs/libs/structures its difficult to be entirely comfortable that elevation from spot to root is not possible, not unreasonable to opine that it could occur. In which case its nice to have yet another hurdle that is protective of your data files/folders. Collectively turns a hurdle more into a pole vault.

[Neo_78]

When running FatDog in RAM-only mode from USB or DVD without hard drives connected, why not save your personal work files on a separate, encrypted USB pen drive that you plug and unplug as required?

In that way you can always boot into a clean system and still have the option to store your work.

Are there any password encryption functions for external USB drives available in FatDog or would an external library be required?

[m1k3]

At some point, I question when it becomes too many hurdles, even for myself. I use LibreWolf, encrypt personal documents, run a firewall, and connect via wireguard. Honestly, the likelihood of a hacker or state actor targeting me specifically is very low. I have a small number of sites that I frequently visit and I don't click on links without some level of scrutinization. Maybe I'm naive but, I feel my threat level is fairly low so any additional hurdles would seem unnecessary for basic computing.

[Neo_78]

VeraCrypt seems to be the right tool for USB pendrive encryption and is available in Gslapt:

https://www.veracrypt.fr/code/VeraCrypt/