Date:	Mon, 21 Dec 2015 14:04:32 -0500
From:	Jason Newton <nevion@...il.com>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Is PROT_SOCK still relevant?

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 <nevion@...il.com> 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 <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/

Powered by blists - more mailing lists