All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karl MacMillan <kmacmillan@tresys.com>
To: Stephen Smalley <sds@epoch.ncsc.mil>
Cc: Dave Caplan <dac@tresys.com>,
	Chris PeBenito <pebenito@gentoo.org>,
	Russell Coker <russell@coker.com.au>,
	SE Linux <selinux@tycho.nsa.gov>,
	Daniel J Walsh <dwalsh@redhat.com>
Subject: Re: specifying groups of types
Date: Fri, 16 Jan 2004 13:36:35 -0500	[thread overview]
Message-ID: <1074278194.23661.134.camel@colossus.columbia.tresys.com> (raw)
In-Reply-To: <1074277054.24719.113.camel@moss-spartans.epoch.ncsc.mil>

On Fri, 2004-01-16 at 13:17, Stephen Smalley wrote:
> On Fri, 2004-01-16 at 11:50, Karl MacMillan wrote:
> > I'm not certain that we want these to be order dependent. I can imagine
> > a policy writer doing
> > 
> > allow { attr_a -sysadm_t attr_b} . . . 
> > 
> > and being surprised that sysadm_t was allowed because it was in attr_b.
> 
> So, you want something like the attached (untested) patch?
> Still wouldn't prevent one allow rule from adding back a
> type excluded by another allow rule...

Exactly. I don't think that we want to prevent other rules from adding
back the type, just consider the list of types within a rule as a whole.
The patch looks correct to me at first glance, but I didn't test it
either. After testing, will this change go in? I'm working on supporting
this in our tools and need to know the final semantics.

Thanks,

Karl

-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
http://www.tresys.com
(410) 290-1411 x134


--
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:[~2004-01-16 18:36 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-11  4:35 specifying groups of types Russell Coker
2003-10-14 12:22 ` Stephen Smalley
2003-10-14 18:56   ` David Caplan
2003-10-16  5:07     ` Chris PeBenito
2003-11-02 17:43     ` Chris PeBenito
2003-11-03 13:53       ` Stephen Smalley
2003-11-03 13:55       ` David Caplan
2004-01-15 14:31     ` Stephen Smalley
2004-01-16 16:50       ` Karl MacMillan
2004-01-16 18:17         ` Stephen Smalley
2004-01-16 18:36           ` Karl MacMillan [this message]
2004-01-16 18:48             ` Stephen Smalley
2004-01-16 21:03           ` Trival relabel Problem Thomas DuBuisson
2004-01-16 21:14             ` 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=1074278194.23661.134.camel@colossus.columbia.tresys.com \
    --to=kmacmillan@tresys.com \
    --cc=dac@tresys.com \
    --cc=dwalsh@redhat.com \
    --cc=pebenito@gentoo.org \
    --cc=russell@coker.com.au \
    --cc=sds@epoch.ncsc.mil \
    --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.