Hacker News new | ask | show | jobs
by TheDong 1537 days ago
> i'm trying to make a list of these services (and maybe disable them) to minimize my footprint (often testing out untrusted code from github etc in a small secretive community, ie easy to target)

If you're running a lot of "untrusted code from github", then the list of services you have enabled or disabled on your system isn't going to make a difference.

For someone who frequently runs untrusted code, I'd recommend learning any of:

1. qemu / virsh / how to quickly and efficiently spin up isolated VMs

2. ec2/GCP/digital ocean/any similar VPS provider

3. QubesOS https://www.qubes-os.org/

The first two options will be a more secure way to run untrusted code and provide actual protection. The 3rd has better usability, though isn't as secure.

Disabling local thumbnailing services... yeah, sure, do that, but don't expect it to really do much against "testing out untrusted code".
2 comments
axytol 1537 days ago
Some good tips on running untrusted code in VMs. If possible I'm interested to learn why you consider qemu based VMs as more secure than QubesOS? If I get it right QubesOS is Xen based so is it about the hypervisor or something else that favours qemu in your opinion?
link
TheDong 1537 days ago
QubesOS inherently has a higher attack surface due to the features it's added to be more usable.

An AWS VM in the cloud I ssh into can't possibly snoop on another window I have open.

QubesOS on the other hand includes usability features like displaying graphical interfaces from VMs, clipboard sharing features, etc etc https://www.qubes-os.org/doc/gui/

These usability features increase attack surface, whether they're implemented on top of a Xen or KVM hypervisor.

My assumption for a local qemu setup is that the user wouldn't use things like 9p or display sharing, which I think means a smaller enough attack surface to make a difference.

link
nqzero 1534 days ago
i explicitly said "if the user executes ... they're powned" and never said anything about "running". you're implying i'm taking far more risk than i am

i'm trying to understand (and minimize, if needed) the automated risks of having untrusted files *stored* locally, which would give me time to read them and develop a level of trust

fwiw, if i need to run something untrusted, i'm using #2 some, but mostly:

  4. a 2nd (untrusted) machine running locally, which is beefier than my laptop and also used for benchmarking.
     i've never seen any unusual behavior from it, but treat it as though it's compromised
link