Message-ID: <CAGou9MgOea+7dXqrqYWzpuaa=G_FXAW8zsZRkS5Wxyjak5bvMg@mail.gmail.com>
Date:	Mon, 14 Dec 2015 09:21:33 -0500
From:	Jason Newton <nevion@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Is PROT_SOCK still relevant?

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists