Message-ID: <56719897.4090902@gmail.com>
Date:	Wed, 16 Dec 2015 12:00:07 -0500
From:	"Austin S. Hemmelgarn" <ahferroin7@...il.com>
To:	Jason Newton <nevion@...il.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Is PROT_SOCK still relevant?

On 2015-12-16 09:52, 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.
It would be a lot easier from an administrative perspective than having 
to do any of:
1. Use systemd, and hope your software supports interacting with it 
properly (oh, wait, part of the point of this is embedded systems, so 
this option can be immediately thrown out the window because it's almost 
as bad for efficiency as iptables).
2. Install and configure xinetd or something similar, and then hope your 
server is actually compatible with inetd semantics (and most aren't 
these days, although that may hopefully change, ironically because of 
systemd).
3. Configure iptables (it's not hard, but it is tedious, and it's 
_really_ inefficient even for just protecting a few dozen ports).
4. Install and configure some other port reservation software.
5. Configure SELinux or some other LSM to do it for you.

I have no idea how hard this might be to do on the kernel side, although 
I have a feeling that at the very least making it a single configurable 
range is not likely to be difficult.
>
> Do we need a default list?  What would the contents be if so?  [0,
> 1024)?  {22, ...}? {}?
If we want to keep compatibility, we should default it to all ports less 
than 1024, and this definitely falls under the category of user visible 
ABI.  (There should be nothing that depends on these ports being 
accessible via CAP_NET_ADMIN other than some ancient NFS security 
designs, and if some software _does_ depend on this, I'd seriously 
question the intelligence of the developers.)
>
> 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?
I like the idea of using sysctl for this, it makes it easy for the 
administrator to dynamically change things at runtime without needing 
some special program to do so.
>
> -Jason
>
> On Mon, Dec 14, 2015 at 3:43 PM, Jason Newton <nevion@...il.com> wrote:
>> On Mon, Dec 14, 2015 at 2:39 PM, One Thousand Gnomes
>> <gnomes@...rguk.ukuu.org.uk> 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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

--
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