Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932208AbbLNUnd (ORCPT ); Mon, 14 Dec 2015 15:43:33 -0500 Received: from mail-io0-f174.google.com ([209.85.223.174]:34802 "EHLO mail-io0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932119AbbLNUnc (ORCPT ); Mon, 14 Dec 2015 15:43:32 -0500 MIME-Version: 1.0 In-Reply-To: <20151214193954.10f3b0fc@lxorguk.ukuu.org.uk> References: <20151214152508.21394030@lxorguk.ukuu.org.uk> <20151214193954.10f3b0fc@lxorguk.ukuu.org.uk> Date: Mon, 14 Dec 2015 15:43:31 -0500 Message-ID: Subject: Re: Is PROT_SOCK still relevant? From: Jason Newton To: One Thousand Gnomes Cc: 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: 2556 Lines: 50 On Mon, Dec 14, 2015 at 2:39 PM, One Thousand Gnomes wrote: >> Perhaps lets consider this in another way if it is strongly held that >> this is worth while in the default configuration: can it default off >> in the context of selinux / other security frameworks (preferably >> based on their detection and/or controllably settable at runtime)? >> Those allow more powerful and finer grain control and don't need this >> to be there as they already provide auditing on what operations and >> port numbers should be allowed by what programs. > > That would be a regression and a very very bad one to have. The defaults > need to always be the same as before - or stronger and never go back > towards insecurity, otherwise they could make things less safe. Even if you don't think it should be default, there's still a case having a knob for leaving it to the auditing framework to deal with it, or perhaps sysctl tunable ranges like on FreeBSD. That way none of the workarounds mentioned have to be invoked and tuned, which increases maintenance and setup burden. On some systems, these methods may not be available, too. Android is one that comes to mind. I openly stated this issue has been brought up for me *this time* due to Android, but it still does keep coming up. It's on my Linux Kernel bucket list to get it addressed/tunable. This isn't isn't going to be changed and make it to where it matters for me this occurrence with any practical timing - but I'm trying to prevent the next occurrence I'll have with it - and its not in my expectations it'll be Android at that point. > >> Or how about letting port number concerns be handled by those security >> frameworks all together considering it is limited security? > > There are already half a dozen different ways to handle it from xinetd > through setcap, to systemd spawning it, to iptables. Most (all?) of those methods have sacrifices as previously noted: Systemd isn't everywhere still and may never be, setcap doesn't work with java/python and the like, iptables has significant performance loss when scalability is important and increased configuration detail... never tried with xinetd. Is one of these the sure fire way or should we be happy we have so many choices with each their own caveats? -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/