All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Smalley <stephen.smalley.work@gmail.com>
To: Ondrej Mosnacek <omosnace@redhat.com>
Cc: James Carter <jwcart2@gmail.com>,
	SElinux list <selinux@vger.kernel.org>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	James Carter <jwcart2@tycho.nsa.gov>
Subject: Re: [PATCH 0/3] libsepol: Speed up policy optimization
Date: Wed, 4 Mar 2020 09:26:34 -0500	[thread overview]
Message-ID: <CAEjxPJ5-nzostsGnca1OcVT9hm6XWP9F1ceFCU3--RAzLHXERQ@mail.gmail.com> (raw)
In-Reply-To: <CAFqZXNunTQfLAc7JAfZyvynPS0s=ADK0fbT1rXrcUCsMiDk9HA@mail.gmail.com>

On Wed, Mar 4, 2020 at 4:07 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> I played with this a bit by recompiling the local binary policy with
> secilc and then comparing the CIL of both binary policies (I used this
> script [1]) and the results are a bit confusing... There is no
> difference in result between -X 0 and -X 1 [2] and in both cases it
> removes some unused attributes (those are only referenced from
> neverallow rules) that were in the original policy
> (/etc/selinux/targeted/policy/policy.31 from my Fedora 31 machine),
> but not in the one recompiled via checkpolicy -C + secilc... At least
> I was able to confirm that secilc -X 2 really removes the attributes
> that have only one type and reduces the policy size by a few
> kilobytes.
>
> I suspect that the reason for the unremoved attributes in the policy
> built by semodule are due to a bug in libsepol: It seems that when it
> starts with a cildb that has the neverallow rules in the input policy
> + has disable_neverallow set, it removes the rules but not the
> attributes that are used only in them. Only when it reads the policy
> again, it identifies these unused attributes (since there are no
> longer any neverallow rules in the input) and removes them
> unconditionally. It could be something else, but if I'm right then I
> think libsepol should be fixed to remove the unused attributes right
> away. I don't dare digging into the CIL code to investigate it, though
> ;)

James will have to confirm the details but IIRC we had to keep
attributes in the policy
when they are referenced by a neverallow in order to avoid breaking
Android because
it uses the attribute definition from the policy as part of CTS
validation of OEM policies
(it extracts the neverallows from the AOSP policy, extracts the binary
policy from the device,
and checks the neverallows against the device policy).

>
> [1] https://gitlab.com/omos/selinux-misc/-/blob/master/diffexpand.sh
> [2] Okay, this part is not really confusing, sonce semodule should
> already build the policy with an equivalent of -X 1, so -X 0 should
> yield the same result.

  reply	other threads:[~2020-03-04 14:25 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-27 16:02 [PATCH 0/3] libsepol: Speed up policy optimization Ondrej Mosnacek
2020-02-27 16:02 ` [PATCH 1/3] libsepol: skip unnecessary check in build_type_map() Ondrej Mosnacek
2020-03-17 18:19   ` Stephen Smalley
2020-03-19 19:39     ` James Carter
2020-02-27 16:02 ` [PATCH 2/3] libsepol: optimize inner loop " Ondrej Mosnacek
2020-03-02 15:24   ` James Carter
2020-03-02 16:31     ` James Carter
2020-03-17 18:22   ` Stephen Smalley
2020-03-19 19:39     ` James Carter
2020-02-27 16:02 ` [PATCH 3/3] libsepol: speed up policy optimization Ondrej Mosnacek
2020-03-17 18:24   ` Stephen Smalley
2020-03-19 19:39     ` James Carter
2020-02-28 18:08 ` [PATCH 0/3] libsepol: Speed " Stephen Smalley
2020-03-02 14:50   ` Stephen Smalley
2020-03-02 14:58     ` Stephen Smalley
2020-03-02 15:46       ` Ondrej Mosnacek
2020-03-02 18:45         ` Stephen Smalley
2020-03-02 20:24           ` Stephen Smalley
2020-03-02 21:08             ` Ondrej Mosnacek
2020-03-04  9:07               ` Ondrej Mosnacek
2020-03-04 14:26                 ` Stephen Smalley [this message]
2020-03-04 15:33                   ` James Carter
2020-03-05 13:45                     ` Ondrej Mosnacek
2020-03-02 20:12         ` Stephen Smalley
2020-03-13 11:53 ` Ondrej Mosnacek
2020-03-13 19:07   ` Stephen Smalley
2020-03-13 19:57     ` 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=CAEjxPJ5-nzostsGnca1OcVT9hm6XWP9F1ceFCU3--RAzLHXERQ@mail.gmail.com \
    --to=stephen.smalley.work@gmail.com \
    --cc=jwcart2@gmail.com \
    --cc=jwcart2@tycho.nsa.gov \
    --cc=omosnace@redhat.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@vger.kernel.org \
    /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.