two new questions (sort of)

Clarkson, Mike R (US SSA) mike.clarkson at baesystems.com
Wed Jan 9 01:11:50 UTC 2008


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






More information about the fedora-selinux-list mailing list