From: Richard Haines <richard_c_haines@btinternet.com>
To: dhowells@redhat.com
Cc: keyrings@vger.kernel.org, selinux@vger.kernel.org
Subject: SELinux issue with 'keys-acl' patch in kernel.org's 'linux-next' tree
Date: Thu, 23 Jan 2020 10:28:25 +0000 [thread overview]
Message-ID: <8ee40192da117d9cdf4eab1e63ab5f77b359801c.camel@btinternet.com> (raw)
I see the 'keys-acl' [1] patch is now back in kernel.org's 'linux-next'
tree.
After some investigation, I have a query on this that I've attempted to
explain below.
The keyutils tests work with this patch on standard Fedora policy
because the policy gives most domains access to all key permissions.
Also the polcy is built using 'hide_broken_symptoms' that adds 'allow
domain domain:key { link search };', therefore calls made by these
always pass:
keys/keyring.c - find_keyring_by_name():
Originally required: KEY_NEED_SEARCH
Now requires: KEY_NEED_JOIN
keys/keyctl.c - keyctl_session_to_parent():
Originally required: KEY_NEED_LINK
Now requires: KEY_NEED_JOIN
However if (as in the selinux-testsuite - test/keys), 'domain' is
replaced by a macro that excludes the { link search }, and allows each
permission to be tested, two tests fail. This is because:
1) keyctl_session_to_parent() requires KEY_NEED_JOIN translated to
KEY_NEED_LINK permission.
2) find_keyring_by_name() requires KEY_NEED_JOIN translated to
KEY_NEED_SEARCH permission.
The patch always translates KEY_NEED_JOIN to KEY_NEED_SEARCH
Any views on this as it seems a regression.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/security/selinux?h=next-20200122&id¨62a799537490b74a81e14a62623af502bdb25d
WARNING: multiple messages have this Message-ID (diff)
From: Richard Haines <richard_c_haines@btinternet.com>
To: dhowells@redhat.com
Cc: keyrings@vger.kernel.org, selinux@vger.kernel.org
Subject: SELinux issue with 'keys-acl' patch in kernel.org's 'linux-next' tree
Date: Thu, 23 Jan 2020 10:28:25 +0000 [thread overview]
Message-ID: <8ee40192da117d9cdf4eab1e63ab5f77b359801c.camel@btinternet.com> (raw)
I see the 'keys-acl' [1] patch is now back in kernel.org's 'linux-next'
tree.
After some investigation, I have a query on this that I've attempted to
explain below.
The keyutils tests work with this patch on standard Fedora policy
because the policy gives most domains access to all key permissions.
Also the polcy is built using 'hide_broken_symptoms' that adds 'allow
domain domain:key { link search };', therefore calls made by these
always pass:
keys/keyring.c - find_keyring_by_name():
Originally required: KEY_NEED_SEARCH
Now requires: KEY_NEED_JOIN
keys/keyctl.c - keyctl_session_to_parent():
Originally required: KEY_NEED_LINK
Now requires: KEY_NEED_JOIN
However if (as in the selinux-testsuite - test/keys), 'domain' is
replaced by a macro that excludes the { link search }, and allows each
permission to be tested, two tests fail. This is because:
1) keyctl_session_to_parent() requires KEY_NEED_JOIN translated to
KEY_NEED_LINK permission.
2) find_keyring_by_name() requires KEY_NEED_JOIN translated to
KEY_NEED_SEARCH permission.
The patch always translates KEY_NEED_JOIN to KEY_NEED_SEARCH
Any views on this as it seems a regression.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/security/selinux?h=next-20200122&id=a862a799537490b74a81e14a62623af502bdb25d
next reply other threads:[~2020-01-23 10:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-23 10:28 Richard Haines [this message]
2020-01-23 10:28 ` SELinux issue with 'keys-acl' patch in kernel.org's 'linux-next' tree Richard Haines
2020-01-23 15:12 ` SELinux: How to split permissions for keys? David Howells
2020-01-23 15:46 ` Stephen Smalley
2020-01-23 15:46 ` Stephen Smalley
2020-01-23 20:35 ` Stephen Smalley
2020-01-23 20:35 ` Stephen Smalley
2020-02-02 19:30 ` Richard Haines
2020-02-02 19:30 ` Richard Haines
2020-02-03 13:13 ` Stephen Smalley
2020-02-03 13:13 ` Stephen Smalley
2020-02-03 14:03 ` Richard Haines
2020-02-03 14:03 ` Richard Haines
2020-02-03 14:48 ` Stephen Smalley
2020-02-03 14:48 ` Stephen Smalley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8ee40192da117d9cdf4eab1e63ab5f77b359801c.camel@btinternet.com \
--to=richard_c_haines@btinternet.com \
--cc=dhowells@redhat.com \
--cc=keyrings@vger.kernel.org \
--cc=selinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.