Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752790AbdFTVnp (ORCPT ); Tue, 20 Jun 2017 17:43:45 -0400 Received: from mail-lf0-f68.google.com ([209.85.215.68]:34802 "EHLO mail-lf0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752338AbdFTVnl (ORCPT ); Tue, 20 Jun 2017 17:43:41 -0400 MIME-Version: 1.0 X-Originating-IP: [108.49.102.27] In-Reply-To: <1497989063.12069.18.camel@tycho.nsa.gov> References: <20170619213348.2970-1-aranea@aixah.de> <1497989063.12069.18.camel@tycho.nsa.gov> From: Paul Moore Date: Tue, 20 Jun 2017 17:43:38 -0400 Message-ID: Subject: Re: [PATCH] selinux: Assign proper class to PF_UNIX/SOCK_RAW sockets To: Stephen Smalley Cc: Luis Ressel , James Morris , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov 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: 1618 Lines: 39 On Tue, Jun 20, 2017 at 4:04 PM, Stephen Smalley wrote: > On Tue, 2017-06-20 at 15:49 -0400, Paul Moore wrote: >> On Mon, Jun 19, 2017 at 5:33 PM, Luis Ressel wrote: >> > For PF_UNIX, SOCK_RAW is synonymous with SOCK_DGRAM (cf. >> > net/unix/af_unix.c). This is a tad obscure, but libpcap uses it. >> > >> > Signed-off-by: Luis Ressel >> > Acked-by: Stephen Smalley >> > --- >> > security/selinux/hooks.c | 1 + >> > 1 file changed, 1 insertion(+) >> >> My only concern is what effect this will have on existing policy. >> Prior to this patch PF_UNIX/SOCK_RAW will result in the generic >> "socket" class where after this patch it will result in the >> "unix_dgram_socket". I believe this is the right change, but it >> seems >> like this should be wrapped by a policy capability, yes? > > I doubt it is worth a policy capability. Agreed that a policy capability is pretty heavy for something to have little impact, I'm just trying to be a bit more consistent about these things (reference the thread we had a few weeks ago). > Permission to create/use > socket tends to be far rarer than permission to create/use > unix_dgram_socket; looks like we never allow the former without the > latter in Fedora, for example. Considering where we are at with respect to the merge window, let's shelve this for now and I'll merge it after the next merge window closes. In all likelihood I'll be sending selinux/next up to James later this week and I'd like this to sit in linux-next for longer than a few days. -- paul moore www.paul-moore.com