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]
Message-ID: <1d0b80d272a8e8c4a7b322d2d2bcc483d9e41a28.camel@btinternet.com>
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.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ