I tried to run some software on my router. It kind of works, if it fits. Storage was the limiting factor. There’s an option to expand the FS to include a USB stick, but somehow it made something overheat, and the router froze every now and then.

I’m running my email server on a POCO F1 ex-Android phone (running PostmarketOS now).

I wish I could get NixOS running on it, then I’d move other things also there.

I’m using VNC over an SSH tunnel. TigerVNC’s vncviewer even has the -via parameter you can use to make creating the tunnel seamless.

Here’s a couple of pointers to get started:

1. The Arch Linux Wiki is full of excellent information. It’s not for beginners, though.
2. Run top in your terminal to see what’s taking CPU.
3. Run top -o RES (or what’s easier, run top and then press M while it’s running) to see what is taking up RAM.

… though unfortunately, it’s mighty probable that the only significant consumer of memory and CPU is your browser. Get uBlock Origin, it helps web pages be lighter and eat less resources. Don’t open too many tabs at once - learn to use bookmarks efficiently, instead (folders, bookmarks toolbar and whatnot).

Reminds me of the programs that make the kernel drop FS buffers in an attempt to free up RAM. Or hog as much memory as they can in an attempt to have unused things swapped to disk. Yeah, they free up RAM all right, but at the expense of actual speed.

Most of the time, this junk is actively harmful. Forget it, modern Linux uses optimized defaults.

You can get more performance out of your hardware by switching to from heavyweight to lightweight programs - for example, instead of Skype (which uses Electron), choose some other way to chat like irssi for IRC. Instead of Gnome, choose i3 or dwm or something like that. You need a bunch of tradeoffs and learning, though, to really get the most out of your hardware.

Windows has a pre-built index as well (or at least it has a search indexer service that enjoys as warm a CPU as possible). That doesn’t appear to improve the speed of search, though.

In Linux, the locate command is crazy fast. I am amazed at how slow search is in Windows, compared to this.

Having an unauthenticated relay imposes the responsibility to configure it correctly (the “only certain addresses” part) and protect it (the “accessible outside the local network” bit). Are you sure it’s not accessible? Did you remember to test with IPv6 too? Will it remain protected after the next time you mess around with your firewall for some totally unrelated reason?

If it works - good for you, but be mindful of all the baggage that comes with a new service.

You’re trading one security issue (profileration of app passwords) to another one (an unauthenticated relay). Is it worth it?

The last time I needed to boot a PC that didn’t have a screen, I built a NixOS installation image with SSH access. I added a user, sudo access, and prepopulated authenticated SSH keys, something similar to https://nixos.mayflower.consulting/blog/2018/09/11/custom-images/

It was about as easy as configuring my own NixOS system.

There you go: https://wiki.archlinux.org/title/Bubblewrap

Environments are per-process. Every program can have its own environment, so don’t inject secrets where they’re not needed.

I’m using bubblewrap to restrict access to FS.

Oh, I totally agree my solution is not “proper” - it’s a homebrewn solution, full of duct tape and shoestrings. That said, it does everything I need to do. Which features of “proper programs” would you be missing? Perhaps I could add them for my own use.

Did gou look into what takes up the most memory? You could downgrade from the modern browser with 500 tabs to netsurf with 500 bookmarks, perhaps, or similar. Many modern websites don’t work there, though.

Instead of Gnome, I’m using Sway, at the moment it’s taking up 236MB resident.

Do you need that mail client to run 24x7? It’s better for mental health to check mail when you decide (once in the morning), not when some rando wants to sell you cannabis oil (best cure for any ailment!) - or you might find something tiny that checks for email and shows a desktop notification, so you know to launch your mail client.

Alacritty likes to munch memory, Foot takes up much less, but Foot doesn’t render some colors correctly, for whatever reason.

Shop around, there are more options than just changing the Matrix client.

I wrote a Bash script that uses rsync to copy data elsewhere.

It gets launched by a systemd timer, but cron would also work. At first it creates a btrfs snapshot of source, for consistency’s sake.

Then it copies stuff. It’s incremental, ie. unchanged files get hardlinked, not copied (-link-dest against the latest symlink) into date-specific directories that present the full view of the filesystem.

Finally, it cleans up the source snapshot and rewrites the latest symlink to point to the freshly made copy, if successful.

I could share my script, if there’s interest, tho it might look a bit messy. Oh, and these rdiff-whatchamacallits probably do the same thing in a more professional manner. I wrote mine to learn rsync.

Not saying my practice is the best one, but here’s what I do:

• EFI system partition is mounted on /boot
  • kernel is held here. In case of distros like NixOS etc that keep around old kernels, a small ESP might run out of space. I make mine at least 1GB.
• the rest of the disk is one luks2 volume
• inside the encrypted volume, there’s a BTRFS volume
• there’s a subvolume for /home
• and a subvolume for every distro I have (which is usually 1, but sometimes I tinker or switch)
• Kernel command line parameters specify the btrfs subvol with the right distro to boot.
• for NixOS, you need a bootloader (to choose the right kernel). Systemd-boot works well, and its configuration is easily readable. I never figured out how to work with GRUB2, its configuration is just too confusing.
• or if you like Arch, dispense with bootloaders and just use EFISTUB. You can put kernel cmdline params into EFI bootloader options with efibootmgr.

Simple yet complete. Efficient, and extensible - for example, now that everything is a subvolume, I can easily snapshot it, then create backups with rsync off the snapshot, to avoid inconsistent state between backed-up files.

Here it comes: https://paste.ee/p/voTFI

Note that I’m no Bash expert, and you’ll undoubtedly find ways to improve or fix it. Usage:

• Run stuff in a sandbox isolate bash - and then verify your access to filesystem is restricted
• Enable Xorg for apps that need it X=1 isolate mindustry
  • Wayland, which naturally isolates apps from each other, is enabled by default.
• Enable network for apps that need it: NET=1 isolate curl https://ip6.me/api/
• Enter the sandbox to mess around with it manually: NAME=mindustry isolate bash
  • Note that it doesn’t catch Ctrl-C. Ctrl-C kills the isolated Bash.
• Populate data (installers and whatnot): NAME=mygame isolate ls; cp installer.sh ~/.local/share/bubblewrap/mygame/; NAME=mygame isolate bash

Interesting, could you please elaborate?

1. What exactly is this “built in sandbox”, and what does it protect against? How does it compare with Flatpak disallowing access to filesystem?
2. Could we get a source for the claim of sandbox being crippled? Or more details? Documentation? Build scripts?

I had a look at flatpaks I have installed:

• Firefox (org.mozilla.firefox): no access to ~

• Thunderbird (org.mozilla.Thunderbird): no access to ~

• Element (im.riot.Riot): no access to ~

• Beyond All Reason (info.beyondallreason.bar) - no access to ~

• Steam (com.valvesoftware.Steam) - no access to ~, and (best of all) Steam runs a ton of untrusted code in games, which will inherit this restriction.

• Wolfenstein: Blade of Agony (com.realm667.Wolfenstein_Blade_of_Agony) - no access to ~

• Chromium (com.github.Eloston.UngoogledChromium): allows access to ~ by default. It’s one click to disable, or I could shop around for another one, like org.chromium.Chromium.

• OpenTTD (org.openttd.OpenTTD) - allows access to ~

Thus, yeah, some apps neglect to restrrict ~, thankfully it’s easy to fix. It’s not a disadvantage, though, it’s a lack of advantage.

Indeed, Flatpak is its own repo. It might be more, or it might be less up to date than your favorite distro. Debian, for instance, was once notorious for packaging ancient versions (tho this has improved lately).

The saving grace of Flatpak is that it’s still better isolated.

If native Chrome decides to start emitting your crypto wallet’s privkeys as a part of its push for Better Customer Experience and More Precisely Targeted Ads, you won’t even know or notice it. This is technically very easy to do. It might make itself hard to dislodge by injecting itself into ~/.bashrc or the desktop environment’s startup system, or Systemd services.

If Flatpakked Chrome starts misbehaving, it might mine crypto on your CPU (wasting your electricity), or rent out all your disk space, or turn your PC into a node in a botnet, but it won’t have access to read or write anything other than your ~/Downloads. It’s also easy to uninstall, as it hasn’t had a chance to spread its seed.

Sorry for the long rant… What was the original question again? Outdated dependencies? Not an expert, but I hear the whole reason AppImage, Snap, FlatPak, Yarn locks and Go language was invented was to make it easier to have outdated dependencies. You never know what’s available in $Distribution, you depend on goodwill of maintainers of $Distribution to package your app and all deps. In AUR you can find older versions of Lua libs (lua51-filesystem) which someone had to add to make Mudlet run - Mudlet didn’t see fit to upgrade to the latest Lua.

While it is indeed somewhat true that a library (that many apps depend on) can be patched to fix a security issue, and apps won’t need to be rebuilt, it only works if the lib was a sufficiently recent version. And if the distro maintainer is more diligent than the Flatpak maintainer. Otherwise, the authors of said lib are going to ask you to upgrade to a supported version where that bug has already been fixed, defenestrating the whole argument-in-favor. This completely breaks down in NixOS, too, where your package would get rebuilt from source as inputs changed.

There’s plenty of good advice in other comments in this topic. Let me add mine too, something I haven’t seen in other comments: You need to figure out your threat model, and steer your course accordingly.

Who do you trust?

• No one? Don’t use a computer. Use an airgapped computer without any internet connection. Write your own OS (but be mindful of bootstrapping issues, you’ll also need to write your own compiler to protect against Thompson’s hack). It’s a hassle.
• Original authors of software? Compile and install all software from source. Consider using LFS. It’s a hassle.
• Maintainers of my operating system of choice? Only install packages from official package repositories (apt in Debian, pacman in Arch, you know the drill). Eschew any others, like PPA in Ubuntu, AUR in Arch. Though package maintainers don’t necessarily review any package updates, there’s a chance they just might. Though package maintainers are in the position to inject backdoors during packaging, this is somewhat unlikely as packaging scripts tend to be small and easy to review.

What risky activities are you doing?

• Running random crap software downloaded from the internet?
  • Run it in a virtual machine. It’s easy to install another Linux into a VM - you could try VirtualBox or qemu or libvirt or some other one.
  • Containerize it with Docker, or run it in Firejail or Bubblewrap
    • Don’t mount your home directory, or anything other important into the container. Instead, if you need to pass data, use a dedicated directory.
    • It’s easy to restrict internet access to a program, when running it in Docker or Bubblewrap.
• Running the same as root? I’m pretty sure a full virtual machine would be the only secure option to do that, and I’m 100% certain even that would be enough.
• Running large software that probably ought to be OK, but you never know for certain? This is what I normally do:
  • Use the Flatpak version, if available. Check its permissions (e.g. with Flatseal), you might be able to tighten the screws. For example, a browser (yes, Firefox, Thunderbird, Chromium are available as Flatpaks. Even Chrome is) is plenty large enough for any number of security bugs to hide in. Or a backdoor, which might be crafted to be indistinguishable from a honest bug.
  • If there’s no Flatpak version available, I Bubblewrap it.

I have a simple Bash script that restricts apps’ view of my filesystem, and cuts off as much stuff as possible, while retaining the app’s ability to run. Works with Wayland and console apps, optionally with Xorg apps if I set a flag. Network access requires its own flag.

I could share my Bubblewrapping script, if there’s interest.