-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
Sent: Wednesday, January 09, 2008 10:15 AM
To: Clarkson, Mike R (US SSA)
Cc: Eric Paris; Daniel J Walsh; fedora-selinux-list(a)redhat.com
Subject: RE: two new questions (sort of)
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?
I thought I was using the RedHat provided mls policy. I downloaded the
src from RedHat and built as a strict-mls policy.
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.
I think the only non-base module coming into play is my small setcontest
module, and I didn't add any dontaudit statements it. I do call a number
of interfaces that may add dontaudit statements but I think most/all of
them are to base modules.
By "postprocessed module file" do you mean the setcontest.pp file? This
file doesn't appear to have any dontaudit statements in it, but aren't
*.pp files binary? I wouldn't know how to strip out a dontaudit
statement if I found one.
I'm not sure what you mean by "build a modern selinux userland ...".
>
>
> > -----Original Message-----
> > From: Eric Paris [mailto:eparis@redhat.com]
> > Sent: Tuesday, January 08, 2008 7:34 PM
> > To: Clarkson, Mike R (US SSA)
> > Cc: Stephen Smalley; Daniel J Walsh;
fedora-selinux-list(a)redhat.com
> > 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@tycho.nsa.gov]
> > > > Sent: Tuesday, January 08, 2008 1:30 PM
> > > > To: Clarkson, Mike R (US SSA)
> > > > Cc: fedora-selinux-list(a)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(a)redhat.com
> > >
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>
>
--
Stephen Smalley
National Security Agency