From: Darrel Goeddel <dgoeddel@TrustedCS.com>
To: Joshua Brindle <jbrindle@tresys.com>
Cc: SELinux List <SELinux@tycho.nsa.gov>,
Stephen Smalley <sds@tycho.nsa.gov>,
Eric Paris <eparis@redhat.com>,
Karl MacMillan <kmacmillan@mentalrootkit.com>,
Chad Hanson <chanson@TrustedCS.com>
Subject: Re: [PATCH 2/2] userland support for new range_transition statements
Date: Wed, 09 Aug 2006 10:00:41 -0500 [thread overview]
Message-ID: <44D9F899.6050202@trustedcs.com> (raw)
In-Reply-To: <6FE441CD9F0C0C479F2D88F959B0158832AE66@exchange.columbia.tresys.com>
Joshua Brindle wrote:
>>From: Darrel Goeddel [mailto:dgoeddel@trustedcs.com]
>>
>>Joshua Brindle wrote:
>>
<snip>
>>Wouldn't this mean that the base module would have to define
>>every possible combination of sensitivities and categories?
>>That would make things a bit unmanageable.
>
>
> No, the required range would be interpreted the same way that any other
> range is. Every complete range used within a module (or optional block)
> would have to be required though, but I'm not sure how big of a deal
> that is, how many different combinations are typically used? Now that
> users aren't even put in the policy for different mls ranges I assume it
> is very few.
There are environments that use thousands of combinations.
>
>>I don't look at categories and sensitivities s local
>>configuration at all - they are a defined part of the policy.
>> A human-readable translation for what the level means is a
>>local configuration. It is really the same story for types -
>>I can use security_t in my module, but I am making
>>assumptions about what security_t means in the base policy.
>>When I put s4:c0,c5,c100.c150 into a module, I am making the
>>same assumptions.
>>
>
>
> Not sure about this, SystemHigh is not the same on every system, how
> does a module reconcile that? You are right about the typespace which is
> something we want to address, refpolicy interfaces introduced
> encapsulation where modules don't know about other modules types,
> unfortunately since its all compile time now the encapsulation isn't
> enforced but interfaces in the language would be able to do that.
True, SystemHigh may not be the same on every system. The policy would have
to have knowledge of the label encoding scheme of the target. Typically,
an environment will have a approved scheme that is used by all systems.
(actually SystemHigh is probably the same because it should be the highest
sensitivity and all cats, but other labels such as secret, unclass, etc. may
have different encodings for different sites)
>>As for putting the translations into the policy - that
>>doesn't work out very well. I believe that we experimented
>>with that a long time ago and found it to be a complete
>>nightmare. IMO, the correct place for translations would be
>>at the level of a tool that would help create policy modules.
>>
>
>
> I understand that, I'm just wondering how one could ever distribute a
> module with any mls range to different sites. If everyone is using
> refpolicy the types are known to be the same, that isn't the case with
> sensitivities and categories since they truly are a local configuration
> via the translations.
Yep. In practice, that "local" configuration is generally not local to a
specific system, rather it is common to the entire enterprise. It is a
customer or site configuration, not necessarily a machine configuration.
Policy for that environment must be aware of the labeling scheme.
I hope I got that right...
--
Darrel
--
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-08-09 15:00 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-28 15:13 [PATCH 2/2] userland support for new range_transition statements Darrel Goeddel
2006-07-31 16:40 ` Stephen Smalley
2006-07-31 18:25 ` Darrel Goeddel
2006-07-31 18:29 ` Karl MacMillan
2006-07-31 18:54 ` Darrel Goeddel
2006-07-31 20:52 ` Stephen Smalley
2006-08-01 13:14 ` Joshua Brindle
2006-08-02 16:38 ` Darrel Goeddel
2006-08-02 19:51 ` Karl MacMillan
2006-08-02 21:59 ` Darrel Goeddel
2006-08-03 12:01 ` Joshua Brindle
2006-08-03 15:55 ` Joshua Brindle
2006-08-04 16:13 ` Darrel Goeddel
2006-08-07 13:18 ` Joshua Brindle
2006-08-08 14:48 ` Darrel Goeddel
2006-08-08 22:45 ` Joshua Brindle
2006-08-09 15:00 ` Darrel Goeddel [this message]
2006-08-04 17:10 ` [PATCH 2/2 take 2] " Darrel Goeddel
2006-08-08 22:25 ` Joshua Brindle
2006-08-09 13:09 ` Karl MacMillan
2006-08-09 13:31 ` Joshua Brindle
2006-08-09 15:06 ` Darrel Goeddel
2006-08-09 15:13 ` Karl MacMillan
2006-08-09 15:39 ` [PATCH 2/2 take 2] userland support for new range_transitionstatements Joshua Brindle
2006-08-09 14:29 ` [PATCH 2/2 take 2] userland support for new range_transition statements Darrel Goeddel
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=44D9F899.6050202@trustedcs.com \
--to=dgoeddel@trustedcs.com \
--cc=SELinux@tycho.nsa.gov \
--cc=chanson@TrustedCS.com \
--cc=eparis@redhat.com \
--cc=jbrindle@tresys.com \
--cc=kmacmillan@mentalrootkit.com \
--cc=sds@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.