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.
--
Cheers,
Stephen Rothwell
diff --cc security/selinux/include/security.h
index 5353cd346433,d6036c018cf2..000000000000
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@@ -79,7 -79,7 +79,8 @@@ enum
POLICYDB_CAPABILITY_ALWAYSNETWORK,
POLICYDB_CAPABILITY_CGROUPSECLABEL,
POLICYDB_CAPABILITY_NNP_NOSUID_TRANSITION,
+ POLICYDB_CAPABILITY_KEYPERMS,
+ POLICYDB_CAPABILITY_GENFS_SECLABEL_SYMLINKS,
__POLICYDB_CAPABILITY_MAX
};
#define POLICYDB_CAPABILITY_MAX (__POLICYDB_CAPABILITY_MAX - 1)
@@@ -210,13 -214,13 +215,20 @@@ static inline bool selinux_policycap_nn
return state->policycap[POLICYDB_CAPABILITY_NNP_NOSUID_TRANSITION];
}
+static inline bool selinux_policycap_key_perms(void)
+{
+ struct selinux_state *state = &selinux_state;
+
+ return state->policycap[POLICYDB_CAPABILITY_KEYPERMS];
+}
+
+ static inline bool selinux_policycap_genfs_seclabel_symlinks(void)
+ {
+ struct selinux_state *state = &selinux_state;
+
+ return state->policycap[POLICYDB_CAPABILITY_GENFS_SECLABEL_SYMLINKS];
+ }
+
int security_mls_enabled(struct selinux_state *state);
int security_load_policy(struct selinux_state *state,
void *data, size_t len);
diff --cc security/selinux/ss/services.c
index 7527292fb31a,e310f8ee21a1..000000000000
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@@ -74,7 -73,7 +73,8 @@@ const char *selinux_policycap_names[__P
"always_check_network",
"cgroup_seclabel",
"nnp_nosuid_transition",
- "key_perms"
++ "key_perms",
+ "genfs_seclabel_symlinks"
};
static struct selinux_ss selinux_ss;
On Tue, Feb 11, 2020 at 6:35 PM Stephen Rothwell <[email protected]> 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.
Thanks for bringing this up Stephen, I wasn't aware that patch had hit
the keys tree.
Unless I missed a message in the SELinux mailing list thread regarding
the "security/selinux: Add support for new key permissions" patch, I
thought there were some outstanding questions (well, just a single big
one I guess) that needed to be resolved before this could go upstream;
did you put this in the keys tree David just for some additional
testing, or because you wanted to send it up to Linus via your tree?
If the latter, I would really prefer if this goes to Linus via SELinux
tree as it conflicts with some SELinux ABI changes and I would rather
we handle that in the SELinux tree instead of having to send manual
merge instructions up to Linus during the next merge window.
--
paul moore
http://www.paul-moore.com
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.
On Wed, Feb 12, 2020 at 7:03 AM Richard Haines
<[email protected]> wrote:
> 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.
David, I see that this patch is still getting pulled into linux-next,
could you please revert it from your keys tree?
--
paul moore
http://www.paul-moore.com