Add permission to allow access to /proc/net/

[edpotter]

Netguard requires access to /proc/net/{tcp,tcp6} in order to perform some of its functionality, like allowing the user to get alerts about net access, show which hosts an app is connecting to or filter network access.
Due to /proc/net/ being blocked by default, these don't work on CopperheadOS. It looks like Netguard recently realized this, and added some checking in M66B/NetGuard@7883988 .

Would it be possible enable Netguard by doing something like tying the blocking of /proc/net/ to another android permission (view network connections?) or adding a per-app toggle?

To the best of my knowledge, there is currently no other solution available on CopperheadOS for preventing apps from phoning home, so this is what I've been using.

Thank you for all your hard work making a Secure & Private Android!

[thestinger]

Nope, since I don't think this is the right way to approach implementing a firewall. If there's a use case I consider valid, I'll consider it.

[thestinger]

Nope, since I don't think this is the right way to approach implementing a firewall. If there's a use case I consider valid, I'll consider it.

[thestinger]

If people want to start having user control over firewall functionality, they'll need to step up and work on it. The VPN service doesn't work well for this at all and means not being able to use an actual VPN. It just doesn't make sense. I look forward to seeing a proper firewall implementation not depending on hacks like injecting firewall rules outside of netd via the additional attack surface of root access or abusing the VPN API. Since no one has even looked into working on it, I have to assume that it's a very low priority for everyone.

[thestinger]

If people want to start having user control over firewall functionality, they'll need to step up and work on it. The VPN service doesn't work well for this at all and means not being able to use an actual VPN. It just doesn't make sense. I look forward to seeing a proper firewall implementation not depending on hacks like injecting firewall rules outside of netd via the additional attack surface of root access or abusing the VPN API. Since no one has even looked into working on it, I have to assume that it's a very low priority for everyone.