Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752613AbbLNQNZ (ORCPT ); Mon, 14 Dec 2015 11:13:25 -0500 Received: from mail-ig0-f182.google.com ([209.85.213.182]:36995 "EHLO mail-ig0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752037AbbLNQNY (ORCPT ); Mon, 14 Dec 2015 11:13:24 -0500 MIME-Version: 1.0 In-Reply-To: <20151214152508.21394030@lxorguk.ukuu.org.uk> References: <20151214152508.21394030@lxorguk.ukuu.org.uk> Date: Mon, 14 Dec 2015 11:13:23 -0500 Message-ID: Subject: Re: Is PROT_SOCK still relevant? From: Jason Newton To: One Thousand Gnomes Cc: linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1787 Lines: 41 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/