linux-kernel - Re: Is PROT_SOCK still relevant?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGou9MgKL7ff7Wr97U8xm3LuYBYRb02SGsho0x17tzkjEAgJPg@mail.gmail.com>
Date:	Mon, 14 Dec 2015 11:13:23 -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?

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.

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