linux-kernel - Re: linux-next: manual merge of the selinux tree with the keys tree

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:   Wed, 12 Feb 2020 12:03:33 +0000
From:   Richard Haines <richard_c_haines@...nternet.com>
To:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Paul Moore <paul@...l-moore.com>,
        David Howells <dhowells@...hat.com>, sds@...ho.nsa.gov
Cc:     Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Christian Göttsche <cgzones@...glemail.com>,
        Stephen Smalley <sds@...ho.nsa.gov>
Subject: Re: linux-next: manual merge of the selinux tree with the keys tree

On Wed, 2020-02-12 at 10:35 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the selinux tree got conflicts in:
> 
>   security/selinux/include/security.h
>   security/selinux/ss/services.c
> 
> between commit:
> 
>   87b14da5b76a ("security/selinux: Add support for new key
> permissions")
> 
> from the keys tree and commit:
> 
>   7470d0d13fb6 ("selinux: allow kernfs symlinks to inherit parent
> directory context")
> 
> from the selinux tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your
> tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any
> particularly
> complex conflicts.
> 

I think 87b14da5b76a ("security/selinux: Add support for new key
permissions") should be revoked and resubmitted via selinux as it was
never ack'ed there and produced before 7470d0d13fb6 ("selinux: allow
kernfs symlinks to inherit parent directory context"), that has been
ack'ed.

Because of this the policy capability ids are out of sync with what has
been committed in userspace libsepol.

Plus as Paul mentioned there is an outstanding query on the permission
loop that David needs to answer.