From: Paul Moore <paul@paul-moore.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: selinux@vger.kernel.org
Subject: Re: [PATCH v3] scripts/selinux: add basic mls support to mdp
Date: Fri, 15 Feb 2019 10:00:39 -0500 [thread overview]
Message-ID: <CAHC9VhS+F-QBU-oJpXw1aAP1=TpekD1GEYB8y-QqEib1mzbwMA@mail.gmail.com> (raw)
In-Reply-To: <20190215145045.31945-1-sds@tycho.nsa.gov>
On Fri, Feb 15, 2019 at 9:51 AM Stephen Smalley <sds@tycho.nsa.gov> wrote:
> Add basic MLS policy support to mdp. Declares
> two sensitivities and two categories, defines
> mls constraints for all permissions requiring
> dominance (ala MCS), assigns the system-high
> level to initial SID contexts and the default user
> level, and assigns system-low level to filesystems.
>
> Also reworks the fs_use and genfscon rules to only
> generate rules for filesystems that are configured
> in the kernel. In some cases this depends on a specific
> config option for security xattrs, in other cases security
> xattrs are unconditionally supported by a given filesystem
> if the filesystem is enabled, and in some cases the filesystem
> is always enabled in the kernel. Dropped obsolete pseudo
> filesystems.
>
> NB The list of fs_use_* and genfscon rules emitted by mdp
> is very incomplete compared to refpolicy or Android sepolicy.
> We should probably expand it.
>
> Usage:
> scripts/selinux/mdp/mdp -m policy.conf file_contexts
> checkpolicy -M -o policy policy.conf
>
> Then install the resulting policy and file_contexts as usual.
>
> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> ---
> v3 fixes up the file contexts generation code to also use SYSTEMLOW and
> collapse down to a single fprintf call per line.
> scripts/selinux/mdp/mdp.c | 131 ++++++++++++++++++++++++++++++--------
> 1 file changed, 103 insertions(+), 28 deletions(-)
This is great Stephen, thanks for working on this - and rather quickly
too! For those who don't follow the GitHub issues, I just opened an
issue yesterday mentioning it would be nice to add MLS support to the
mdp tool.
Are you planning to keep playing with this? I'm asking not because I
think it needs more work to be worthwhile, but rather I don't want to
merge something that you want to continue working on. If you are
happy with this latest patch I think it is okay to merge this into
selinux/next, even at this late stage, simply because it is not part
of a built kernel, but rather a developer's tool.
> diff --git a/scripts/selinux/mdp/mdp.c b/scripts/selinux/mdp/mdp.c
> index 073fe7537f6c..4223e2fea441 100644
> --- a/scripts/selinux/mdp/mdp.c
> +++ b/scripts/selinux/mdp/mdp.c
> @@ -33,6 +33,7 @@
> #include <unistd.h>
> #include <string.h>
> #include <sys/socket.h>
> +#include <linux/kconfig.h>
>
> static void usage(char *name)
> {
> @@ -95,10 +96,31 @@ int main(int argc, char *argv[])
> }
> fprintf(fout, "\n");
>
> - /* NOW PRINT OUT MLS STUFF */
> + /* print out mls declarations and constraints */
> if (mls) {
> - printf("MLS not yet implemented\n");
> - exit(1);
> + fprintf(fout, "sensitivity s0;\n");
> + fprintf(fout, "sensitivity s1;\n");
> + fprintf(fout, "dominance { s0 s1 }\n");
> + fprintf(fout, "category c0;\n");
> + fprintf(fout, "category c1;\n");
> + fprintf(fout, "level s0:c0.c1;\n");
> + fprintf(fout, "level s1:c0.c1;\n");
> +#define SYSTEMLOW "s0"
> +#define SYSTEMHIGH "s1:c0.c1"
> + for (i = 0; secclass_map[i].name; i++) {
> + struct security_class_mapping *map = &secclass_map[i];
> +
> + fprintf(fout, "mlsconstrain %s {\n", map->name);
> + for (j = 0; map->perms[j]; j++)
> + fprintf(fout, "\t%s\n", map->perms[j]);
> + /*
> + * This requires all subjects and objects to be
> + * single-level (l2 eq h2), and that the subject
> + * level dominate the object level (h1 dom h2)
> + * in order to have any permissions to it.
> + */
> + fprintf(fout, "} (l2 eq h2 and h1 dom h2);\n\n");
> + }
> }
>
> /* types, roles, and allows */
> @@ -108,34 +130,87 @@ int main(int argc, char *argv[])
> for (i = 0; secclass_map[i].name; i++)
> fprintf(fout, "allow base_t base_t:%s *;\n",
> secclass_map[i].name);
> - fprintf(fout, "user user_u roles { base_r };\n");
> - fprintf(fout, "\n");
> + fprintf(fout, "user user_u roles { base_r }");
> + if (mls)
> + fprintf(fout, " level %s range %s - %s", SYSTEMHIGH,
> + SYSTEMLOW, SYSTEMHIGH);
> + fprintf(fout, ";\n");
> +
> +#define USERROLETYPE "user_u:base_r:base_t"
>
> /* default sids */
> for (i = 1; i < initial_sid_to_string_len; i++)
> - fprintf(fout, "sid %s user_u:base_r:base_t\n", initial_sid_to_string[i]);
> + fprintf(fout, "sid %s " USERROLETYPE "%s\n",
> + initial_sid_to_string[i], mls ? ":" SYSTEMHIGH : "");
> fprintf(fout, "\n");
>
> - fprintf(fout, "fs_use_xattr ext2 user_u:base_r:base_t;\n");
> - fprintf(fout, "fs_use_xattr ext3 user_u:base_r:base_t;\n");
> - fprintf(fout, "fs_use_xattr ext4 user_u:base_r:base_t;\n");
> - fprintf(fout, "fs_use_xattr jfs user_u:base_r:base_t;\n");
> - fprintf(fout, "fs_use_xattr xfs user_u:base_r:base_t;\n");
> - fprintf(fout, "fs_use_xattr reiserfs user_u:base_r:base_t;\n");
> - fprintf(fout, "fs_use_xattr jffs2 user_u:base_r:base_t;\n");
> - fprintf(fout, "fs_use_xattr gfs2 user_u:base_r:base_t;\n");
> -
> - fprintf(fout, "fs_use_task eventpollfs user_u:base_r:base_t;\n");
> - fprintf(fout, "fs_use_task pipefs user_u:base_r:base_t;\n");
> - fprintf(fout, "fs_use_task sockfs user_u:base_r:base_t;\n");
> -
> - fprintf(fout, "fs_use_trans mqueue user_u:base_r:base_t;\n");
> - fprintf(fout, "fs_use_trans devpts user_u:base_r:base_t;\n");
> - fprintf(fout, "fs_use_trans hugetlbfs user_u:base_r:base_t;\n");
> - fprintf(fout, "fs_use_trans tmpfs user_u:base_r:base_t;\n");
> - fprintf(fout, "fs_use_trans shm user_u:base_r:base_t;\n");
> -
> - fprintf(fout, "genfscon proc / user_u:base_r:base_t\n");
> +#define FS_USE(behavior, fstype) \
> + fprintf(fout, "fs_use_%s %s " USERROLETYPE "%s;\n", \
> + behavior, fstype, mls ? ":" SYSTEMLOW : "")
> +
> + /*
> + * Filesystems whose inode labels can be fetched via getxattr.
> + */
> +#ifdef CONFIG_EXT2_FS_SECURITY
> + FS_USE("xattr", "ext2");
> +#endif
> +#ifdef CONFIG_EXT3_FS_SECURITY
> + FS_USE("xattr", "ext3");
> +#endif
> +#ifdef CONFIG_EXT4_FS_SECURITY
> + FS_USE("xattr", "ext4");
> +#endif
> +#ifdef CONFIG_JFS_SECURITY
> + FS_USE("xattr", "jfs");
> +#endif
> +#ifdef CONFIG_REISERFS_FS_SECURITY
> + FS_USE("xattr", "reiserfs");
> +#endif
> +#ifdef CONFIG_JFFS2_FS_SECURITY
> + FS_USE("xattr", "jffs2");
> +#endif
> +#ifdef CONFIG_XFS_FS
> + FS_USE("xattr", "xfs");
> +#endif
> +#ifdef CONFIG_GFS2_FS
> + FS_USE("xattr", "gfs2");
> +#endif
> +
> + /*
> + * Filesystems whose inodes are labeled from allocating task.
> + */
> + FS_USE("task", "pipefs");
> + FS_USE("task", "sockfs");
> +#ifdef CONFIG_POSIX_MQUEUE
> + FS_USE("task", "mqueue");
> +#endif
> +
> + /*
> + * Filesystems whose inode labels are computed from both
> + * the allocating task and the superblock label.
> + */
> +#ifdef CONFIG_UNIX98_PTYS
> + FS_USE("trans", "devpts");
> +#endif
> +#ifdef CONFIG_HUGETLBFS
> + FS_USE("trans", "hugetlbfs");
> +#endif
> +#ifdef CONFIG_TMPFS
> + FS_USE("trans", "tmpfs");
> +#endif
> +
> +
> +#define GENFSCON(fstype, prefix) \
> + fprintf(fout, "genfscon %s %s " USERROLETYPE "%s\n", \
> + fstype, prefix, mls ? ":" SYSTEMLOW : "")
> +
> + /*
> + * Filesystems whose inodes are labeled from path prefix match
> + * relative to the filesystem root. Depending on the filesystem,
> + * only a single label for all inodes may be supported.
> + */
> + GENFSCON("proc", "/");
> + GENFSCON("selinuxfs", "/");
>
> fclose(fout);
>
> @@ -144,8 +219,8 @@ int main(int argc, char *argv[])
> printf("Wrote policy, but cannot open %s for writing\n", ctxout);
> usage(argv[0]);
> }
> - fprintf(fout, "/ user_u:base_r:base_t\n");
> - fprintf(fout, "/.* user_u:base_r:base_t\n");
> + fprintf(fout, "/ " USERROLETYPE "%s\n", mls ? ":" SYSTEMLOW : "");
> + fprintf(fout, "/.* " USERROLETYPE "%s\n", mls ? ":" SYSTEMLOW : "");
> fclose(fout);
>
> return 0;
> --
> 2.20.1
>
--
paul moore
www.paul-moore.com
next prev parent reply other threads:[~2019-02-15 15:01 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-15 14:50 [PATCH v3] scripts/selinux: add basic mls support to mdp Stephen Smalley
2019-02-15 15:00 ` Paul Moore [this message]
2019-02-15 15:03 ` Stephen Smalley
2019-02-15 15:05 ` Stephen Smalley
2019-02-15 15:18 ` Paul Moore
2019-02-15 15:25 ` Stephen Smalley
2019-02-15 15:37 ` Paul Moore
2019-02-15 15:40 ` Stephen Smalley
2019-02-15 16:52 ` Dominick Grift
2019-02-15 17:16 ` Stephen Smalley
2019-02-15 17:19 ` Dominick Grift
2019-02-15 17:24 ` Dominick Grift
2019-02-15 19:11 ` Paul Moore
2019-02-15 19:21 ` Dominick Grift
2019-02-15 19:30 ` Stephen Smalley
2019-02-15 19:36 ` Dominick Grift
2019-02-15 19:48 ` Stephen Smalley
2019-02-16 12:04 ` Dominick Grift
2019-02-16 12:12 ` Dominick Grift
2019-02-18 3:12 ` Paul Moore
2019-02-18 7:08 ` Dominick Grift
[not found] ` <CAB9W1A3f1jxJQPrU-o=gEKzgjRGmbThoqPvzbK7QNqprdE-LAw@mail.gmail.com>
2019-02-19 8:15 ` Dominick Grift
2019-02-19 11:08 ` Dominick Grift
[not found] ` <CAB9W1A2s+PcrC=fPXA9AYRm1oVYArsRCGKihM5mjUqnQtuLe3w@mail.gmail.com>
[not found] ` <CAB9W1A3Pef5pfAZ8UEvSQYvWA9oZTRNPvWFCHw8e9eqZsGvGWA@mail.gmail.com>
2019-02-20 10:27 ` Petr Lautrbach
2019-02-19 12:11 ` Petr Lautrbach
2019-02-19 12:37 ` Dominick Grift
2019-02-19 12:40 ` Dominick Grift
2019-02-15 16:50 ` Dominick Grift
2019-02-15 15:15 ` 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='CAHC9VhS+F-QBU-oJpXw1aAP1=TpekD1GEYB8y-QqEib1mzbwMA@mail.gmail.com' \
--to=paul@paul-moore.com \
--cc=sds@tycho.nsa.gov \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).