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
