lkml.org 
[lkml]   [2015]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Is PROT_SOCK still relevant?
From
Date
On 2015-12-14 11:13, Jason Newton wrote:
> On Mon, Dec 14, 2015 at 10:25 AM, One Thousand Gnomes
> <gnomes@lxorguk.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).


\
 
 \ /
  Last update: 2015-12-14 20:01    [W:0.102 / U:3.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site