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@xxxxxxxxxxxxx] > Sent: Tuesday, January 08, 2008 1:30 PM > To: Clarkson, Mike R (US SSA) > Cc: fedora-selinux-list@xxxxxxxxxx; 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
