From: Serge Hallyn <serge.hallyn@gmail.com>
To: SELinux <SELinux@tycho.nsa.gov>
Subject: TE Policy Modules for SELinux policies
Date: Mon, 10 Jan 2005 22:35:42 -0600 [thread overview]
Message-ID: <46ce702f0501102035329f22c9@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2366 bytes --]
Hi,
Three or four years ago I started using "policy modules" to write DTE
policies. A year or two ago I considered porting/extending the policy
modules to support selinux. I've played on and off, and finally decided
this weekend to get it to a state where I could send it out.
The attached tarball contains sel_pc.py (and supporting code), which
converts policy modules to an selinux policy. A sample module is in
selinux_policy_modules/modules/basic, which compiled to bootable
policies - under enforcing mode. I have not added sufficient permisssions
(ie to class lnkfile, process, etc) to bother trying to use enforcing.
One way in which this differs from writing selinux policy by hand, is that
access rules are actually grants and requests (and denials) by specific
domains and types. As such, priorities can be used to resolve conflicts
in intuitive ways. For instance, if we have
type etc_t
access boot_d f:r
access user_d none
end
domain user_d
type etc_t f:r
end
Then domain user_d will not receive the f:r to etc_t, because the "incoming"
permission grant (into etc_t) trumps the "outgoing" permission request (from
user_d). Of course this example isn't very useful, but it becomes useful with
grouping, ie domain user_d can simply ask for 'f:r' to 'bin.*" or "all", even if
etc_t is defined as "bin.etc_t".
The DTE module compiler code had support for automatic policy analysis.
I have not yet tested this under sel_pc, but will do plan to do so. One
class which I had written, for instance, checked for maintenance of
Bell-LaPadula dominates relations among pre-existing types when a new module
was applied to a policy. (an idea I took from TIS' live policy extension
paper)
Usage:
tar jxf selinux_policy_modules.03.tar.bz2
cd selinux_policy_modules/modules
../src/sel_pc.py -f list -o policy -c file_contexts
checkpolicy policy -o policy.bin
install policy.bin and set file_contexts
(I installed under /etc/selinux/serge/, for instance)
TODO:
general debugging
write better policies
test under enforcing
test policy consistency classes (blp, mod_blp, etc)
incorporate booleans into module language
thanks,
-serge
PS - For more information, usenix members can read
http://www.usenix.org/events/usenix04/tech/freenix/hallyn.html. Sorry
it's not publically available...
[-- Attachment #2: selinux_policy_modules.03.tar.bz2 --]
[-- Type: application/octet-stream, Size: 17848 bytes --]
next reply other threads:[~2005-01-11 4:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-11 4:35 Serge Hallyn [this message]
2005-01-11 20:01 ` TE Policy Modules for SELinux policies Serge Hallyn
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=46ce702f0501102035329f22c9@mail.gmail.com \
--to=serge.hallyn@gmail.com \
--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.