On Wed, 2008-01-09 at 09:27 -0800, Clarkson, Mike R (US SSA) wrote: > I'll file a bug. > > Here is what I did: > > # semodule -b /usr/share/selinux/mls/enableaudit.pp > libsepol.scope_copy_callback: acct: Duplicate declaration in module: > type/attribute acct_t > libsemanage.semanage_link_sandbox: Link packages failed > semodule: Failed! > # semodule -r acct > # semodule -b /usr/share/selinux/mls/enableaudit.pp > libsepol.scope_copy_callback: aide: Duplicate declaration in module: > type/attribute aide_t > libsemanage.semanage_link_sandbox: Link packages failed > semodule: Failed! That suggests that enableaudit.pp wasn't built the same way (or against the same policy) as the policy you are using. Are you using a custom policy or the RH-provided selinux-policy-mls? Also, I suspect that stripping dontaudits from your base module isn't going to help you since you are talking about your own custom module for your own application, right? So I'd start by looking at the postprocessed module file for dontaudits and strip those by hand. Or just build a modern selinux userland into a private directory, set PATH and LD_LIBRARY_PATH to refer to it, and run the modern semodule -DB command from it. > > > > -----Original Message----- > > From: Eric Paris [mailto:eparis@xxxxxxxxxx] > > Sent: Tuesday, January 08, 2008 7:34 PM > > To: Clarkson, Mike R (US SSA) > > Cc: Stephen Smalley; Daniel J Walsh; fedora-selinux-list@xxxxxxxxxx > > Subject: RE: two new questions (sort of) > > > > 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@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 > > -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
