From: Joshua Brindle <jbrindle@tresys.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Daniel J Walsh <dwalsh@redhat.com>,
"Christopher J. PeBenito" <cpebenito@tresys.com>,
Russell Coker <rcoker@redhat.com>,
SE Linux <selinux@tycho.nsa.gov>
Subject: Re: Problem with semodule mls policy
Date: Wed, 15 Mar 2006 11:37:22 -0500 [thread overview]
Message-ID: <441842C2.8070706@tresys.com> (raw)
In-Reply-To: <1142440539.4933.6.camel@moss-spartans.epoch.ncsc.mil>
Stephen Smalley wrote:
> On Wed, 2006-03-15 at 11:01 -0500, Joshua Brindle wrote:
>> Stephen Smalley wrote:
>>> On Wed, 2006-03-15 at 09:26 -0500, Daniel J Walsh wrote:
>>>> How do I get semodule to create policy.20 at SystemHigh and everything
>>>> other files at SystemLow?
>> Why do we want policy.20 at SystemHigh again? The only scenerio I can
>> think of is the user->role mappings but who will be using those rather
>> than seuser mappings? For that matter, seuser file should probably be at
>> SystemHigh...
>
> Possibly local customizations are in view here, e.g. the contents of
> interfaces.local, that are then fed into the final policy.20 emitted by
> libsemanage? seusers is the more likely concern, as you note, and it is
> harder to transparently label it separately since it doesn't live in its
> own dedicated subdirectory (so range_transition wouldn't help with it;
> you'd need libsemanage code modification).
>
The entire module store (/etc/selinux/<type>/modules/*) should be
entirely inaccessible except by an semanage_t domain (and policy server
later) via type enforcement, so those shouldn't be a concern. The
policy.20 shouldn't really contain any sensitive information so I think
the only necessary modification is to label seusers differently, correct?
--
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:[~2006-03-15 16:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-15 14:26 Problem with semodule mls policy Daniel J Walsh
2006-03-15 15:01 ` Stephen Smalley
2006-03-15 16:01 ` Joshua Brindle
2006-03-15 16:35 ` Stephen Smalley
2006-03-15 16:37 ` Joshua Brindle [this message]
2006-03-15 16:58 ` Stephen Smalley
2006-03-15 18:00 ` Joshua Brindle
2006-03-15 18:19 ` Stephen Smalley
2006-03-15 21:21 ` Daniel J Walsh
-- strict thread matches above, loose matches on Subject: below --
2006-03-15 18:53 Chad Hanson
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=441842C2.8070706@tresys.com \
--to=jbrindle@tresys.com \
--cc=cpebenito@tresys.com \
--cc=dwalsh@redhat.com \
--cc=rcoker@redhat.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.