All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.