From: Stephen Smalley <sds@tycho.nsa.gov>
To: Nick Kralevich <nnk@google.com>, SELinux <Selinux@tycho.nsa.gov>
Subject: Re: neverallow rules and self negation
Date: Mon, 9 Nov 2015 09:28:55 -0500 [thread overview]
Message-ID: <5640ADA7.8030801@tycho.nsa.gov> (raw)
In-Reply-To: <CAFJ0LnG+=byi92+d6EWyJDikgxxUjX8E1WAHbu4ZBix-65mMYw@mail.gmail.com>
On 11/07/2015 11:29 PM, Nick Kralevich wrote:
> Consider the following rules:
>
> attribute foo;
> type asdf, foo;
> type asdf2, foo;
> allow asdf self:dir search;
> neverallow foo { foo -self }:dir search;
>
> This particular policy fails to compile with the following error:
>
> libsepol.report_failure: neverallow on line XXX of XXX (or line XXX of
> policy.conf) violated by allow asdf asdf:dir { search };
> libsepol.check_assertions: 1 neverallow failures occurred
>
> The intent of the neverallow rule is to prohibit cross domain access
> to some resource, but allow access within the same domain. Something
> like:
>
> neverallow asdf { foo -asdf }:dir search;
> neverallow asdf2 { foo -asdf2 }:dir search;
>
> 1) Is the behavior described above a bug or working as intended?
> 2) Is there a way to write a neverallow rule where the target uses
> "-self", and if so, what does it mean?
It doesn't look to me as if "-self" has ever been supported correctly
either by the checkpolicy parser or by the libsepol neverallow/assertion
checker. So, it's a bug, but not sure how involved a fix will be
(beyond just having checkpolicy reject it in the first place).
next prev parent reply other threads:[~2015-11-09 14:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-08 4:29 neverallow rules and self negation Nick Kralevich
2015-11-09 14:28 ` Stephen Smalley [this message]
2015-11-09 14:30 ` James Carter
2015-11-12 20:07 ` Nick Kralevich
2015-11-13 15:30 ` Joshua Brindle
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=5640ADA7.8030801@tycho.nsa.gov \
--to=sds@tycho.nsa.gov \
--cc=Selinux@tycho.nsa.gov \
--cc=nnk@google.com \
/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.