Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751436AbbLUTEg (ORCPT ); Mon, 21 Dec 2015 14:04:36 -0500 Received: from mail-oi0-f44.google.com ([209.85.218.44]:36860 "EHLO mail-oi0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750870AbbLUTEc (ORCPT ); Mon, 21 Dec 2015 14:04:32 -0500 MIME-Version: 1.0 In-Reply-To: References: <20151214152508.21394030@lxorguk.ukuu.org.uk> <20151214193954.10f3b0fc@lxorguk.ukuu.org.uk> Date: Mon, 21 Dec 2015 14:04:32 -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: 3935 Lines: 87 I can only assume from lack of criticism that either: 1) This is a completely great idea with no cons and thus worthy of time to implement or 2) The topic has been ignored Is it reasonable to allocate a 8KiB buffer for a bit vector covering 2*16 ports? Should I instead just focus on a list/container to have a smaller foot print in the average case? Regards, Jason On Wed, Dec 16, 2015 at 9:52 AM, Jason Newton wrote: > How about changing how this mechanism works from a range of the lowest > N ports and instead have it as a user specifiable set? Towards more > proper security, this allows distros/admins to put any ports they > consider important to have security feature going well beyond the > current limit without recompiling the kernel. > > It may make more sense to make this protocol specific too but I'm not > sure if that would be so simple to implement and manage. > > Do we need a default list? What would the contents be if so? [0, > 1024)? {22, ...}? {}? > > Would there be any special considerations needed for the set > container? How about a hash table? 2^16-1 uchar bool vector? > > In terms of setting/initializing - sysctl? > > -Jason > > On Mon, Dec 14, 2015 at 3:43 PM, Jason Newton wrote: >> 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/