From: Paul Moore <paul@paul-moore.com>
To: "selinux@tycho.nsa.gov" <selinux@tycho.nsa.gov>
Cc: Richard Haines <richard_c_haines@btinternet.com>,
Stephen Smalley <sds@tycho.nsa.gov>,
Eric Paris <eparis@redhat.com>
Subject: Re: SELinux: Update policy version to support constraints info
Date: Thu, 24 Oct 2013 11:36:05 -0700 (PDT) [thread overview]
Message-ID: <11155540.a6QObQOMze@sifl> (raw)
In-Reply-To: <1382610164.40150.YahooMailNeo@web87904.mail.ir2.yahoo.com>
On Thursday, October 24, 2013 11:22:44 AM Richard Haines wrote:
> ----- Original Message -----
>
> > From: Stephen Smalley <sds@tycho.nsa.gov>
> > To: Eric Paris <eparis@redhat.com>
> > Cc: selinux@tycho.nsa.gov
> > Sent: Tuesday, 22 October 2013, 13:43
> > Subject: Re: SELinux: Update policy version to support constraints info
> >
> > On 10/21/2013 07:32 PM, Eric Paris wrote:
> >> From: Richard Haines <richard_c_haines@btinternet.com>
> >> Date: Tue, 18 Dec 2012 19:37:46 +0000
> >>
> >> Update the policy version (POLICYDB_VERSION_CONSTRAINT_NAMES) to allow
> >> holding of policy source info for constraints.
> >
> > Before we get into code review, let me ask the following:
> > Why do we need a new kernel binary policy version for information that
> > is only used by userspace? Why can't this information be extracted from
> > the policy module format or stored in an auxiliary file used only by
> > userspace?
>
> True it could be done the ways you suggest, however the module format would
> only work for modular policies and the auxiliary file (I felt) would be
> difficult to track (could be another config type file maybe?).
My current two cents on the issue ...
Working under the assumption that the userspace tools would much prefer to
read the policy directly from the kernel (for obvious reasons), it makes sense
to me that we provide this additional constraint information along with the
rest of the policy. Having to pull policy information from both the kernel
and a regular file seems like it could lead to all sorts of problems.
Further, I believe that for the majority of systems the extra ~5k of kernel
memory is not a major deal breaker, although I will concede that for smaller
systems (Android perhaps?) this might be more of a concern. What if, along
with this extra constraint information, we add a toggle (perhaps via a new
policy capability) which would trigger the kernel to either preserve the
constraint info or discard it when the policy is loaded?
--
paul moore
www.paul-moore.com
--
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-10-24 18:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-21 23:32 SELinux: Update policy version to support constraints info Eric Paris
2013-10-22 12:43 ` Stephen Smalley
2013-10-24 10:22 ` Richard Haines
2013-10-24 18:36 ` Paul Moore [this message]
2013-10-24 18:59 ` Stephen Smalley
2013-10-24 20:39 ` Stephen Smalley
2013-10-30 20:27 ` Stephen Smalley
2013-10-31 14:08 ` Richard Haines
2013-10-31 14:28 ` 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=11155540.a6QObQOMze@sifl \
--to=paul@paul-moore.com \
--cc=eparis@redhat.com \
--cc=richard_c_haines@btinternet.com \
--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.