FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora SELinux Support

 
 
LinkBack Thread Tools
 
Old 01-08-2008, 07:53 PM
"Clarkson, Mike R (US SSA)"
 
Default two new questions (sort of)

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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 01-08-2008, 08:30 PM
Stephen Smalley
 
Default 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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 01-09-2008, 12:11 AM
"Clarkson, Mike R (US SSA)"
 
Default two new questions (sort of)

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@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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 01-09-2008, 02:34 AM
Eric Paris
 
Default 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@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@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 01-09-2008, 04:27 PM
"Clarkson, Mike R (US SSA)"
 
Default two new questions (sort of)

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!


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



--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 01-09-2008, 05:15 PM
Stephen Smalley
 
Default 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?

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@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@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@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@redhat.com
> > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>
>
--
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 01-09-2008, 06:09 PM
"Clarkson, Mike R (US SSA)"
 
Default two new questions (sort of)

> -----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@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@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@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@redhat.com
> > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >
> >
> --
> Stephen Smalley
> National Security Agency



--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 01-09-2008, 06:34 PM
Stephen Smalley
 
Default two new questions (sort of)

On Wed, 2008-01-09 at 11:09 -0800, Clarkson, Mike R (US SSA) wrote:
>
> > -----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@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.

There should have already been a selinux-policy-mls binary rpm available
that you could have used. If you rebuilt from source, you may have used
a different modules.conf or build.conf settings, unless you just rebuild
their src rpm as is via rpmbuild.

> >
> > 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.

Interfaces are just m4 macros at present, so they get expanded into your
module, not in the base. So any dontaudits they included would show up
in your module after processing by m4.

> 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.

When you do a 'make -f /usr/share/selinux/devel/Makefile', it creates a
tmp/ directory, processes your .te file, creating a postprocessed
tmp/<name>.tmp file. That's the real module content. Then that gets
fed into checkmodule and that gets fed into semodule_package. So, for
example, you might do the following to strip dontaudits from your
module:
cd tmp/
grep -v dontaudit setcontext.tmp > foo
mv foo setcontext.tmp
checkmodule -m -M -o setcontext.mod setcontext.tmp
semodule_package -o setcontext.pp -m setcontext.mod -f setcontext.fc
semodule -i setcontext.pp

> I'm not sure what you mean by "build a modern selinux userland ...".

Grab the sources of the current selinux userland (ones that support
semodule -DB) and compile them?

--
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 

Thread Tools




All times are GMT. The time now is 07:59 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org