Hacker News Reader

Comment by XorNot | Hacker News Reader

This looks spectacular! Finally! This is functionality I've desperately wanted on Linux desktop. Link that up with with some of the SELinux on-demand tools and you have a plausible way to run untrusted binaries without the overhead of completely containerizing them up front.

View on HN

Be careful with that one, this isn't as capable as the HIDS solutions available on Windows - it's not going to do things like detect exfiltration using other executables or modification of other files on your system.

For example, if you allowed curl or Firefox, another executable can simply call one of them and send/receive whatever data they need to. It also can't do things like filter ptrace calls which could easily be used to modify another process to perform exfiltration or just spawn another thread and inject a whole new dynamic library to them, a common practice to bypass detection on Windows.

Windows app firewalls had similar problems, most common was to use explorer.exe

Just block explorer.exe with windows firewall - if really needed just enable out going access for internal subnet only.

There is not need for explorer to access internet!

I only allow windows defender, firefox and chrome to access internet in my home computer setup all other apps are blocked unless truly needed.

If you block svchost.exe from internet access with windows firewall, it will block the windows update. Enable it once in a while to allow the windows update to go thru when you feel the need.

How does Windows prevent this type of bypass? It seems extremely hard to prevent in an unsandboxed environment.

Windows itself does not, 3rd party firewall/HIDS software (ZoneAlarm, Outpost, etc) for Windows has done this by intercepting APIs to do things like call executables with internet access, OpenProcess calls, raw disk IO, registry writes to startup entries, etc.

I'm not sure what they are talking about, but windows comes with a built-in sandbox now. Adds a little bit of overhead, but besides that works very well.

I guess one might try to check the path through the process tree to see if a blacklisted application is the parent (or gp, ggp, etc.) of the process trying to communicate with the outside world.

I considered that but IIRC browsers like firefox will accept to load an URL without creating a new child process.

For instance if I type "firefox 'http://google.com'" in my terminal my already-running firefox instance loads the URL in a new tab, so I assume that some kind of IPC is used behind the scenes to ask the main instance to load the URL. Of course that's harder to exploit nefariously than spawning wget from the same process but when there's a will there's a way...

without the overhead of completely containerizing them up front.

What overhead? `docker run --rm -it -v $PWD/untrustedprogram:/untrustedprogram:ro ubuntu:latest`, done. Use x11docker if needed.

> `docker run --rm -it -v $PWD/untrustedprogram:/untrustedprogram:ro ubuntu:latest`

Not sure if running a program as root in a container is the best approach to "fully sandbox" - depends on what the goal is, obviously.

This isn't upvoted enough. I use that trick verbatim to just wrap a container's execution environment around my $PWD. It's useful way beyond just isolating a program.

I've used `alias shit='docker run --rm -it --entrypoint /bin/sh -v $PWD:/workdir -w /workdir'` for a long time. This way, whenever I need, I can just run `shit alpine` or `shit ubuntu` or whatever.

I have the same as dri (docker run interactive) and dri_cwd so current directory only mounts intentionally (with dri_cwd)

The overhead of keeping a separate copy of the OS, presumably.

Wouldn’t you need something like gvisor and or running under a different user or podman to make this really safe? If you don’t trust the binary they can still just break out the container.

Container escape isn't supposed to be that easy these days, but yes there is a tradeoff between security and convenience and performance. I was objecting to the claim of overhead in using a container; if you need more protection than you can get on the same kernel then you'll pay for it in virtualization costs (granted, that's not super high anymore either).

That's a lot of overhead if you don't already have docker installed, don't have the the ubuntu image installed, etc.

So Docker is a zero cost solution now?

What do you mean by "SELinux on-demand tools"?

I think AppArmor would be a better use-case for that.

With it you can write a security profile containing a rule like:

   network tcp src 192.168.1.1:80 dst 170.1.1.0:80

Networking access is just the start, you can restrict many other stuff, like access to dbus, files, signals, etc.

What overhead are you worried about?

firejail?

I don't see any port-based firewalling options in the firejail documentation from a quick look. So I'm not sure if firejail helps the same use case as EBPFSnitch.

It can isolate applications into separate network namespace (i.e. no access to host services) with or without internet access and also load separate netfilter rules. No convenience arguments for port filtering though.

Reply on news.ycombinator.com