linux-kernel - Re: [RFC PATCH] selinux: add a fallback to defcontext for native labeling

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, 25 Sep 2018 12:10:56 -0700
From:   Taras Kondratiuk <takondra@...co.com>
To:     Paul Moore <paul@...l-moore.com>,
        Stephen Smalley <sds@...ho.nsa.gov>
Cc:     linux-kernel@...r.kernel.org, selinux@...ho.nsa.gov,
        xe-linux-external@...co.com
Subject: Re: [RFC PATCH] selinux: add a fallback to defcontext for native labeling

Quoting Stephen Smalley (2018-09-25 09:39:55)
> On 09/25/2018 12:03 PM, Paul Moore wrote:
> > On Tue, Sep 25, 2018 at 9:58 AM Stephen Smalley <sds@...ho.nsa.gov> wrote:

<snip>

> >> I'm inclined to just change the behavior for defcontext= unconditionally
> >> and have it apply to both native and xattr labeling.  If that's a no-go,
> >> then the simplest solution is to just leave defcontext= behavior
> >> unchanged for xattr labeling and only implement the new semantics for
> >> native labeling.  That's just a matter of adding a flag to
> >> security_context_to_sid_default() and only setting it when calling from
> >> selinux_inode_notifysecctx().
> > 
> > Neither option is very appealing to me, but that doesn't mean I'm saying "no".
> > 
> >  From a sanity and consistency point of view I think option #1 (change
> > the defcontext behavior) is a better choice, and I tend to favor this
> > consistency even with the understanding that it could result in some
> > unexpected behavior for users.  However, if we get complaints, I'm
> > going to revert this without a second thought.
> 
> In that case, I'd suggest splitting it into two patches; first one only 
> enables the new behavior for native labeling filesystems (as per the 
> above, via a flag to security_context_to_sid_default), and the second 
> patch drops the flag and does it unconditionally.  Then you can always 
> revert the latter without affecting the former.
> 
> > 
> > So to answer your question Taras, go ahead and prepare a patch so we
> > can take a look.  A bit of fair warning that it might get delayed
> > until after the upcoming merge window since we are already at -rc5; I
> > want this to have plenty of time in -next.
> > 
> > Thanks guys.

Thanks. I'll prepare patches is a few days.