Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751630AbbLNOVe (ORCPT ); Mon, 14 Dec 2015 09:21:34 -0500 Received: from mail-io0-f182.google.com ([209.85.223.182]:33838 "EHLO mail-io0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751019AbbLNOVd (ORCPT ); Mon, 14 Dec 2015 09:21:33 -0500 MIME-Version: 1.0 Date: Mon, 14 Dec 2015 09:21:33 -0500 Message-ID: Subject: Is PROT_SOCK still relevant? From: Jason Newton To: linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2684 Lines: 50 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/