Messages in this thread | | | Date | Mon, 14 Dec 2015 09:21:33 -0500 | Subject | Is PROT_SOCK still relevant? | From | Jason Newton <> |
| |
I've noted through years difficulties in getting programs in java or python to work in Linux correctly when binding to a "privileged port", requiring various forms of hoop jumping (use of capabilities, iptables redirection, authbind, and the classic newbie mistake of running the program as root) and the workarounds are all lacking being/having: nonstandard, security risks, performance losing, and other issues. Capabilities has been my usual preference, but that is mainly for C or C++ applications with a single program file. Capabilities can't be, in general, used correctly on java/python type programs which are ran under are loaded by said executables - instead any program loaded with those binaries would get that capability. authbind last I looked also didn't support ipv6 and I've had it introduce hard to solve issues before despite its simple looking appearance. iptables comes with a performance penalty but is typically the preferred easy method. There are other ways that haven''t listed and my knowledge of them is poor, although I see systemd offers yet another way to do this.
At the moment I'm having troubles with SNMP and port restrictions on Android, following back to this - and every year or 2 this problem rears its ugly head again for me for the last 10. This time I can't figure out a solution because root is not a normal thing in android unless you're running a custom rom and none of the other workarounds are applicable.
So it's been quite some time since this topic was covered in any capacity, and it's worth asking now: does it make sense to keep this ancient security bit around? Does it make a modicum of improvement to the security and well-being of systems and the internet or at least enough to justify itself? Is this something that will break legacy programs by removing? How about we switch it to disabled by default and see who squawks.
To be frank, I wish it gone and haven't seen any tangible benefits to systems I've administered - SELinux/AppArmor and iptables with reject/drop by default go whole lot further in my than this simple restriction ever did and I think many people aren't bothering with the "proper" workarounds simply because there's no single one to go to that covers all cases or the issue is written off as nonsense - so they end up running as root and creating far worse problems for security.
Is there disagreement on my views or points?
Best Regards, -Jason
| |