linux-kernel - Re: [PATCH] selinux: Assign proper class to PF_UNIX/SOCK

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]

Date:   Tue, 20 Jun 2017 17:43:38 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Stephen Smalley <sds@...ho.nsa.gov>
Cc:     Luis Ressel <aranea@...ah.de>,
        James Morris <james.l.morris@...cle.com>,
        linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org, selinux@...ho.nsa.gov
Subject: Re: [PATCH] selinux: Assign proper class to PF_UNIX/SOCK_RAW sockets

On Tue, Jun 20, 2017 at 4:04 PM, Stephen Smalley <sds@...ho.nsa.gov> wrote:
> On Tue, 2017-06-20 at 15:49 -0400, Paul Moore wrote:
>> On Mon, Jun 19, 2017 at 5:33 PM, Luis Ressel <aranea@...ah.de> 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 <aranea@...ah.de>
>> > Acked-by: Stephen Smalley <sds@...ho.nsa.gov>
>> > ---
>> >  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