Gregory's Server@dalias @leftpaddotpy I am not sure, why would you want to lock a process into separate namespace with a VPN. In most cases I *want* site-enabling VPN to modify *global* system configuration. I just want to choose which parts this VPN can provide, for example limiting it to only selected domains. It would be nice to have simpler ways to bind a service to just one network interface, but I don't need it often.
|
5 comments
@dalias @leftpaddotpy I think general assumption is once local machine is compromised, security falls apart. I would say untrusted nobody user (and it's services) should have filtered access to the system network. Especially if you run a code without trusted source from it. Sort of podman solves it. Okay, it would be nice to restrict domains and IP ranges such process can access. I don't know anything simple offering that.  @pemensik @leftpaddotpy If that's true, sounds like really, really bad news for most Android users... @dalias @leftpaddotpy who said VPN server on Android cannot filter out ads or unwanted traffic? I think iptables should be able to filter based on userid or pid. I admit it would be great for flatpaks also. Name resolution usually does not have user or pid information for each request, it would have to use Unix socket instead of IP+port domain. So it would be difficult to apply ACL on those. But having alternative DNS cache on non-default address would be simple. @dalias @leftpaddotpy Android apps have good sandbox from other users. Each app is separate user there. Unless given rights to media access, they are well separated. Except network and DNS, correct. I would not expect Google to make ads blocking trivial task for obvious reasons. |
@pemensik @leftpaddotpy I was speaking more with sn assumption of a privacy providing VPN where you don't want any traffic to leak. But a site-enabling VPN also makes sense to scope only to processes meant to have access. A compromised nobody account shouldn't have access to VPN your user account has access to.