Re: [PATCH v3 2/2] libsepol: Fix type alias handling in kernel_to_conf

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 27, 2020 at 5:16 PM James Carter <jwcart2@xxxxxxxxx> wrote:
>
> On Wed, May 27, 2020 at 10:23 AM Stephen Smalley
> <stephen.smalley.work@xxxxxxxxx> wrote:
> >
> > On Fri, May 22, 2020 at 10:55 AM James Carter <jwcart2@xxxxxxxxx> 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@xxxxxxxxx>
> >
> > This fixes the missing alias problem, so:
> > Acked-by: Stephen Smalley <stephen.smalley.work@xxxxxxxxx>
> >
> > 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?



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux