Date:	Mon, 14 Dec 2015 13:29:53 -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-14 11:13, Jason Newton wrote:
> On Mon, Dec 14, 2015 at 10:25 AM, One Thousand Gnomes
> <gnomes@...rguk.ukuu.org.uk> 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.
Agreed, if someone is able to hook into early boot such that they can 
start their own version of a regular system daemon, then either:
1. Your system is already compromised, and they can almost certainly 
bypass the protections this offers.
2. Your system is so poorly designed that almost any appearance of 
security is likely false.

However, there is an issue when you restart the SSH daemon (or any other 
daemon that is a security risk), in that it's possible to race there and 
bind the port before the new instance of the daemon starts.
>
> 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.
This is well worth considering, and it's also worth pointing out that 
those ports have come into common use _exactly because of this security 
feature_.

It's also worth noting that one of the common arguments I hear for this 
protection is to prevent people from running their won versions of 
services that the system isn't supposed to be providing, but that 
argument is pointless because any reasonable system these days has a 
properly configured firewall.
>
> 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?
IMHO, requiring someone to be using a generic LSM for something like 
this is not a good idea, unless it's implemented as it's own LSM which 
can be stacked with modules that don't include this functionality (or 
used by people who don't want all the complexity and administrative 
overhead that SELinux and other MAC systems bring).
--
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