I prefer and recommend to install software not from the operating system vendor in userspace than in the os as the administrator account, unless in a few cases where the machine is espcially set up to run the software upon boot as a server.
This is more true even and especially for a single or family user system where that user can easily get to the root account.
This is more difficult on microsoft windows as many software presume admin and make the person work harder to force it into userspace. It is worthwhile though, as much software once installed will just stay there, and it is fairly rare to introduce a new package.
In userspace, the software never gets admin access, so it cannot introduce bugs into the host operating system and break updates.
Even if it is just bugs, the system owner cannot rule out foreign software interference in the operating system if it had access.
The user is not pestered for admin access to let the software update, it can just do it. Therefore the user can be far,far more suspicious if the "admin rights" dialog appears, the correct answer defaulting to being "no!"
On windows, where introducing new packages is the exception, and the userspace software location is in the hidden AppData/Local/Programs location, use Software Restriciton policies to lock out running anything in other places such as, and especially Downloads, also consider Documents and Desktop, the .exe must then be manually moved before being runnable.
There is maybe one disadvantage, a multi user system might have several copies of the same software. Each user cannot then break each others install though.
The impact of security vulnerabilities is also moved from the scope of the whole host into the executing user. The damage is limited to the user account, rather than catestrophicaly take over the whole system.
This gives the host operating system one last chance to take down software gone rogue.
This part is an improvement, though know because user accounts hold sensitive personal data, it should be improved further by pushing the software into a third layer, basically a container under the user account that cannot access files outside of the container, though it may have network access that the main user account does not have.
In windows this is still very early, as Application Guard exists to do, and for Debian there is control groups such as via systemd --user, and nspawn for system wide
There is some literature from some leading operating systems justifying this:
It is useful to mention that application guard could be considered equivalent to systemd containers in microsoft windows, the next issue is telling apart applications inside app guard from those outside, to be able to deny internet access to an unguarded browser or application.
It is necesseary to unravel the references to "Enterprise",
When there are packages "for" debian than don't have a really good reason, such as interacting with hardware, to be installed in the root account, create a fake debian environment in a systemd --user unit, and install the foreign packages into that. This keeps the host clean(ish) and can allow the proprietary package also to keep up to date.
We set up an environment for google, and another for microsoft. Google contains chrome and extras like earth. Microsoft contains edge and extras like skype and teams.
I managed to do away with debootstrap as the foreign packages generally do not need a full fake environment, the aim is only to get them to install and apply vendor updates whenever they are released.
So, in the real home directory we have ~/.local/internet/${VENDOR}/ where vendor could be google or microsoft, or others
Each contains an inner .local subdirectory which is the base of the fake root.
~/.local/internet/${VENDOR}/.local/etc/apt/apt.conf is used to make apt and dpkg work with the fakeroot, as can be seen set all sorts of nasty stuff with the aim to force success.
Each environment may need a .debconf for further forcing
And a .dpkg.cfg
Various binaries that deb packages try to run in postinst phase or similar, are symlinked to /bin/true, as these may only cause automated install/upgrade/refresh to break when the main reason is to unpack and place the updated content.
Have ~/.local/internet/${VENDOR}/.local/usr/bin/apt-config
The most difficult part was identiying the hack needed for an executable to force its own caller to exit successfully, this goes in .local/usr/bin/xdg-icon-resource and is targeted at the postinst dpkg scripts of google chrome and microsoft edge, to convince dpkg that they and others are installed correctly.
Finally I cloned the host's dpkg status so that the fakedeb believed that many host packages were installed, this is only to satisfy dependencies of the foreign packages.
Then, enter the fake environment with ideally a segregated network namespace, systemd-networkd on my host is set to recognise new br members.
For networkd we have /etc/systemd/network/30-netpit20_guests.network on the host, using a pattern of rt20_* as an example
Now define a systemd unit with the basics for a new ~/.config/systemd/user/vendor.service
Later, when everything is working, the sleep 86400 could be replaced with the actual app launch sequence
Initially starting the unit should cause it to hold in the sleep for a while, to allow the final bits to be checked
As a fake APT is, really complicated, I use a function to enter the namespace for setup and troubleshooting, it is much like firejail --join
Once inside, such as enterit vendor, firstly it is necessary to neutralise chown syscalls like SystemCallFilter=~lchown:0 ~fchown:0, so I paste this lot:
This LD_PRELOAD thus makes chown calls done by dpkg do nothing successfully so it does not crash.
Then, setup APT, update the application via apt-get or aptitude, then test launching it.
Many such sources supply a URL that serves a http redirect (called WHAT= here), to another URL in a cdn that serves the actual content, called WHERE= here
We need an rsa keypair for this, use the host ssh one as key rotation done from time to time.
A line in the containers sources.list to tell it where to pull:
Then a script that the container unit can call just before running apt.
To install, apt gets a sources.list pointing at the directory whereas /etc/apt/trusted.gpg.d/ gets a symlink at trusted.gpg
Here are the 2 units of the helper /etc/systemd/system/netlink1.socket
The route 1 refers to /usr/include/linux/rtnetlink.h 1 = RTMGRP_LINK
the /etc/systemd/system/netlink1.service unit, hunts down all active network namespace and do any custom config that has to happen from root.
In this example, set container own mtu to 65535, as if not needing to cross hardware we can have a huge mtu so just max it out.
Reachability of the internet limited to 1500, and reachability of a site router to some value in between depending on hardware support.
For now discard details from the netlink socket, as link adds and removes are not so frequent to make it essential, though future enhancements could process it for better efficiency.
Both chromium and google chrome support IPv6 well when run like this, despite some things like probing for google public dns, however msedge refused to use ipv6 with a typical 2000::/3 route. I discovered that edge may checks for a default IPv6 route, so to add it, a workaround may be applied inside the edge container or jail:
it is very desirable to install as a non-admin to %LOCALAPPDATA%\Programs\Google as this allows the program to patch without requesting the Administrator password, especially on a single user system. Unfortuately by default the installer will demand the administrator password and not install without it, so try to find a workaround.
Doing the install completely in userspace is better for the system for its maintainability, and also any system issues could not be attributed on google earth.
Normally earth download is excepted to work.
Had downloaded latest=v7.3.1-x64 from direct links. Google may have fixed by the time this is read.
The installer writes the msi file as a GE*.tmp file to %temp%, we quickly snatch it before it is deleted. e.g. rename %temp%\GE*.tmp GE.msi
Now invoke msiexec with this msi file to force a peruser install:
If there is a systemwide install of google earth, remove it firstly so that msi does not refuse to install peruser instances.
Unfortnately a lot of .msi such as wireshark, depend on an optional windows module called visual c++ redistributable, that may not be present o the system at the wanted version, and not deployed automatically via windows update.
The workaround is getting the redists rquested by the application, directly from Microsoft, and then installing those via the Administrator account, even though should be a windows update thing really
Then, for wireshark, use pktmon instead for pacet capture.
A variation of this trick seems to work with sonos desktop controller, extract the msi and run it as above, instead of C:\Program Files (x86)\Sonos\, sonos destop installer correctly offers to install install to C:\Users\user\AppData\Local\Programs\Sonos\
Installer tries to place C:\windows\syswow64\msvcr100d.dll, this may be 32-bit visual runtimne. so checked system for latest runtime, and grabbed 32-bit version for runtime 2013 on windows 10.
A similar method is posisble for userspace debian, for using google earth or chrome deb packages in userspace:
Adobe flash dll would be installed to: C:\Users\user\AppData\Local\Mozilla Firefox\browser\plugins\
msiexec /log test.txt /i flashplayer_win.msi ALLUSERS=2 MSIINSTALLPERUSER=1
I am upgrading to use of systemd userspace unit, it makes a private network namespace, then a veth instance creates a link to the outside world.
The "netns 1" being systemd attaches it to the root namespace where systemd-networkd attaches it to the host bridge.
Then, the user enjoys the ability to configure networking within the namespace. I run dhclient, which can call bird in its scripts, pulling in routes by connecting to a passive BGP server. The container is then ready to use although could be hardened further by dropping more privileges before runnig the target program, such as using a new pid namespace to prevent access to patch in extra veth to the host.
In this example I also use the hexadecimal form of network namespace number as part of the container mac address, this appears to guarantee no conflicts.
,Thus this goes in ~/.config/systemd/user/example.service
Units can still be inspected from outside via nsenter
The bindpaths allows a virtual homedirectory for each app, it may be useful to group them by vendor, so google for chrome, and microsoft for edge
replace xlogo with follow on commands, for chromium derivatives example common for both chrome and edge, start by forcing an update:
Hugepages are also activated for performance, as well as that they are already used for virtual machines
Start chrome
Or start edge