two new questions (sort of)

[Stephen Smalley]

On Wed, 2008-01-09 at 11:09 -0800, Clarkson, Mike R (US SSA) wrote:
> 
> > -----Original Message-----
> > From: Stephen Smalley [mailto:sds at tycho.nsa.gov]
> > Sent: Wednesday, January 09, 2008 10:15 AM
> > To: Clarkson, Mike R (US SSA)
> > Cc: Eric Paris; Daniel J Walsh; fedora-selinux-list at redhat.com
> > Subject: RE: two new questions (sort of)
> > 
> > 
> > On Wed, 2008-01-09 at 09:27 -0800, Clarkson, Mike R (US SSA) wrote:
> > > I'll file a bug.
> > >
> > > Here is what I did:
> > >
> > > # semodule -b /usr/share/selinux/mls/enableaudit.pp
> > > libsepol.scope_copy_callback: acct: Duplicate declaration in module:
> > > type/attribute acct_t
> > > libsemanage.semanage_link_sandbox: Link packages failed
> > > semodule:  Failed!
> > > # semodule -r acct
> > > # semodule -b /usr/share/selinux/mls/enableaudit.pp
> > > libsepol.scope_copy_callback: aide: Duplicate declaration in module:
> > > type/attribute aide_t
> > > libsemanage.semanage_link_sandbox: Link packages failed
> > > semodule:  Failed!
> > 
> > That suggests that enableaudit.pp wasn't built the same way (or
> against
> > the same policy) as the policy you are using.  Are you using a custom
> > policy or the RH-provided selinux-policy-mls?
> 
> I thought I was using the RedHat provided mls policy. I downloaded the
> src from RedHat and built as a strict-mls policy.

There should have already been a selinux-policy-mls binary rpm available
that you could have used.  If you rebuilt from source, you may have used
a different modules.conf or build.conf settings, unless you just rebuild
their src rpm as is via rpmbuild.

> > 
> > Also, I suspect that stripping dontaudits from your base module isn't
> > going to help you since you are talking about your own custom module
> for
> > your own application, right?  So I'd start by looking at the
> > postprocessed module file for dontaudits and strip those by hand.  Or
> > just build a modern selinux userland into a private directory, set
> PATH
> > and LD_LIBRARY_PATH to refer to it, and run the modern semodule -DB
> > command from it.
> > 
> 
> I think the only non-base module coming into play is my small setcontest
> module, and I didn't add any dontaudit statements it. I do call a number
> of interfaces that may add dontaudit statements but I think most/all of
> them are to base modules.

Interfaces are just m4 macros at present, so they get expanded into your
module, not in the base.  So any dontaudits they included would show up
in your module after processing by m4.

> By "postprocessed module file" do you mean the setcontest.pp file? This
> file doesn't appear to have any dontaudit statements in it, but aren't
> *.pp files binary? I wouldn't know how to strip out a dontaudit
> statement if I found one.

When you do a 'make -f /usr/share/selinux/devel/Makefile', it creates a
tmp/ directory, processes your .te file, creating a postprocessed
tmp/<name>.tmp file.  That's the real module content.  Then that gets
fed into checkmodule and that gets fed into semodule_package.  So, for
example, you might do the following to strip dontaudits from your
module:
	cd tmp/
	grep -v dontaudit setcontext.tmp > foo
	mv foo setcontext.tmp
	checkmodule -m -M -o setcontext.mod setcontext.tmp
	semodule_package -o setcontext.pp -m setcontext.mod -f setcontext.fc
	semodule -i setcontext.pp

> I'm not sure what you mean by "build a modern selinux userland ...". 

Grab the sources of the current selinux userland (ones that support
semodule -DB) and compile them?

-- 
Stephen Smalley
National Security Agency