selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Smalley <stephen.smalley.work@gmail.com>
To: James Carter <jwcart2@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: Fri, 29 May 2020 08:57:31 -0400	[thread overview]
Message-ID: <CAEjxPJ74YYyfJ2kHyPw1Y4Sk0ZG3-YEn+Dq3+PuM1qYCyGsScg@mail.gmail.com> (raw)
In-Reply-To: <CAP+JOzQv3K-dYpnfC5ZMyEMkv+LqU6nFC8kff3i+3Xr7=byJmg@mail.gmail.com>

On Wed, May 27, 2020 at 5:16 PM James Carter <jwcart2@gmail.com> wrote:
>
> 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?

Possible difference in default behaviors for secilc versus libsemanage
direct usage of cil_compile()?
Or something to do with the whole checkmodule -> semodule_package ->
/usr/libexec/selinux/hll/pp translation?

  reply	other threads:[~2020-05-29 12:57 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
2020-05-29 12:57       ` Stephen Smalley [this message]
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=CAEjxPJ74YYyfJ2kHyPw1Y4Sk0ZG3-YEn+Dq3+PuM1qYCyGsScg@mail.gmail.com \
    --to=stephen.smalley.work@gmail.com \
    --cc=jwcart2@gmail.com \
    --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 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).