From: Stephen Smalley <sds@tycho.nsa.gov>
To: Dominick Grift <dominick.grift@gmail.com>
Cc: selinux <selinux@tycho.nsa.gov>
Subject: Re: RFC policycoreutils packaging
Date: Mon, 16 Sep 2013 08:07:39 -0400 [thread overview]
Message-ID: <5236F48B.7080407@tycho.nsa.gov> (raw)
In-Reply-To: <1379166860.4313.21.camel@d30>
On 09/14/2013 09:54 AM, Dominick Grift wrote:
> We were discussing policycoreutils packaging and there are some things
> unclear to me:
>
> 1. if one wants to run a monotlitic policy on a embedded system, then,
> besides fixfiles and checkpolicy, which tools from policycoreutils are
> needed?
If you want a truly minimalist SELinux userspace, consider our port to
Android in the SE for Android project. Policy is built monolithically
on the build host, with only the final binary policy installed to the
device, so you don't even need libsepol or checkpolicy on the device,
and you don't need libsemanage, semodule, or semanage at all. We also
have a minimalist port of libselinux with glibc dependencies removed,
and a port of the SELinux utilities to the Android toolbox, although I
suspect you are using busybox and thus picking up its SELinux support
instead.
> 1.a How are home dir contexts generated with monolithic policy ( or
> should they be created manually ? ), i ask this because in Fedora the
> genhomedircon is just a script that calls semodule, but i think semodule
> does not work with monolithic policy. If true, how then is someone
> expected to generate home dir contexts?
Originally IIRC, genhomedircon was a python script that didn't use
semodule or libsemanage at all. That's how it used to work in the
pre-modular/managed policy days. Should be able to find it the
selinux-historical git repo.
> 2. Does the sandbox utility only work ( or only work properly ) in
> policy configurations that have the MCS security model enabled? If so
> should one then depend on a policy model that has MCS enabled?
I think it presumes that the MLS engine is enabled and thus it can use
categories. Whether or not the configuration is MCS or MLS or something
altogether different doesn't matter so much as long as two processes
that have incomparable categories can't observe or modify each other.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
next prev parent reply other threads:[~2013-09-16 12:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-14 13:54 RFC policycoreutils packaging Dominick Grift
2013-09-16 12:07 ` Stephen Smalley [this message]
2013-09-16 12:32 ` Dominick Grift
2013-09-16 14:32 ` Daniel J Walsh
2013-09-16 14:54 ` Dominick Grift
2013-09-16 15:12 ` Daniel J Walsh
2013-09-16 15:27 ` Dominick Grift
2013-09-16 15:38 ` Dominick Grift
2013-09-16 16:21 ` Daniel J Walsh
2013-09-16 15:28 ` Christopher J. PeBenito
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=5236F48B.7080407@tycho.nsa.gov \
--to=sds@tycho.nsa.gov \
--cc=dominick.grift@gmail.com \
--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.