All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darrel Goeddel <dgoeddel@TrustedCS.com>
To: "'SELinux List'" <SELinux@tycho.nsa.gov>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
	Eric Paris <eparis@redhat.com>,
	Joshua Brindle <jbrindle@tresys.com>
Subject: [PATCH 0/2] new and improved range_transition statements
Date: Fri, 28 Jul 2006 10:11:21 -0500	[thread overview]
Message-ID: <44CA2919.4010708@trustedcs.com> (raw)

This following patches allow for specification of security classes for
range_transition statements in the policy.  This is intended to address
a solution for RedHat Bugzilla #185436.

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185436

While working on this format change to allow class specification, it was
noted that the current range_transition handling in the policy toolchain was
not ideal.  It expanded things at compile time and there was no way to get
these statements into policy modules.  So, in addition to changing the kernel
policy format and base policy format in a trivial manner to support the
desired functionality, I also tried to make the base and module formats more
robust when handling range_transition rules.  Hopefully, this format will
allow for range_transition statements in modules with additional work for
libsepol in the (near?) future.  I will defer the toolchain gurus on the
completeness of my approach ;)  This patch set has been tested in the
following configurations:

old kernel / all old policy - sure glad that worked
old kernel / old format modules generating a new format kernel policy that
  is automatically downgraded at load time
old kernel / new format modules generating a new format kernel policy that
  is automatically downgraded at load time
new kernel / old format modules generating a new format kernel policy
old kernel / new format modules generating a new format kernel policy

The old style statements (without class specification) are correctly
interpreted as applying to the "process" class.  Old and new style statements
can be used together happily.  Duplicate and conflicting rules are properly
handled when expanding the rules with dups being dropped and conflicts
resulting in an error.  Also, a kernel policy that contains range_transitions
for classes other than "process" will have those transition rules dropped when
it is downgraded, but all "process" rules will remain as the old format supports
them.

The kernel change is fairly simple.  Sure would be nice to get that into 2.6.18
since it is for a bug fix...

The toolchain changes are a bit more complex, although it sure seems a lot easier
than it did when I started looking at the code.  I'd appreciate some scrutiny of
this, especially in the area of future support for range_transition statements in
policy modules.  I feel that will be very necessary and I hope to ease that path
with the format change.

-- 

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.

             reply	other threads:[~2006-07-28 15:11 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-28 15:11 Darrel Goeddel [this message]
2006-07-31 13:07 ` [PATCH 0/2] new and improved range_transition statements Karl MacMillan
2006-07-31 13:56   ` Stephen Smalley
2006-07-31 13:58     ` Karl MacMillan
2006-07-31 14:01       ` Joshua Brindle
2006-07-31 14:13         ` Karl MacMillan
2006-07-31 14:23           ` Joshua Brindle
2006-07-31 14:55             ` Karl MacMillan
2006-07-31 14:30       ` Stephen Smalley
2006-07-31 14:51         ` Karl MacMillan
2006-07-31 14:54         ` Darrel Goeddel
2006-07-31 14:28     ` Valdis.Kletnieks
2006-07-31 14:43       ` Stephen Smalley
2006-07-31 15:10         ` Valdis.Kletnieks
2006-08-04 13:19           ` Stephen Smalley
2006-08-04 14:47             ` James Morris
2006-08-04 17:24             ` Darrel Goeddel
2006-08-07 12:04             ` Joshua Brindle
2006-08-07 14:19               ` Stephen Smalley
2006-08-07 14:32                 ` Joshua Brindle
2006-08-07 14:57                   ` Stephen Smalley
2006-08-07 14:34             ` Christopher J. PeBenito
2006-08-07 19:17               ` 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=44CA2919.4010708@trustedcs.com \
    --to=dgoeddel@trustedcs.com \
    --cc=SELinux@tycho.nsa.gov \
    --cc=eparis@redhat.com \
    --cc=jbrindle@tresys.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.