Re: Semodule accepts bad modules every other time

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

 



On Mon, May 18, 2020 at 9:56 AM Stephen Smalley
<stephen.smalley.work@xxxxxxxxx> wrote:
>
> On Mon, May 18, 2020 at 5:43 AM Topi Miettinen <toiwoton@xxxxxxxxx> wrote:
> >
> > Hi,
> >
> > I have a module, which can be compiled without problems but it can still
> > generate errors during load. However, every other time the load succeeds.
> >
> > Here's the example:
> > # cat foo.te
> > module foo 1.0;
> >
> > type file_type;
> >
> > require {
> >          type user_t; # dummy require statement to keep checkmodule happy
> > }
> > # make
> > Compiling default foo module
> > Creating default foo.pp policy package
> > rm tmp/foo.mod.fc tmp/foo.mod
> > # make QUIET=n load
> > Loading default modules: foo
> > /usr/sbin/semodule -i foo.pp
> > Re-declaration of type file_type
> > Failed to create node
> > Bad type declaration at /var/lib/selinux/default/tmp/modules/400/foo/cil:1
> > /usr/sbin/semodule:  Failed!
> > make: *** [/usr/share/selinux/devel/include/Makefile:148: tmp/loaded]
> > Error 1
> > # make QUIET=n load
> > Loading default modules: foo
> > /usr/sbin/semodule -i foo.pp
> > (no error)
> >
> > Running semodule directly:
> > # semodule -i foo.pp
> > Re-declaration of type file_type
> > Failed to create node
> > Bad type declaration at /var/lib/selinux/default/tmp/modules/400/foo/cil:1
> > semodule:  Failed!
> > # semodule -i foo.pp
> > # semodule -i foo.pp
> > Re-declaration of type file_type
> > Failed to create node
> > Bad type declaration at /var/lib/selinux/default/tmp/modules/400/foo/cil:1
> > semodule:  Failed!
> > # semodule -i foo.pp
> >
> > Maybe the failing transaction is not reverted properly and then the
> > failed module changes the system somehow? Some problem with detecting
> > redeclarations?
>
> Looks like a bug in libsepol to me:
> # valgrind semodule -i foo.pp
> ==5989== Memcheck, a memory error detector
> ==5989== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==5989== Using Valgrind-3.16.0.GIT and LibVEX; rerun with -h for copyright info
> ==5989== Command: semodule -i foo.pp
> ==5989==
> ==5989== Conditional jump or move depends on uninitialised value(s)
> ==5989==    at 0x48E02F5: cil_gen_node (cil_build_ast.c:129)
> ==5989==    by 0x48E3FD3: cil_gen_type (cil_build_ast.c:2315)
> ==5989==    by 0x48EBDC0: __cil_build_ast_node_helper (cil_build_ast.c:6261)
> ==5989==    by 0x490AF1D: cil_tree_walk_core (cil_tree.c:272)
> ==5989==    by 0x490B06C: cil_tree_walk (cil_tree.c:316)
> ==5989==    by 0x490AF8F: cil_tree_walk_core (cil_tree.c:284)
> ==5989==    by 0x490B06C: cil_tree_walk (cil_tree.c:316)
> ==5989==    by 0x490AF8F: cil_tree_walk_core (cil_tree.c:284)
> ==5989==    by 0x490B06C: cil_tree_walk (cil_tree.c:316)
> ==5989==    by 0x48ED269: cil_build_ast (cil_build_ast.c:6571)
> ==5989==    by 0x48D019F: cil_compile@@LIBSEPOL_1.1 (cil.c:564)
> ==5989==    by 0x498A646: semanage_direct_commit (direct_api.c:1419)
> ==5989==
> Re-declaration of type file_type
> Failed to create node
> Bad type declaration at /var/lib/selinux/targeted/tmp/modules/400/foo/cil:1
> semodule:  Failed!
>
> Without valgrind, I get a segfault.  This is with make DEBUG=1.

I didn't try valgrind with semodule -i (it only segfaults for me when
running under valgrind), but I did notice a segault every other time I
did semodule -vB (with or without valgrind).

Since file_type is declared as an attribute, there definitely should
be an error when you try to declare it as a type.

I'll take a closer look.

Jim



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

  Powered by Linux