upvote
And it's a proper way to use computer nowadays.

Apart from high-overhead solutions like VMs and containers, there are seamless and maintenance-free solutions (after the initial setup):

- systemd service hardening [0] [1]

pretty powerful, but it's a blacklist approach - whack-a-mole

- AppArmor [2]

Whitelist, proactive approach. Contrary to SElinux, it's not a programming language, and could be grasped pretty quickly. I made a tool to easily convert AA logs into usable rules. [3]

[0] https://github.com/alegrey91/systemd-service-hardening

[1] https://github.com/desbma/shh

[2] https://presentations.nordisch.org/apparmor/

[3] https://github.com/nobody43/apparmor-suggest

reply
> How do other people handle this dilemma?

For me: consider this a form of paranoia and ignore it, while worrying more about cleanup costs of non-vetted packages.

Like, even if there is 5% chance that a program I download will start downloading global python or node packages, odds are within a year I'll deal with couple that have mutually incompatible requirements and are impossible to run without more VM surgery than I have patience for, and that I'll discover this only after a botched installation bricks software that used to work before.

But that's solvable with less extra work. Just throwaway containers. With no hand-wringing about read-only access or isolating it from network, because my threat modeling doesn't consider loss of privacy or any data leak from my personal local side to be realistic or impactful threat event (I mean, everything that matters is in someone else's cloud and by design not trivial to access) - OTOH, it assigns great magnitudes to loss of personal time.

reply
Clone the repo and ask your llm of choice to audit any security risks
reply
After that I run them in containers, no network access, ro filesystem.
reply
And then build from source. And make sure it doesn't auto-update so no new malware gets in. This is my idea of a lot of extra work.
reply
Why even ask the question?
reply
Building from source is nowadays writing one sentence in a chat box. Your idea of extra work is either unbelievably lazy or perhaps outdated by a few years.
reply
good luck auditing all transitive dependencies
reply
I think the best answer lies somewhere in compartmentalization and fine-grained permissions. In this case: run it in some kind of secure container which has access to read browser history, and write to its database, but definitely does not have network access.

Unfortunately there's no one-size-fits-all solution for this yet, but there are a lot of groups attacking it from different angles: Qubes, GrapheneOS, Firejail, Bubblewrap, Android/iOS app permissions, Landlock, App Sandbox, etc.

reply
> ...run it in some kind of secure container which has access to read browser history, and write to its database, but definitely does not have network access.

We should be doing this with all software, regardless of provenance, anyway. Least privilege applies to servers just as much as it does to users. Even if the software isn't untrustworthy you can be it has vulnerabilities.

My first go-to is network segmentation because I spend most of my time doing networking work. For every vendor who has shit-talked me to Customers ("Wah, wah! Your networking vendor is making this so much harder because they want us to enumerate our traffic!") I have concrete examples I can cite when attacks were stopped by network segmentation (preventing shellcode from downloading a payload, preventing C2 communication, firing off alerts when unexpected network traffic starts coming out of a host, etc).

Beyond network segmentation, I am very suspicious of software that needs to run as a privileged user. So many attacks get easier when privilege escalation in the host OS is already done for you.

reply
Distro maintainers aren’t infallible either. At the end of the day it’s up to you to decide where and how much trust you place and do your due diligence from there.

One thing that can be helpful when reasoning about things like this is figuring out what your actual threat model is. What does system compromise look like to you? Data exfiltration, arbitrary code execution, something else?

reply