From: Darrel Goeddel <dgoeddel@TrustedCS.com>
To: Joshua Brindle <jbrindle@tresys.com>
Cc: SELinux List <selinux@tycho.nsa.gov>,
Daniel Walsh <dwalsh@redhat.com>,
Stephen Smalley <sds@tycho.nsa.gov>,
Karl MacMillan <kmacmillan@mentalrootkit.com>,
Linda Knippers <linda.knippers@hp.com>,
Christopher PeBenito <cpebenito@tresys.com>
Subject: Re: [RFC PATCH 1/3] reference policy: add "context" security class
Date: Thu, 05 Oct 2006 14:20:57 -0500 [thread overview]
Message-ID: <45255B19.8080303@trustedcs.com> (raw)
In-Reply-To: <452553BE.3080805@tresys.com>
Joshua Brindle wrote:
> Darrel Goeddel wrote:
>
>> Define a new security class "context" and its permission "translate" for
>> use by the context translation daemon. The bit of policy added to the
>> setrans_translate_context interface only allows for translation of
>> domains and file_contexts. You can see how this is bad if you try to
>> ls -Z /dev. I don't have a trick to allow TE access to every type other
>> than grabbing some "big" attributes, then listing every remaining type.
>> That obviously does not work in the modular policy model anyway. Any
>> ideas on how we could maybe handle that one? (assuming that anyone else
>> does not want TE restriction on the translations :)) How about a
>> privilege to use '*' or '~' in typesets...
>>
> * and ~ in typesets considered harmful. In addition to the badness of
> not actually knowing what you are giving access to they would cause the
> avtab to be much bigger (they'd have to be expanded whereas "big"
> attributes don't anymore).
I know, I agreed with the restriction. I just didn't have a situation
back then where I only wanted an MLS check :(
> However, I'm not sure you want to go this route anyway. You are
> basically implying that the label of a context is the context itself
> (mind bending I know, we did this same thing forever ago with the policy
> server). We finally decided that it was much better to explicitly label
> then (this was part of the '.' notation). For example the policy server
> labeling file might have:
>
> type apache_t system_u:object_r:apache_root_type_t
> type apache_t. system_u:object_r:apache_types_t
>
> then you can give access to everything "under" apache_t in the hierarchy
> with just one allow rule but not give access to apache_t. I know this
> exact thing won't work for you since you are doing full contexts but you
> may want to consider your labeling scheme.
We could make a "shadow" to every type on the system like foo_t would have
foo_t.context_type_t, then give all of the *.context_type_t types an attribute
of context_type, and then do "allow domain context_type:context translate;".
Anyone mind if I double the number of types? I'm note really serious here
in case anyone was wondering ;)
> In the mean time, since the translation permissions is primarily for MLS
> anyway you might consider a much more course permission that lets you do
> translations in general with the expectation that at some point in the
> future you could implement a more fine grained mechanism.
I take it that you are talking about something like a "self" permission
(allow domain self:security translate_context; or some such). The problem there
is that the actual context must be the target of the check so we can actually
do the MLS comparison. If I misunderstood, could you please explain further.
--
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-10-05 19:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-05 18:05 [RFC PATCH 1/3] reference policy: add "context" security class Darrel Goeddel
2006-10-05 18:49 ` Joshua Brindle
2006-10-05 19:20 ` Darrel Goeddel [this message]
2006-10-05 19:40 ` Stephen Smalley
2006-10-05 19:50 ` Darrel Goeddel
2006-10-05 19:47 ` Joshua Brindle
2006-10-05 18:50 ` Christopher J. PeBenito
2006-10-05 19:29 ` 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=45255B19.8080303@trustedcs.com \
--to=dgoeddel@trustedcs.com \
--cc=cpebenito@tresys.com \
--cc=dwalsh@redhat.com \
--cc=jbrindle@tresys.com \
--cc=kmacmillan@mentalrootkit.com \
--cc=linda.knippers@hp.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.