two new questions (sort of)

Wed Jan 9 19:09:58 UTC 2008

> -----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.

> 
> 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.

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.

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

> >
> >
> > > -----Original Message-----
> > > From: Eric Paris [mailto:eparis at redhat.com]
> > > Sent: Tuesday, January 08, 2008 7:34 PM
> > > To: Clarkson, Mike R (US SSA)
> > > Cc: Stephen Smalley; Daniel J Walsh;
fedora-selinux-list at redhat.com
> > > Subject: RE: two new questions (sort of)
> > >
> > > enableaudit.pp is a base module, are you using -i or -b to load
it?
> > If
> > > you can't just semodule -b enableaudit.pp file a bug explaining
what
> > you
> > > did and what went wrong  (dan loves bugs, i heard him say it)
> > >
> > > -Eric
> > >
> > > On Tue, 2008-01-08 at 17:11 -0800, Clarkson, Mike R (US SSA)
wrote:
> > > > Thanks. I wasn't aware that all dontaudit rules could be
disabled.
> > > >
> > > > It looks like RHEL5.1 doesn't have the -D option available for
> > semodule,
> > > > so I'm attempting to use the older method of loading
enableaudit.pp.
> > I
> > > > keep getting duplicate declaration errors. It appears that to
load
> > > > enableaudit.pp, I first need to remove nearly all the non-base
> > modules.
> > > > Is there an easier method to do that other than either of the
> > following?
> > > > 	-using "semodule -i" and listing all the modules
> > > > 	-changing each module to off in the modules.conf file
> > > >
> > > > Thanks
> > > >
> > > > > -----Original Message-----
> > > > > From: Stephen Smalley [mailto:sds at tycho.nsa.gov]
> > > > > Sent: Tuesday, January 08, 2008 1:30 PM
> > > > > To: Clarkson, Mike R (US SSA)
> > > > > Cc: fedora-selinux-list at redhat.com; Daniel J Walsh
> > > > > Subject: Re: two new questions (sort of)
> > > > >
> > > > >
> > > > > On Tue, 2008-01-08 at 12:53 -0800, Clarkson, Mike R (US SSA)
> > wrote:
> > > > > > I've been testing dynamic transitions with a simple test
program
> > > > that
> > > > > > uses setcon to change from one mls level to another, as well
as
> > one
> > > > > > domain to another. I wrote a policy for this test program
and
> > > > provided
> > > > > > all the rules necessary to remove all of the avc denials
from
> > the
> > > > audit
> > > > > > log. When I run my program in permissive mode, it works as
> > expected
> > > > > > without adding any avc denial messages to the audit log. But
> > when I
> > > > > > switch to enforcing mode, the setcon call fails. Maybe there
are
> > > > some
> > > > > > dontaudit statements that come with the policy causing this.
I'm
> > > > using
> > > > > > RHEL5.1 with the mls policy.Any ideas as to what may be
causing
> > > > this?
> > > > >
> > > > > Try loading policy without any dontaudit rules and try again.
> > > > > With modern userland, you can just do:
> > > > > 	semodule -DB
> > > > > to remove all dontaudits from policy and load it.  semodule -B
> > later
> > > > > will revert the change.
> > > > >
> > > > > The old way before semodule -DB was to install enableaudit.pp
(a
> > base
> > > > > module with dontaudits stripped at build time)
> > > > > from /usr/share/selinux/$SELINUXTYPE.  But that only affects
the
> > base
> > > > > module, not any other modules.  So if this is for a policy
module
> > > > you've
> > > > > created, you should really look there to see what dontaudits
are
> > in
> > > > the
> > > > > postprocessed file under the tmp directory.
> > > > >
> > > > > > Since the subject of dynamic transitions seems to raise much
> > angst
> > > > and
> > > > > > gnashing of teeth, I thought I'd ask if there is a better
way to
> > > > solve
> > > > > > the problem that we have? I'm investigating dynamic
transitions
> > for
> > > > the
> > > > > > following purpose. We have services that we run that take a
long
> > > > time to
> > > > > > start up, too long to start them up on demand. We want to
have a
> > > > pool of
> > > > > > them up and running, waiting to be tasked by a server. But
we'll
> > be
> > > > > > running an MLS system with many compartments and possible
> > > > combinations
> > > > > > of compartments so it is not feasible to have services up
and
> > > > running
> > > > > > for all the compartment combinations. The idea is to have a
pool
> > of
> > > > > > services initialize at some default level, and then assign
them
> > to
> > > > the
> > > > > > correct level/compartment when tasked. Upon completing a
task, a
> > > > service
> > > > > > would shut down and a new service would be started to
replace
> > it, at
> > > > the
> > > > > > default level. Two domains would be used. A service
> > initialization
> > > > > > domain, and a service running domain. The service
initialization
> > > > domain
> > > > > > would have the capability of dynamic transitions. The
service
> > > > running
> > > > > > domain would not. Therefore, when the service is tasked, it
also
> > > > > > dynamically transitions to the correct level and to the
service
> > > > running
> > > > > > domain. From that point on it no longer has the capability
of
> > > > further
> > > > > > dynamic transitions. If there is a better way to solve this
> > problem,
> > > > I'd
> > > > > > like to know.
> > > > >
> > > > > exec based transitions are preferable as we can control the
> > > > inheritance
> > > > > of state across the transition and the initialization of the
> > process
> > > > in
> > > > > the new context, including binding entry into the context to a
> > > > specific
> > > > > executable.  But it does carry an overhead, of course.
> > Refactoring
> > > > your
> > > > > service program may be possible, or maybe not.
> > > > >
> > > > > These kinds of questions are likely better suited to selinux
list
> > > > rather
> > > > > than fedora selinux list, btw.  Not really fedora specific.
> > > > >
> > > > > --
> > > > > Stephen Smalley
> > > > > National Security Agency
> > > >
> > > >
> > > >
> > > > --
> > > > fedora-selinux-list mailing list
> > > > fedora-selinux-list at redhat.com
> > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >
> >
> --
> Stephen Smalley
> National Security Agency