From: Joshua Brindle <brindle@quarksecurity.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: paul@paul-moore.com, selinux@tycho.nsa.gov,
eparis@parisplace.org, pebenito@ieee.org, jwcart2@tycho.nsa.gov
Subject: Re: [RFC][PATCH] selinux: add a map permission check for mmap
Date: Fri, 05 May 2017 09:42:32 -0400 [thread overview]
Message-ID: <590C8148.6010307@quarksecurity.com> (raw)
In-Reply-To: <20170505131448.8718-1-sds@tycho.nsa.gov>
Stephen Smalley wrote:
> Add a map permission check on mmap so that we can distinguish memory mapped
> access (since it has different implications for revocation). When a file
> is opened and then read or written via syscalls like read(2)/write(2),
> we revalidate access on each read/write operation via
> selinux_file_permission() and therefore can revoke access if the
> process context, the file context, or the policy changes in such a
> manner that access is no longer allowed. When a file is opened and then
> memory mapped via mmap(2) and then subsequently read or written directly
> in memory, we presently have no way to revalidate or revoke access.
> The purpose of a separate map permission check on mmap(2) is to permit
> policy to prohibit memory mapping of specific files for which we need
> to ensure that every access is revalidated, particularly useful for
> scenarios where we expect the file to be relabeled at runtime in order
> to reflect state changes (e.g. cross-domain solution, assured pipeline
> without data copying).
>
> Signed-off-by: Stephen Smalley<sds@tycho.nsa.gov>
> ---
> NB I chose not to define a new policy capability for this permission,
> since it is adequately covered by handle_unknown for compatibility and
> others seemed to agree that this does not fall into the category of
> changes requiring a new policy capability. I also chose to define the
> permission for socket classes in addition to file classes and let it
> be checked for both.
Thank you. This is very helpful. This fully closes the relabel
revocation issue, right?
Is it actually safe to tell people that relabel+move is sufficient in an
assured pipeline now?
>
> security/selinux/hooks.c | 12 ++++++++++++
> security/selinux/include/classmap.h | 2 +-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index e67a526..5432628 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -3550,6 +3550,18 @@ static int selinux_mmap_addr(unsigned long addr)
> static int selinux_mmap_file(struct file *file, unsigned long reqprot,
> unsigned long prot, unsigned long flags)
> {
> + struct common_audit_data ad;
> + int rc;
> +
> + if (file) {
> + ad.type = LSM_AUDIT_DATA_FILE;
> + ad.u.file = file;
> + rc = inode_has_perm(current_cred(), file_inode(file),
> + FILE__MAP,&ad);
> + if (rc)
> + return rc;
> + }
> +
> if (selinux_checkreqprot)
> prot = reqprot;
>
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index 1e0cc9b..3e49a78 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -1,7 +1,7 @@
> #include<linux/capability.h>
>
> #define COMMON_FILE_SOCK_PERMS "ioctl", "read", "write", "create", \
> - "getattr", "setattr", "lock", "relabelfrom", "relabelto", "append"
> + "getattr", "setattr", "lock", "relabelfrom", "relabelto", "append", "map"
>
> #define COMMON_FILE_PERMS COMMON_FILE_SOCK_PERMS, "unlink", "link", \
> "rename", "execute", "quotaon", "mounton", "audit_access", \
next prev parent reply other threads:[~2017-05-05 13:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-05 13:14 [RFC][PATCH] selinux: add a map permission check for mmap Stephen Smalley
2017-05-05 13:42 ` Joshua Brindle [this message]
2017-05-05 14:24 ` Stephen Smalley
2017-05-05 13:53 ` Stephen Smalley
2017-05-12 16:30 ` Stephen Smalley
2017-05-18 15:41 ` Paul Moore
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=590C8148.6010307@quarksecurity.com \
--to=brindle@quarksecurity.com \
--cc=eparis@parisplace.org \
--cc=jwcart2@tycho.nsa.gov \
--cc=paul@paul-moore.com \
--cc=pebenito@ieee.org \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
/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.