Re: Is PROT_SOCK still relevant?

[Jason Newton]

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Is PROT_SOCK still relevant?

[Jason Newton]

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 <nev...@gmail.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 <nev...@gmail.com> wrote:
>> On Mon, Dec 14, 2015 at 2:39 PM, One Thousand Gnomes
>> <gno...@lxorguk.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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Is PROT_SOCK still relevant?

[Jason Newton]

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Is PROT_SOCK still relevant?

[Jason Newton]

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 <nev...@gmail.com> wrote:
> On Mon, Dec 14, 2015 at 2:39 PM, One Thousand Gnomes
> <gno...@lxorguk.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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Is PROT_SOCK still relevant?

[Jason Newton]

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Is PROT_SOCK still relevant?

[Jason Newton]

On Mon, Dec 14, 2015 at 10:25 AM, One Thousand Gnomes
 wrote:

>> Is there disagreement on my views or points?
>
> Yes 8)
>
> You don't really want someone racing you to set up a fake ssh service on
> your system to steal all the passwords do you ?
>
> Alan

Hasn't been a problem yet, for me.  I use security layers/frameworks
when applicable and I want such protections.

Further if starting from any [decent] init system, the right sshd
should start, bind, and go daemon before any fake ssh service can be
started by a user, meaning no race condition - you might point out
though if the program crashes, the same unsafe pickle exists.  Of
course we've already went down the road of a compromised system,
there's probably bigger problems in such a scenario.  We've got higher
number "standard" ports these days which aren't offered protection on
this range too, 8080 comes to mind - nmap sure makes use of them.

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.

Or how about letting port number concerns be handled by those security
frameworks all together considering it is limited security?

-Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Is PROT_SOCK still relevant?

[Jason Newton]

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Is PROT_SOCK still relevant?

[Jason Newton]

On Mon, Dec 14, 2015 at 10:25 AM, One Thousand Gnomes
 wrote:

>> Is there disagreement on my views or points?
>
> Yes 8)
>
> You don't really want someone racing you to set up a fake ssh service on
> your system to steal all the passwords do you ?
>
> Alan

Hasn't been a problem yet, for me.  I use security layers/frameworks
when applicable and I want such protections.

Further if starting from any [decent] init system, the right sshd
should start, bind, and go daemon before any fake ssh service can be
started by a user, meaning no race condition - you might point out
though if the program crashes, the same unsafe pickle exists.  Of
course we've already went down the road of a compromised system,
there's probably bigger problems in such a scenario.  We've got higher
number "standard" ports these days which aren't offered protection on
this range too, 8080 comes to mind - nmap sure makes use of them.

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.

Or how about letting port number concerns be handled by those security
frameworks all together considering it is limited security?

-Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Is PROT_SOCK still relevant?

[Jason Newton]

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Is PROT_SOCK still relevant?

[Jason Newton]

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/