selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Carter <jwcart2@gmail.com>
To: Stephen Smalley <stephen.smalley.work@gmail.com>
Cc: SElinux list <selinux@vger.kernel.org>
Subject: Re: [PATCH v3 2/2] libsepol: Fix type alias handling in kernel_to_conf
Date: Wed, 27 May 2020 17:15:58 -0400	[thread overview]
Message-ID: <CAP+JOzQv3K-dYpnfC5ZMyEMkv+LqU6nFC8kff3i+3Xr7=byJmg@mail.gmail.com> (raw)
In-Reply-To: <CAEjxPJ6FBrGviZVjGQE=-wfVsetubcKfM-FTTqpAp9ZnCF_geA@mail.gmail.com>

On Wed, May 27, 2020 at 10:23 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Fri, May 22, 2020 at 10:55 AM James Carter <jwcart2@gmail.com> wrote:
> >
> > Type alias rules are not written out when converting a binary kernel
> > policy to a policy.conf. The problem is that type aliases are not in
> > the type_val_to_struct array and that is what is being used to find
> > the aliases.
> >
> > Since type aliases are only in the types hashtable, walk that to
> > find the type aliases.
> >
> > Fixed the syntax of the typalias rule which requires "alias" to come
> > between the type and the aliases (ex/ typealias TYPE alias ALIAS;).
> >
> > Fixes: 0a08fd1e69797d6a ("libsepol: Add ability to convert binary
> >        policy to policy.conf file")
> >
> > Signed-off-by: James Carter <jwcart2@gmail.com>
>
> This fixes the missing alias problem, so:
> Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
>
> However, in testing these, I noticed that if I do the following:
> checkpolicy -MF -o policy.conf -b /etc/selinux/targeted/policy/policy.32
> checkpolicy -MC -o policy.cil -b /etc/selinux/targeted/policy/policy.32
> checkpolicy -M -o policyfromconf policy.conf
> secilc -o policyfromcil policy.cil
> checkpolicy -M -o policyfromkernel -b /etc/selinux/targeted/policy.32
>
> then the three policyfrom* files differ in length and contents.
> Decompiling them all via checkpolicy -MF (or -MC) and diff'ing those
> (since sediff takes too long) appears to suggest differences from
> attribute removal (odd since I thought you reverted that), redundant
> rule removal (isn't that off by default too?), and portcon ordering
> (by protocol).
> Optimally we should able to regenerate the same kernel policy from all
> three (although we might need to run the kernel policy through
> checkpolicy to normalize ordering).

Starting with a  policy.31 file and running the following:
$PREFIX/usr/bin/checkpolicy -C -M -b -o policy.cil policy.31
$PREFIX/usr/bin/secilc -M 1 -o policy.cil.bin policy.cil
$PREFIX/usr/bin/checkpolicy -C -M -b -o policy.2.cil policy.cil.bin
$PREFIX/usr/bin/secilc -M 1 -o policy.2.cil.bin policy.2.cil
$PREFIX/usr/bin/checkpolicy -C -M -b -o policy.3.cil policy.2.cil.bin
$PREFIX/usr/bin/secilc -M 1 -o policy.3.cil.bin policy.3.cil
$PREFIX/usr/bin/checkpolicy -C -M -b -o policy.4.cil policy.3.cil.bin
$PREFIX/usr/bin/checkpolicy -M -b -o policy.bin policy.31
$PREFIX/usr/bin/checkpolicy -F -M -b -o policy.conf policy.31
$PREFIX/usr/bin/checkpolicy -M -o policy.conf.bin policy.conf
$PREFIX/usr/bin/checkpolicy -F -M -b -o policy.2.conf policy.conf.bin
$PREFIX/usr/bin/checkpolicy -M -o policy.2.conf.bin policy.2.conf
$PREFIX/usr/bin/checkpolicy -F -M -b -o policy.3.conf policy.2.conf.bin
$PREFIX/usr/bin/checkpolicy -M -o policy.3.conf.bin policy.3.conf
$PREFIX/usr/bin/checkpolicy -F -M -b -o policy.4.conf policy.3.conf.bin

After the first conversion to policy.cil, all CIL binaries are the
same in everyway.
After the first conversion to policy.conf, every conf binary is the
same size and every other conf binary is the same. (sctp and udp
portcon rules for the same port range swap positions.)

All CIL source policies after the initial policy.cil are the same. The
policy.cil has attributes that are in no rules, all other CIL binaries
and source have those removed.

After the initial policy.conf, every other conf file is the same.
(Again, it is the portcon rules for scp and udp that are swapped.)

The initial policy.conf has a bunch of duplicate rules.

I thought CIL sorted portcon rules like checkpolicy, so I am not sure
why the behavior is different.
I don't know why there are duplicate rules in the initial conversion
to a policy.conf file.
I am not sure about the attribute behavior. Why are they even in the
original binary if secilc is producing it?

Jim

  parent reply	other threads:[~2020-05-27 21:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-22 14:50 [PATCH v3 1/2] libsepol: Fix type alias handling in kernel_to_cil James Carter
2020-05-22 14:50 ` [PATCH v3 2/2] libsepol: Fix type alias handling in kernel_to_conf James Carter
2020-05-27 14:22   ` Stephen Smalley
2020-05-27 14:44     ` James Carter
2020-05-27 21:15     ` James Carter [this message]
2020-05-29 12:57       ` Stephen Smalley
2020-05-29 12:53     ` 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='CAP+JOzQv3K-dYpnfC5ZMyEMkv+LqU6nFC8kff3i+3Xr7=byJmg@mail.gmail.com' \
    --to=jwcart2@gmail.com \
    --cc=selinux@vger.kernel.org \
    --cc=stephen.smalley.work@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).