All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sven Vermeulen <sven.vermeulen@siphos.be>
To: selinux@tycho.nsa.gov
Subject: Disabling rules
Date: Thu, 9 May 2013 20:33:36 +0200	[thread overview]
Message-ID: <20130509183336.GA16336@siphos.be> (raw)

Hi all,

I was wondering if we could include a method for users or administrators to
remove (or disable) particular allow statements from the policy, without the
need to unload the module that provides the policy and replace it with a
similar policy (offering the same types and such, but just doesn't include
those rules the admin doesn't want to enable).

>From my understanding, I think this has been discussed in the past, but not
accepted due to it becoming a mess (for admins) to maintain such policies:
in one module, rules would be allowed, and in another denied again.

Still, we can disable dontaudits, disable an entire module or put a
particular domain in permissive mode. Perhaps we could look into disabling
certain statements as well? 

The reason I ask is that administrators might want to some just a fraction
of the granted permissions in the default policy, without having to maintain
an entire policy themselves. This could be useful for temporarily working
around possible vulnerabilities.

For (policy) developers as well, this could be a useful feature. One can
selectively disable some rules and test out the impact. For instance,
suppose we want to reduce the number of "open" permissions on certain files.
Historically, "open" was granted as well, but we might want to look into
inherited read/write access (without "open"). With such feature, we can test
out the impact without the need to do the (intensive) policy updates first.
Afterwards, the policy can then be properly reduced.

I was considering using constraints to implement this myself (locally), but
constraints cannot be added to modules (need to be in base according to the
selinuxproject wiki).

Wkr,
	Sven Vermeulen

--
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:[~2013-05-09 18:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-09 18:33 Sven Vermeulen [this message]
2013-05-09 18:47 ` Disabling rules 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=20130509183336.GA16336@siphos.be \
    --to=sven.vermeulen@siphos.be \
    --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.