From: Eric Paris <eparis@redhat.com>
To: selinux@tycho.nsa.gov
Subject: concept of a permissive domain
Date: Tue, 11 Sep 2007 15:13:01 -0400 [thread overview]
Message-ID: <1189537981.3407.51.camel@localhost.localdomain> (raw)
So there was a brief conversation between dan, karl, and myself today
about implementing a permissive subject domain. Basically there would
be some new language construct possibly "permissive httpd_t true;" which
would then set a flag. If this flag was set, all denials would be
logged but the operation would be permitted. This would make it
possible to create a type_exec_t and type_t for your new domain, mark it
as permissive/unconfined and run it as long as you like. Once you get
all your new allow rules you just remove the permissive bit. You didn't
have to setenforce the whole system.
First thought from Karl was to use the 'char primary' field of the
struct type_datum. Seems reasonable enough, after we have that
information in kernel it shouldn't take me too much playing around in
avc_has_perm_noaudit to check if this flag is set on a denial. I don't
think slowing down the denial path a little by having to call back in to
see if this flag was set for a given source sid is that big of deal.
Maybe I could keep it just about as fast by adding more flags
audit_allow_once (can't really reuse audit_allow) to the avd or
something like that, but it seems like a large waste of space to carry
another set of audit flags that won't be used much.
Thoughts? Other ways to implement this? Problems with the basic premis
of an unconfined domain?
-Eric
--
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 reply other threads:[~2007-09-11 19:14 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-11 19:13 Eric Paris [this message]
2007-09-11 20:31 ` concept of a permissive domain Daniel J Walsh
2007-09-11 21:26 ` Karl MacMillan
2007-09-11 21:47 ` Eric Paris
2007-09-12 13:27 ` Karl MacMillan
2007-09-12 13:57 ` Daniel J Walsh
2007-09-13 14:08 ` Stephen Smalley
2007-09-13 14:46 ` Karl MacMillan
2007-09-13 14:57 ` Stephen Smalley
2007-09-13 15:25 ` Karl MacMillan
2007-09-13 19:25 ` Daniel J Walsh
2007-09-13 19:38 ` Stephen Smalley
2007-09-13 20:16 ` Eric Paris
2007-09-18 20:24 ` Stephen Smalley
2007-09-18 20:50 ` Joshua Brindle
2007-09-18 21:54 ` Chad Sellers
2007-09-19 12:56 ` Daniel J Walsh
2007-09-19 14:22 ` Chad Sellers
2007-10-12 13:50 ` Daniel J Walsh
2007-10-12 17:49 ` Joshua Brindle
2007-10-12 18:07 ` Eric Paris
2007-10-12 19:03 ` Karl MacMillan
2007-10-12 19:09 ` Stephen Smalley
2007-10-12 18:40 ` Chad Sellers
2007-10-12 19:05 ` Karl MacMillan
2007-10-12 20:43 ` Chad Sellers
2007-10-12 21:01 ` Stephen Smalley
2007-10-12 21:21 ` Karl MacMillan
2007-10-12 23:38 ` Chad Sellers
2007-10-13 13:38 ` Daniel J Walsh
2007-10-14 10:14 ` Stefan Schulze Frielinghaus
2007-10-15 12:40 ` Daniel J Walsh
2007-10-15 16:52 ` Brett Lentz
2007-10-15 16:58 ` Stephen Smalley
2007-10-15 18:32 ` Daniel J Walsh
2007-10-15 18:40 ` Stephen Smalley
2007-10-15 18:57 ` Karl MacMillan
2007-10-15 19:09 ` Eric Paris
2007-10-17 19:47 ` Stephen Smalley
2007-10-17 21:50 ` Recurring SELinux events for similar violations Hasan Rezaul-CHR010
2007-10-17 22:18 ` Eric Paris
2007-10-17 22:22 ` Hasan Rezaul-CHR010
2007-10-18 13:13 ` Stephen Smalley
2007-10-18 14:32 ` Hasan Rezaul-CHR010
2007-11-29 20:06 ` Hasan Rezaul-CHR010
2007-11-29 20:16 ` Stephen Smalley
2007-11-29 21:26 ` Hasan Rezaul-CHR010
2007-11-29 21:32 ` Stephen Smalley
2007-11-29 21:45 ` Stephen Smalley
2007-10-15 17:26 ` concept of a permissive domain Chad Sellers
2007-10-12 19:07 ` Stephen Smalley
2007-10-12 19:30 ` Stephen Smalley
2007-09-19 16:35 ` Martin Orr
2007-09-19 16:41 ` Eric Paris
2007-09-20 14:41 ` Joshua Brindle
2007-09-20 14:46 ` Joshua Brindle
2007-09-19 16:52 ` Stephen Smalley
2007-09-24 14:59 ` Karl MacMillan
2007-09-13 20:25 ` Karl MacMillan
2007-09-14 14:15 ` James Carter
2007-09-14 14:45 ` Joshua Brindle
2007-09-14 15:15 ` Karl MacMillan
2007-09-11 22:57 ` Joshua Brindle
2007-09-12 13:26 ` Karl MacMillan
2007-09-13 13:11 ` Stephen Smalley
2007-09-13 13:19 ` Karl MacMillan
2007-09-13 13:25 ` Stephen Smalley
2007-09-13 13:59 ` Eric Paris
2007-09-13 14:23 ` Stephen Smalley
2007-09-13 14:36 ` Stephen Smalley
2007-09-13 14:42 ` Karl MacMillan
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=1189537981.3407.51.camel@localhost.localdomain \
--to=eparis@redhat.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.