two new questions (sort of)
Eric Paris
eparis at redhat.com
Wed Jan 9 03:34:10 UTC 2008
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
More information about the fedora-selinux-list
mailing list