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? 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. Thanks -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
