[users] Nagios 3.2.3 SELinux

[Scott Reese]

Greetings:

I've been looking at the SELinux policy as it relates to Nagios. It's been a learning experience, and I now fully understand why people just turn SELinux off. What a hassle. In any event, I've isolated the issues, and I'm looking for advice from those of you who package software around here on which way of solving the problem is best.

RedHat is shipping a Nagios SELinux policy module as part of their base selinux-policy package. It has a few problems, some major, some minor. The major one, which causes Nagios to not be able to start if SELinux is set to Enforcing is that the policy expects certain Nagios files to be in one place, but they are somewhere else. The problem is in the /var directory structures. RedHat expects Nagios to put its files into the existing /var structures. PID files go in /var/run, spool files (which Nagios is using to get results back from the plugins) in /var/spool/nagios, etc. The way that Nagios is packaged, however, is different. It creates a /var/nagios directory structure, and puts all of its files in there. Since the files aren't where the SELinux policy expects them to be, it generates denials and Nagios doesn't work.

So, the options boil down to change the Nagios packages to fit the shipping RedHat SELinux policy, or modify the SELinux policy to match the shipping Nagios package. My question is, which do you think is the best way to go?

Yury had previously asked if the SELinux policy could be packaged and shipped with the Nagios RPMs. The infrastructure to do that is built into the RPM packaging system, so it would be a possibility. What I haven't figured out is how that would interact with the policy module that RedHat is shipping as part of the base package. I don't know if RedHat would have to remove that module from the package, or if just shipping a module with a higher version number would replace the RedHat module with the Nagios module.

Thanks for any insight you have.

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20110105/8f269429/attachment.html

[Frank Bures]

Post by Scott Reese
I've been looking at the SELinux policy as it relates to Nagios. It's
been a learning experience, and I now fully understand why people just
turn SELinux off. What a hassle. In any event, I've isolated the
issues, and I'm looking for advice from those of you who package
software around here on which way of solving the problem is best.
RedHat is shipping a Nagios SELinux policy module as part of their base
selinux-policy package. It has a few problems, some major, some minor.
The major one, which causes Nagios to not be able to start if SELinux is
set to Enforcing is that the policy expects certain Nagios files to be
in one place, but they are somewhere else. The problem is in the /var
directory structures. RedHat expects Nagios to put its files into the
existing /var structures. PID files go in /var/run, spool files (which
Nagios is using to get results back from the plugins) in
/var/spool/nagios, etc. The way that Nagios is packaged, however, is
different. It creates a /var/nagios directory structure, and puts all
of its files in there. Since the files aren't where the SELinux policy
expects them to be, it generates denials and Nagios doesn't work.
So, the options boil down to change the Nagios packages to fit the
shipping RedHat SELinux policy, or modify the SELinux policy to match
the shipping Nagios package. My question is, which do you think is the
best way to go?
Yury had previously asked if the SELinux policy could be packaged and
shipped with the Nagios RPMs. The infrastructure to do that is built
into the RPM packaging system, so it would be a possibility. What I
haven't figured out is how that would interact with the policy module
that RedHat is shipping as part of the base package. I don't know if
RedHat would have to remove that module from the package, or if just
shipping a module with a higher version number would replace the RedHat
module with the Nagios module.

One can leave the Nagios structure intact and just create a local SELinux
policy related to it. Local policies are not wiped-out during SELinux
policy updates and as you stated, rpm provides tools for such purposes.

Cheers
Frank

[Eirikur Hjartarson]

Hi,

EPEL6 (beta) ships nagios-3.2.3, I would assume that the SELinux nagios
policy was set up for that build.

Regards,

Post by Scott Reese
I've been looking at the SELinux policy as it relates to Nagios. It's
been a learning experience, and I now fully understand why people just
turn SELinux off. What a hassle. In any event, I've isolated the
issues, and I'm looking for advice from those of you who package
software around here on which way of solving the problem is best.
RedHat is shipping a Nagios SELinux policy module as part of their
base selinux-policy package. It has a few problems, some major, some
minor. The major one, which causes Nagios to not be able to start if
SELinux is set to Enforcing is that the policy expects certain Nagios
files to be in one place, but they are somewhere else. The problem is
in the /var directory structures. RedHat expects Nagios to put its
files into the existing /var structures. PID files go in /var/run,
spool files (which Nagios is using to get results back from the
plugins) in /var/spool/nagios, etc. The way that Nagios is packaged,
however, is different. It creates a /var/nagios directory structure,
and puts all of its files in there. Since the files aren't where the
SELinux policy expects them to be, it generates denials and Nagios
doesn't work.
So, the options boil down to change the Nagios packages to fit the
shipping RedHat SELinux policy, or modify the SELinux policy to match
the shipping Nagios package. My question is, which do you think is
the best way to go?
Yury had previously asked if the SELinux policy could be packaged and
shipped with the Nagios RPMs. The infrastructure to do that is built
into the RPM packaging system, so it would be a possibility. What I
haven't figured out is how that would interact with the policy module
that RedHat is shipping as part of the base package. I don't know if
RedHat would have to remove that module from the package, or if just
shipping a module with a higher version number would replace the
RedHat module with the Nagios module.
Thanks for any insight you have.
-Scott
_______________________________________________
users mailing list
users at lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/users

[Yury V. Zaytsev]

Post by Eirikur Hjartarson
Hi,
EPEL6 (beta) ships nagios-3.2.3, I would assume that the SELinux nagios
policy was set up for that build.

Maybe we should adjust our package to match EPEL then? Christoph?

[Christoph Maser]

Post by Yury V. Zaytsev

Post by Eirikur Hjartarson
Hi,
EPEL6 (beta) ships nagios-3.2.3, I would assume that the SELinux nagios
policy was set up for that build.

Maybe we should adjust our package to match EPEL then? Christoph?

Either that or ship our own selinux nagios module (version > 1.1.0) to
replace the one shipped in selinux-policy-targeted.noarch. The sources
for the module can be extracted from the selinux-policy source rpm.

In those policies i don't find any reference to /var/spool. The files
are from 2006 and I think they are for nagios 2.6, somehow I doubt the
EPEL package wil work with the nagios semodule shipped in base..

Another pint where is the fedora/epel source for nagios? I can't find it
on http://git.fedorahosted.org/

Chris

[Christoph Maser]

Post by Yury V. Zaytsev

Post by Eirikur Hjartarson
Hi,
EPEL6 (beta) ships nagios-3.2.3, I would assume that the SELinux nagios
policy was set up for that build.

Maybe we should adjust our package to match EPEL then? Christoph?

Either that or ship our own selinux nagios module (version > 1.1.0) to
replace the one shipped in selinux-policy-targeted.noarch. The sources
for the module can be extracted from the selinux-policy source rpm.

In those policies i don't find any reference to /var/spool. The files
are from 2006 and I think they are for nagios 2.6, somehow I doubt the
EPEL package wil work with the nagios semodule shipped in base..

Another pint where is the fedora/epel source for nagios? I can't find it
on http://git.fedorahosted.org/

Chris

[Christoph Maser]

Post by Yury V. Zaytsev

Post by Eirikur Hjartarson
Hi,
EPEL6 (beta) ships nagios-3.2.3, I would assume that the SELinux nagios
policy was set up for that build.

Maybe we should adjust our package to match EPEL then? Christoph?

Either that or ship our own selinux nagios module (version > 1.1.0) to
replace the one shipped in selinux-policy-targeted.noarch. The sources
for the module can be extracted from the selinux-policy source rpm.

In those policies i don't find any reference to /var/spool. The files
are from 2006 and I think they are for nagios 2.6, somehow I doubt the
EPEL package wil work with the nagios semodule shipped in base..

Another pint where is the fedora/epel source for nagios? I can't find it
on http://git.fedorahosted.org/

Chris

[Christoph Maser]

Post by Yury V. Zaytsev

Post by Eirikur Hjartarson
Hi,
EPEL6 (beta) ships nagios-3.2.3, I would assume that the SELinux nagios
policy was set up for that build.

Maybe we should adjust our package to match EPEL then? Christoph?

Either that or ship our own selinux nagios module (version > 1.1.0) to
replace the one shipped in selinux-policy-targeted.noarch. The sources
for the module can be extracted from the selinux-policy source rpm.

In those policies i don't find any reference to /var/spool. The files
are from 2006 and I think they are for nagios 2.6, somehow I doubt the
EPEL package wil work with the nagios semodule shipped in base..

Another pint where is the fedora/epel source for nagios? I can't find it
on http://git.fedorahosted.org/

Chris

[Christoph Maser]

Post by Yury V. Zaytsev

Post by Eirikur Hjartarson
Hi,
EPEL6 (beta) ships nagios-3.2.3, I would assume that the SELinux nagios
policy was set up for that build.

Maybe we should adjust our package to match EPEL then? Christoph?

Either that or ship our own selinux nagios module (version > 1.1.0) to
replace the one shipped in selinux-policy-targeted.noarch. The sources
for the module can be extracted from the selinux-policy source rpm.

In those policies i don't find any reference to /var/spool. The files
are from 2006 and I think they are for nagios 2.6, somehow I doubt the
EPEL package wil work with the nagios semodule shipped in base..

Another pint where is the fedora/epel source for nagios? I can't find it
on http://git.fedorahosted.org/

Chris

[Yury V. Zaytsev]

Post by Eirikur Hjartarson
Hi,
EPEL6 (beta) ships nagios-3.2.3, I would assume that the SELinux nagios
policy was set up for that build.

Maybe we should adjust our package to match EPEL then? Christoph?

[Yury V. Zaytsev]

Post by Eirikur Hjartarson
Hi,
EPEL6 (beta) ships nagios-3.2.3, I would assume that the SELinux nagios
policy was set up for that build.

Maybe we should adjust our package to match EPEL then? Christoph?

[Yury V. Zaytsev]

Post by Eirikur Hjartarson
Hi,
EPEL6 (beta) ships nagios-3.2.3, I would assume that the SELinux nagios
policy was set up for that build.

Maybe we should adjust our package to match EPEL then? Christoph?

[Yury V. Zaytsev]

Post by Eirikur Hjartarson
Hi,
EPEL6 (beta) ships nagios-3.2.3, I would assume that the SELinux nagios
policy was set up for that build.

Maybe we should adjust our package to match EPEL then? Christoph?

[Pavel Kankovsky]

Post by Scott Reese
Since the files aren't where the SELinux policy expects them to be, it
generates denials and Nagios doesn't work.

Denials are caused by incorrect contexts. And contexts are not initialized
correctly because files and directories are not at expected places.

Missing file context rules can be added with "semanage fcontext" and
existing files and directories relabeled with "fixfiles restore".

Anyway, the easiest solution would probably be to change the package
layout to follow FHS, as expected by the standard policy and its file
context rules.

Post by Scott Reese
Yury had previously asked if the SELinux policy could be packaged and
shipped with the Nagios RPMs.

This is probably something that should be avoided because the policy
module needs to be installed separately. RPM does no label new objects
correctly if a new policy is installed together with affected packages
(this happened several times during the lifetime of RHEL 5).

[Christoph Maser]

Post by Pavel Kankovsky

Post by Scott Reese
Since the files aren't where the SELinux policy expects them to be, it
generates denials and Nagios doesn't work.

Denials are caused by incorrect contexts. And contexts are not initialized
correctly because files and directories are not at expected places.
Missing file context rules can be added with "semanage fcontext" and
existing files and directories relabeled with "fixfiles restore".
Anyway, the easiest solution would probably be to change the package
layout to follow FHS, as expected by the standard policy and its file
context rules.

Yes there are some improvements to be done but the policy shipped in
rehel 5 certainly is also incomplete. Its missing /var/run/nagios.*
and /var/spool/nagios(/.*)? in the file context. Wich means that a)
nagios has to be started as root to create the pid file. Yes I know
nagio drops privileges, but it reads the config before dropping privs on
startup. If the permissions are wrong on the configs a runtime config
reload can cause failures
b) checkresultdir has to be under /var/log but it should be
under /var/spool.

So, what do we do? And btw. newer releases of selinux-policies have that
fixed (e.g. in fedora 14). That means another bunch of conditionals in
the spec :(

Post by Pavel Kankovsky

Post by Scott Reese
Yury had previously asked if the SELinux policy could be packaged and
shipped with the Nagios RPMs.

This is probably something that should be avoided because the policy
module needs to be installed separately. RPM does no label new objects
correctly if a new policy is installed together with affected packages
(this happened several times during the lifetime of RHEL 5).

Interesting, I am just working on integrating selinux policies ind
icinga packages, I will have an eye on that. If what you say is true
this should be considered a bug in RPM, after all there is a %policy
section....

[Christoph Maser]

Post by Christoph Maser

Post by Pavel Kankovsky

Post by Scott Reese
Since the files aren't where the SELinux policy expects them to be, it
generates denials and Nagios doesn't work.

Denials are caused by incorrect contexts. And contexts are not initialized
correctly because files and directories are not at expected places.
Missing file context rules can be added with "semanage fcontext" and
existing files and directories relabeled with "fixfiles restore".
Anyway, the easiest solution would probably be to change the package
layout to follow FHS, as expected by the standard policy and its file
context rules.

Yes there are some improvements to be done but the policy shipped in
rehel 5 certainly is also incomplete. Its missing /var/run/nagios.*
and /var/spool/nagios(/.*)? in the file context. Wich means that a)
nagios has to be started as root to create the pid file. Yes I know
nagio drops privileges, but it reads the config before dropping privs on
startup. If the permissions are wrong on the configs a runtime config
reload can cause failures
b) checkresultdir has to be under /var/log but it should be
under /var/spool.
So, what do we do? And btw. newer releases of selinux-policies have that
fixed (e.g. in fedora 14). That means another bunch of conditionals in
the spec :(

I have to correct myself, actually /var/spool/nagios is in the policy. I
did only look at the source files of selinux-policy but there is also a
huge patch in that package wich includes a lot of nagios policy changes.
But I did identify a few problems with the nagios policy module as
shipped in C5:

- init script: it is possible to start nagios as root or nagios user on
the command line but not using the init script. the init script is
context initrc_exec_t and that context is not allowed

- pid file: actually nagios drops its privs before writing the pid file,
so the init script can not be in /var/run. workaround: put the pid file
under /var/log/nagios

- command file: by default nagios installs the command file in
$LOGDIR/rw wich would be /var/log/nagios/rw but fifo access for
httpd_nagios_script_t is only allowed for /var/spool/nagios. Setting
$LOGDIR to /var/spool/nagios is not a solution since that breaks a lot
of other policies. workaround: patch Makefiles so the command file
location can be set seperatley

I will try to fix the last 2 ones, but I have no idea how to deal with
the init script. Does anyone have an idea how to deal with it?

Chris

[Christoph Maser]

Post by Christoph Maser
I have to correct myself, actually /var/spool/nagios is in the policy. I
did only look at the source files of selinux-policy but there is also a
huge patch in that package wich includes a lot of nagios policy changes.
But I did identify a few problems with the nagios policy module as
- init script: it is possible to start nagios as root or nagios user on
the command line but not using the init script. the init script is
context initrc_exec_t and that context is not allowed
- pid file: actually nagios drops its privs before writing the pid file,
so the init script can not be in /var/run. workaround: put the pid file
under /var/log/nagios
- command file: by default nagios installs the command file in
$LOGDIR/rw wich would be /var/log/nagios/rw but fifo access for
httpd_nagios_script_t is only allowed for /var/spool/nagios. Setting
$LOGDIR to /var/spool/nagios is not a solution since that breaks a lot
of other policies. workaround: patch Makefiles so the command file
location can be set seperatley
I will try to fix the last 2 ones, but I have no idea how to deal with
the init script. Does anyone have an idea how to deal with it?
Chris

So i did make those changes and committed an update. A fresh install of
the package on CentOS 5 now works with selinux enabled, only the init
script does not work unless one changes the file context of the init
script to something else than initrc_exec_t.

Chris

[Christoph Maser]

Post by Christoph Maser
I have to correct myself, actually /var/spool/nagios is in the policy. I
did only look at the source files of selinux-policy but there is also a
huge patch in that package wich includes a lot of nagios policy changes.
But I did identify a few problems with the nagios policy module as
- init script: it is possible to start nagios as root or nagios user on
the command line but not using the init script. the init script is
context initrc_exec_t and that context is not allowed
- pid file: actually nagios drops its privs before writing the pid file,
so the init script can not be in /var/run. workaround: put the pid file
under /var/log/nagios
- command file: by default nagios installs the command file in
$LOGDIR/rw wich would be /var/log/nagios/rw but fifo access for
httpd_nagios_script_t is only allowed for /var/spool/nagios. Setting
$LOGDIR to /var/spool/nagios is not a solution since that breaks a lot
of other policies. workaround: patch Makefiles so the command file
location can be set seperatley
I will try to fix the last 2 ones, but I have no idea how to deal with
the init script. Does anyone have an idea how to deal with it?
Chris

So i did make those changes and committed an update. A fresh install of
the package on CentOS 5 now works with selinux enabled, only the init
script does not work unless one changes the file context of the init
script to something else than initrc_exec_t.

Chris

[Christoph Maser]

Post by Christoph Maser
I have to correct myself, actually /var/spool/nagios is in the policy. I
did only look at the source files of selinux-policy but there is also a
huge patch in that package wich includes a lot of nagios policy changes.
But I did identify a few problems with the nagios policy module as
- init script: it is possible to start nagios as root or nagios user on
the command line but not using the init script. the init script is
context initrc_exec_t and that context is not allowed
- pid file: actually nagios drops its privs before writing the pid file,
so the init script can not be in /var/run. workaround: put the pid file
under /var/log/nagios
- command file: by default nagios installs the command file in
$LOGDIR/rw wich would be /var/log/nagios/rw but fifo access for
httpd_nagios_script_t is only allowed for /var/spool/nagios. Setting
$LOGDIR to /var/spool/nagios is not a solution since that breaks a lot
of other policies. workaround: patch Makefiles so the command file
location can be set seperatley
I will try to fix the last 2 ones, but I have no idea how to deal with
the init script. Does anyone have an idea how to deal with it?
Chris

So i did make those changes and committed an update. A fresh install of
the package on CentOS 5 now works with selinux enabled, only the init
script does not work unless one changes the file context of the init
script to something else than initrc_exec_t.

Chris

[Christoph Maser]

Post by Christoph Maser
I have to correct myself, actually /var/spool/nagios is in the policy. I
did only look at the source files of selinux-policy but there is also a
huge patch in that package wich includes a lot of nagios policy changes.
But I did identify a few problems with the nagios policy module as
- init script: it is possible to start nagios as root or nagios user on
the command line but not using the init script. the init script is
context initrc_exec_t and that context is not allowed
- pid file: actually nagios drops its privs before writing the pid file,
so the init script can not be in /var/run. workaround: put the pid file
under /var/log/nagios
- command file: by default nagios installs the command file in
$LOGDIR/rw wich would be /var/log/nagios/rw but fifo access for
httpd_nagios_script_t is only allowed for /var/spool/nagios. Setting
$LOGDIR to /var/spool/nagios is not a solution since that breaks a lot
of other policies. workaround: patch Makefiles so the command file
location can be set seperatley
I will try to fix the last 2 ones, but I have no idea how to deal with
the init script. Does anyone have an idea how to deal with it?
Chris

So i did make those changes and committed an update. A fresh install of
the package on CentOS 5 now works with selinux enabled, only the init
script does not work unless one changes the file context of the init
script to something else than initrc_exec_t.

Chris

[Christoph Maser]

Post by Christoph Maser
I have to correct myself, actually /var/spool/nagios is in the policy. I
did only look at the source files of selinux-policy but there is also a
huge patch in that package wich includes a lot of nagios policy changes.
But I did identify a few problems with the nagios policy module as
- init script: it is possible to start nagios as root or nagios user on
the command line but not using the init script. the init script is
context initrc_exec_t and that context is not allowed
- pid file: actually nagios drops its privs before writing the pid file,
so the init script can not be in /var/run. workaround: put the pid file
under /var/log/nagios
- command file: by default nagios installs the command file in
$LOGDIR/rw wich would be /var/log/nagios/rw but fifo access for
httpd_nagios_script_t is only allowed for /var/spool/nagios. Setting
$LOGDIR to /var/spool/nagios is not a solution since that breaks a lot
of other policies. workaround: patch Makefiles so the command file
location can be set seperatley
I will try to fix the last 2 ones, but I have no idea how to deal with
the init script. Does anyone have an idea how to deal with it?
Chris

So i did make those changes and committed an update. A fresh install of
the package on CentOS 5 now works with selinux enabled, only the init
script does not work unless one changes the file context of the init
script to something else than initrc_exec_t.

Chris

[Christoph Maser]

Post by Christoph Maser

Post by Pavel Kankovsky

Post by Scott Reese
Since the files aren't where the SELinux policy expects them to be, it
generates denials and Nagios doesn't work.

Denials are caused by incorrect contexts. And contexts are not initialized
correctly because files and directories are not at expected places.
Missing file context rules can be added with "semanage fcontext" and
existing files and directories relabeled with "fixfiles restore".
Anyway, the easiest solution would probably be to change the package
layout to follow FHS, as expected by the standard policy and its file
context rules.

Yes there are some improvements to be done but the policy shipped in
rehel 5 certainly is also incomplete. Its missing /var/run/nagios.*
and /var/spool/nagios(/.*)? in the file context. Wich means that a)
nagios has to be started as root to create the pid file. Yes I know
nagio drops privileges, but it reads the config before dropping privs on
startup. If the permissions are wrong on the configs a runtime config
reload can cause failures
b) checkresultdir has to be under /var/log but it should be
under /var/spool.
So, what do we do? And btw. newer releases of selinux-policies have that
fixed (e.g. in fedora 14). That means another bunch of conditionals in
the spec :(

I have to correct myself, actually /var/spool/nagios is in the policy. I
did only look at the source files of selinux-policy but there is also a
huge patch in that package wich includes a lot of nagios policy changes.
But I did identify a few problems with the nagios policy module as
shipped in C5:

- init script: it is possible to start nagios as root or nagios user on
the command line but not using the init script. the init script is
context initrc_exec_t and that context is not allowed

- pid file: actually nagios drops its privs before writing the pid file,
so the init script can not be in /var/run. workaround: put the pid file
under /var/log/nagios

- command file: by default nagios installs the command file in
$LOGDIR/rw wich would be /var/log/nagios/rw but fifo access for
httpd_nagios_script_t is only allowed for /var/spool/nagios. Setting
$LOGDIR to /var/spool/nagios is not a solution since that breaks a lot
of other policies. workaround: patch Makefiles so the command file
location can be set seperatley

I will try to fix the last 2 ones, but I have no idea how to deal with
the init script. Does anyone have an idea how to deal with it?

Chris

[Christoph Maser]

Post by Christoph Maser

Post by Pavel Kankovsky

Post by Scott Reese
Since the files aren't where the SELinux policy expects them to be, it
generates denials and Nagios doesn't work.

Denials are caused by incorrect contexts. And contexts are not initialized
correctly because files and directories are not at expected places.
Missing file context rules can be added with "semanage fcontext" and
existing files and directories relabeled with "fixfiles restore".
Anyway, the easiest solution would probably be to change the package
layout to follow FHS, as expected by the standard policy and its file
context rules.

Yes there are some improvements to be done but the policy shipped in
rehel 5 certainly is also incomplete. Its missing /var/run/nagios.*
and /var/spool/nagios(/.*)? in the file context. Wich means that a)
nagios has to be started as root to create the pid file. Yes I know
nagio drops privileges, but it reads the config before dropping privs on
startup. If the permissions are wrong on the configs a runtime config
reload can cause failures
b) checkresultdir has to be under /var/log but it should be
under /var/spool.
So, what do we do? And btw. newer releases of selinux-policies have that
fixed (e.g. in fedora 14). That means another bunch of conditionals in
the spec :(

I have to correct myself, actually /var/spool/nagios is in the policy. I
did only look at the source files of selinux-policy but there is also a
huge patch in that package wich includes a lot of nagios policy changes.
But I did identify a few problems with the nagios policy module as
shipped in C5:

- init script: it is possible to start nagios as root or nagios user on
the command line but not using the init script. the init script is
context initrc_exec_t and that context is not allowed

- pid file: actually nagios drops its privs before writing the pid file,
so the init script can not be in /var/run. workaround: put the pid file
under /var/log/nagios

- command file: by default nagios installs the command file in
$LOGDIR/rw wich would be /var/log/nagios/rw but fifo access for
httpd_nagios_script_t is only allowed for /var/spool/nagios. Setting
$LOGDIR to /var/spool/nagios is not a solution since that breaks a lot
of other policies. workaround: patch Makefiles so the command file
location can be set seperatley

I will try to fix the last 2 ones, but I have no idea how to deal with
the init script. Does anyone have an idea how to deal with it?

Chris

[Christoph Maser]

Post by Christoph Maser

Post by Pavel Kankovsky

Post by Scott Reese
Since the files aren't where the SELinux policy expects them to be, it
generates denials and Nagios doesn't work.

Denials are caused by incorrect contexts. And contexts are not initialized
correctly because files and directories are not at expected places.
Missing file context rules can be added with "semanage fcontext" and
existing files and directories relabeled with "fixfiles restore".
Anyway, the easiest solution would probably be to change the package
layout to follow FHS, as expected by the standard policy and its file
context rules.

Yes there are some improvements to be done but the policy shipped in
rehel 5 certainly is also incomplete. Its missing /var/run/nagios.*
and /var/spool/nagios(/.*)? in the file context. Wich means that a)
nagios has to be started as root to create the pid file. Yes I know
nagio drops privileges, but it reads the config before dropping privs on
startup. If the permissions are wrong on the configs a runtime config
reload can cause failures
b) checkresultdir has to be under /var/log but it should be
under /var/spool.
So, what do we do? And btw. newer releases of selinux-policies have that
fixed (e.g. in fedora 14). That means another bunch of conditionals in
the spec :(

I have to correct myself, actually /var/spool/nagios is in the policy. I
did only look at the source files of selinux-policy but there is also a
huge patch in that package wich includes a lot of nagios policy changes.
But I did identify a few problems with the nagios policy module as
shipped in C5:

- init script: it is possible to start nagios as root or nagios user on
the command line but not using the init script. the init script is
context initrc_exec_t and that context is not allowed

- pid file: actually nagios drops its privs before writing the pid file,
so the init script can not be in /var/run. workaround: put the pid file
under /var/log/nagios

- command file: by default nagios installs the command file in
$LOGDIR/rw wich would be /var/log/nagios/rw but fifo access for
httpd_nagios_script_t is only allowed for /var/spool/nagios. Setting
$LOGDIR to /var/spool/nagios is not a solution since that breaks a lot
of other policies. workaround: patch Makefiles so the command file
location can be set seperatley

I will try to fix the last 2 ones, but I have no idea how to deal with
the init script. Does anyone have an idea how to deal with it?

Chris

[Christoph Maser]

Post by Christoph Maser

Post by Pavel Kankovsky

Post by Scott Reese
Since the files aren't where the SELinux policy expects them to be, it
generates denials and Nagios doesn't work.

Denials are caused by incorrect contexts. And contexts are not initialized
correctly because files and directories are not at expected places.
Missing file context rules can be added with "semanage fcontext" and
existing files and directories relabeled with "fixfiles restore".
Anyway, the easiest solution would probably be to change the package
layout to follow FHS, as expected by the standard policy and its file
context rules.

Yes there are some improvements to be done but the policy shipped in
rehel 5 certainly is also incomplete. Its missing /var/run/nagios.*
and /var/spool/nagios(/.*)? in the file context. Wich means that a)
nagios has to be started as root to create the pid file. Yes I know
nagio drops privileges, but it reads the config before dropping privs on
startup. If the permissions are wrong on the configs a runtime config
reload can cause failures
b) checkresultdir has to be under /var/log but it should be
under /var/spool.
So, what do we do? And btw. newer releases of selinux-policies have that
fixed (e.g. in fedora 14). That means another bunch of conditionals in
the spec :(

I have to correct myself, actually /var/spool/nagios is in the policy. I
did only look at the source files of selinux-policy but there is also a
huge patch in that package wich includes a lot of nagios policy changes.
But I did identify a few problems with the nagios policy module as
shipped in C5:

- init script: it is possible to start nagios as root or nagios user on
the command line but not using the init script. the init script is
context initrc_exec_t and that context is not allowed

- pid file: actually nagios drops its privs before writing the pid file,
so the init script can not be in /var/run. workaround: put the pid file
under /var/log/nagios

- command file: by default nagios installs the command file in
$LOGDIR/rw wich would be /var/log/nagios/rw but fifo access for
httpd_nagios_script_t is only allowed for /var/spool/nagios. Setting
$LOGDIR to /var/spool/nagios is not a solution since that breaks a lot
of other policies. workaround: patch Makefiles so the command file
location can be set seperatley

I will try to fix the last 2 ones, but I have no idea how to deal with
the init script. Does anyone have an idea how to deal with it?

Chris

[Christoph Maser]

Post by Pavel Kankovsky

Post by Scott Reese
Since the files aren't where the SELinux policy expects them to be, it
generates denials and Nagios doesn't work.

Denials are caused by incorrect contexts. And contexts are not initialized
correctly because files and directories are not at expected places.
Missing file context rules can be added with "semanage fcontext" and
existing files and directories relabeled with "fixfiles restore".
Anyway, the easiest solution would probably be to change the package
layout to follow FHS, as expected by the standard policy and its file
context rules.

Yes there are some improvements to be done but the policy shipped in
rehel 5 certainly is also incomplete. Its missing /var/run/nagios.*
and /var/spool/nagios(/.*)? in the file context. Wich means that a)
nagios has to be started as root to create the pid file. Yes I know
nagio drops privileges, but it reads the config before dropping privs on
startup. If the permissions are wrong on the configs a runtime config
reload can cause failures
b) checkresultdir has to be under /var/log but it should be
under /var/spool.

So, what do we do? And btw. newer releases of selinux-policies have that
fixed (e.g. in fedora 14). That means another bunch of conditionals in
the spec :(

Post by Pavel Kankovsky

Post by Scott Reese
Yury had previously asked if the SELinux policy could be packaged and
shipped with the Nagios RPMs.

This is probably something that should be avoided because the policy
module needs to be installed separately. RPM does no label new objects
correctly if a new policy is installed together with affected packages
(this happened several times during the lifetime of RHEL 5).

Interesting, I am just working on integrating selinux policies ind
icinga packages, I will have an eye on that. If what you say is true
this should be considered a bug in RPM, after all there is a %policy
section....

[Christoph Maser]

Post by Pavel Kankovsky

Post by Scott Reese
Since the files aren't where the SELinux policy expects them to be, it
generates denials and Nagios doesn't work.

Denials are caused by incorrect contexts. And contexts are not initialized
correctly because files and directories are not at expected places.
Missing file context rules can be added with "semanage fcontext" and
existing files and directories relabeled with "fixfiles restore".
Anyway, the easiest solution would probably be to change the package
layout to follow FHS, as expected by the standard policy and its file
context rules.

Yes there are some improvements to be done but the policy shipped in
rehel 5 certainly is also incomplete. Its missing /var/run/nagios.*
and /var/spool/nagios(/.*)? in the file context. Wich means that a)
nagios has to be started as root to create the pid file. Yes I know
nagio drops privileges, but it reads the config before dropping privs on
startup. If the permissions are wrong on the configs a runtime config
reload can cause failures
b) checkresultdir has to be under /var/log but it should be
under /var/spool.

So, what do we do? And btw. newer releases of selinux-policies have that
fixed (e.g. in fedora 14). That means another bunch of conditionals in
the spec :(

Post by Pavel Kankovsky

Post by Scott Reese
Yury had previously asked if the SELinux policy could be packaged and
shipped with the Nagios RPMs.

This is probably something that should be avoided because the policy
module needs to be installed separately. RPM does no label new objects
correctly if a new policy is installed together with affected packages
(this happened several times during the lifetime of RHEL 5).

Interesting, I am just working on integrating selinux policies ind
icinga packages, I will have an eye on that. If what you say is true
this should be considered a bug in RPM, after all there is a %policy
section....

[Christoph Maser]

Post by Pavel Kankovsky

Post by Scott Reese
Since the files aren't where the SELinux policy expects them to be, it
generates denials and Nagios doesn't work.

Denials are caused by incorrect contexts. And contexts are not initialized
correctly because files and directories are not at expected places.
Missing file context rules can be added with "semanage fcontext" and
existing files and directories relabeled with "fixfiles restore".
Anyway, the easiest solution would probably be to change the package
layout to follow FHS, as expected by the standard policy and its file
context rules.

Yes there are some improvements to be done but the policy shipped in
rehel 5 certainly is also incomplete. Its missing /var/run/nagios.*
and /var/spool/nagios(/.*)? in the file context. Wich means that a)
nagios has to be started as root to create the pid file. Yes I know
nagio drops privileges, but it reads the config before dropping privs on
startup. If the permissions are wrong on the configs a runtime config
reload can cause failures
b) checkresultdir has to be under /var/log but it should be
under /var/spool.

So, what do we do? And btw. newer releases of selinux-policies have that
fixed (e.g. in fedora 14). That means another bunch of conditionals in
the spec :(

Post by Pavel Kankovsky

Post by Scott Reese
Yury had previously asked if the SELinux policy could be packaged and
shipped with the Nagios RPMs.

This is probably something that should be avoided because the policy
module needs to be installed separately. RPM does no label new objects
correctly if a new policy is installed together with affected packages
(this happened several times during the lifetime of RHEL 5).

Interesting, I am just working on integrating selinux policies ind
icinga packages, I will have an eye on that. If what you say is true
this should be considered a bug in RPM, after all there is a %policy
section....

[Christoph Maser]

Post by Pavel Kankovsky

Post by Scott Reese
Since the files aren't where the SELinux policy expects them to be, it
generates denials and Nagios doesn't work.

Denials are caused by incorrect contexts. And contexts are not initialized
correctly because files and directories are not at expected places.
Missing file context rules can be added with "semanage fcontext" and
existing files and directories relabeled with "fixfiles restore".
Anyway, the easiest solution would probably be to change the package
layout to follow FHS, as expected by the standard policy and its file
context rules.

Yes there are some improvements to be done but the policy shipped in
rehel 5 certainly is also incomplete. Its missing /var/run/nagios.*
and /var/spool/nagios(/.*)? in the file context. Wich means that a)
nagios has to be started as root to create the pid file. Yes I know
nagio drops privileges, but it reads the config before dropping privs on
startup. If the permissions are wrong on the configs a runtime config
reload can cause failures
b) checkresultdir has to be under /var/log but it should be
under /var/spool.

So, what do we do? And btw. newer releases of selinux-policies have that
fixed (e.g. in fedora 14). That means another bunch of conditionals in
the spec :(

Post by Pavel Kankovsky

Post by Scott Reese
Yury had previously asked if the SELinux policy could be packaged and
shipped with the Nagios RPMs.

This is probably something that should be avoided because the policy
module needs to be installed separately. RPM does no label new objects
correctly if a new policy is installed together with affected packages
(this happened several times during the lifetime of RHEL 5).

Interesting, I am just working on integrating selinux policies ind
icinga packages, I will have an eye on that. If what you say is true
this should be considered a bug in RPM, after all there is a %policy
section....

[Scott Reese]

Greetings:

I've been looking at the SELinux policy as it relates to Nagios. It's been a learning experience, and I now fully understand why people just turn SELinux off. What a hassle. In any event, I've isolated the issues, and I'm looking for advice from those of you who package software around here on which way of solving the problem is best.

RedHat is shipping a Nagios SELinux policy module as part of their base selinux-policy package. It has a few problems, some major, some minor. The major one, which causes Nagios to not be able to start if SELinux is set to Enforcing is that the policy expects certain Nagios files to be in one place, but they are somewhere else. The problem is in the /var directory structures. RedHat expects Nagios to put its files into the existing /var structures. PID files go in /var/run, spool files (which Nagios is using to get results back from the plugins) in /var/spool/nagios, etc. The way that Nagios is packaged, however, is different. It creates a /var/nagios directory structure, and puts all of its files in there. Since the files aren't where the SELinux policy expects them to be, it generates denials and Nagios doesn't work.

So, the options boil down to change the Nagios packages to fit the shipping RedHat SELinux policy, or modify the SELinux policy to match the shipping Nagios package. My question is, which do you think is the best way to go?

Yury had previously asked if the SELinux policy could be packaged and shipped with the Nagios RPMs. The infrastructure to do that is built into the RPM packaging system, so it would be a possibility. What I haven't figured out is how that would interact with the policy module that RedHat is shipping as part of the base package. I don't know if RedHat would have to remove that module from the package, or if just shipping a module with a higher version number would replace the RedHat module with the Nagios module.

Thanks for any insight you have.

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20110105/8f269429/attachment-0001.html

[Frank Bures]

Post by Scott Reese
I've been looking at the SELinux policy as it relates to Nagios. It's
been a learning experience, and I now fully understand why people just
turn SELinux off. What a hassle. In any event, I've isolated the
issues, and I'm looking for advice from those of you who package
software around here on which way of solving the problem is best.
RedHat is shipping a Nagios SELinux policy module as part of their base
selinux-policy package. It has a few problems, some major, some minor.
The major one, which causes Nagios to not be able to start if SELinux is
set to Enforcing is that the policy expects certain Nagios files to be
in one place, but they are somewhere else. The problem is in the /var
directory structures. RedHat expects Nagios to put its files into the
existing /var structures. PID files go in /var/run, spool files (which
Nagios is using to get results back from the plugins) in
/var/spool/nagios, etc. The way that Nagios is packaged, however, is
different. It creates a /var/nagios directory structure, and puts all
of its files in there. Since the files aren't where the SELinux policy
expects them to be, it generates denials and Nagios doesn't work.
So, the options boil down to change the Nagios packages to fit the
shipping RedHat SELinux policy, or modify the SELinux policy to match
the shipping Nagios package. My question is, which do you think is the
best way to go?
Yury had previously asked if the SELinux policy could be packaged and
shipped with the Nagios RPMs. The infrastructure to do that is built
into the RPM packaging system, so it would be a possibility. What I
haven't figured out is how that would interact with the policy module
that RedHat is shipping as part of the base package. I don't know if
RedHat would have to remove that module from the package, or if just
shipping a module with a higher version number would replace the RedHat
module with the Nagios module.

One can leave the Nagios structure intact and just create a local SELinux
policy related to it. Local policies are not wiped-out during SELinux
policy updates and as you stated, rpm provides tools for such purposes.

Cheers
Frank

[Eirikur Hjartarson]

Hi,

EPEL6 (beta) ships nagios-3.2.3, I would assume that the SELinux nagios
policy was set up for that build.

Regards,

Post by Scott Reese
I've been looking at the SELinux policy as it relates to Nagios. It's
been a learning experience, and I now fully understand why people just
turn SELinux off. What a hassle. In any event, I've isolated the
issues, and I'm looking for advice from those of you who package
software around here on which way of solving the problem is best.
RedHat is shipping a Nagios SELinux policy module as part of their
base selinux-policy package. It has a few problems, some major, some
minor. The major one, which causes Nagios to not be able to start if
SELinux is set to Enforcing is that the policy expects certain Nagios
files to be in one place, but they are somewhere else. The problem is
in the /var directory structures. RedHat expects Nagios to put its
files into the existing /var structures. PID files go in /var/run,
spool files (which Nagios is using to get results back from the
plugins) in /var/spool/nagios, etc. The way that Nagios is packaged,
however, is different. It creates a /var/nagios directory structure,
and puts all of its files in there. Since the files aren't where the
SELinux policy expects them to be, it generates denials and Nagios
doesn't work.
So, the options boil down to change the Nagios packages to fit the
shipping RedHat SELinux policy, or modify the SELinux policy to match
the shipping Nagios package. My question is, which do you think is
the best way to go?
Yury had previously asked if the SELinux policy could be packaged and
shipped with the Nagios RPMs. The infrastructure to do that is built
into the RPM packaging system, so it would be a possibility. What I
haven't figured out is how that would interact with the policy module
that RedHat is shipping as part of the base package. I don't know if
RedHat would have to remove that module from the package, or if just
shipping a module with a higher version number would replace the
RedHat module with the Nagios module.
Thanks for any insight you have.
-Scott
_______________________________________________
users mailing list
users at lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/users

[Pavel Kankovsky]

Post by Scott Reese
Since the files aren't where the SELinux policy expects them to be, it
generates denials and Nagios doesn't work.

Denials are caused by incorrect contexts. And contexts are not initialized
correctly because files and directories are not at expected places.

Missing file context rules can be added with "semanage fcontext" and
existing files and directories relabeled with "fixfiles restore".

Anyway, the easiest solution would probably be to change the package
layout to follow FHS, as expected by the standard policy and its file
context rules.

Post by Scott Reese
Yury had previously asked if the SELinux policy could be packaged and
shipped with the Nagios RPMs.

This is probably something that should be avoided because the policy
module needs to be installed separately. RPM does no label new objects
correctly if a new policy is installed together with affected packages
(this happened several times during the lifetime of RHEL 5).

[Scott Reese]

Greetings:

I've been looking at the SELinux policy as it relates to Nagios. It's been a learning experience, and I now fully understand why people just turn SELinux off. What a hassle. In any event, I've isolated the issues, and I'm looking for advice from those of you who package software around here on which way of solving the problem is best.

RedHat is shipping a Nagios SELinux policy module as part of their base selinux-policy package. It has a few problems, some major, some minor. The major one, which causes Nagios to not be able to start if SELinux is set to Enforcing is that the policy expects certain Nagios files to be in one place, but they are somewhere else. The problem is in the /var directory structures. RedHat expects Nagios to put its files into the existing /var structures. PID files go in /var/run, spool files (which Nagios is using to get results back from the plugins) in /var/spool/nagios, etc. The way that Nagios is packaged, however, is different. It creates a /var/nagios directory structure, and puts all of its files in there. Since the files aren't where the SELinux policy expects them to be, it generates denials and Nagios doesn't work.

So, the options boil down to change the Nagios packages to fit the shipping RedHat SELinux policy, or modify the SELinux policy to match the shipping Nagios package. My question is, which do you think is the best way to go?

Yury had previously asked if the SELinux policy could be packaged and shipped with the Nagios RPMs. The infrastructure to do that is built into the RPM packaging system, so it would be a possibility. What I haven't figured out is how that would interact with the policy module that RedHat is shipping as part of the base package. I don't know if RedHat would have to remove that module from the package, or if just shipping a module with a higher version number would replace the RedHat module with the Nagios module.

Thanks for any insight you have.

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20110105/8f269429/attachment-0002.html

[Frank Bures]

Post by Scott Reese
I've been looking at the SELinux policy as it relates to Nagios. It's
been a learning experience, and I now fully understand why people just
turn SELinux off. What a hassle. In any event, I've isolated the
issues, and I'm looking for advice from those of you who package
software around here on which way of solving the problem is best.
RedHat is shipping a Nagios SELinux policy module as part of their base
selinux-policy package. It has a few problems, some major, some minor.
The major one, which causes Nagios to not be able to start if SELinux is
set to Enforcing is that the policy expects certain Nagios files to be
in one place, but they are somewhere else. The problem is in the /var
directory structures. RedHat expects Nagios to put its files into the
existing /var structures. PID files go in /var/run, spool files (which
Nagios is using to get results back from the plugins) in
/var/spool/nagios, etc. The way that Nagios is packaged, however, is
different. It creates a /var/nagios directory structure, and puts all
of its files in there. Since the files aren't where the SELinux policy
expects them to be, it generates denials and Nagios doesn't work.
So, the options boil down to change the Nagios packages to fit the
shipping RedHat SELinux policy, or modify the SELinux policy to match
the shipping Nagios package. My question is, which do you think is the
best way to go?
Yury had previously asked if the SELinux policy could be packaged and
shipped with the Nagios RPMs. The infrastructure to do that is built
into the RPM packaging system, so it would be a possibility. What I
haven't figured out is how that would interact with the policy module
that RedHat is shipping as part of the base package. I don't know if
RedHat would have to remove that module from the package, or if just
shipping a module with a higher version number would replace the RedHat
module with the Nagios module.

One can leave the Nagios structure intact and just create a local SELinux
policy related to it. Local policies are not wiped-out during SELinux
policy updates and as you stated, rpm provides tools for such purposes.

Cheers
Frank

[Eirikur Hjartarson]

Hi,

EPEL6 (beta) ships nagios-3.2.3, I would assume that the SELinux nagios
policy was set up for that build.

Regards,

Post by Scott Reese
I've been looking at the SELinux policy as it relates to Nagios. It's
been a learning experience, and I now fully understand why people just
turn SELinux off. What a hassle. In any event, I've isolated the
issues, and I'm looking for advice from those of you who package
software around here on which way of solving the problem is best.
RedHat is shipping a Nagios SELinux policy module as part of their
base selinux-policy package. It has a few problems, some major, some
minor. The major one, which causes Nagios to not be able to start if
SELinux is set to Enforcing is that the policy expects certain Nagios
files to be in one place, but they are somewhere else. The problem is
in the /var directory structures. RedHat expects Nagios to put its
files into the existing /var structures. PID files go in /var/run,
spool files (which Nagios is using to get results back from the
plugins) in /var/spool/nagios, etc. The way that Nagios is packaged,
however, is different. It creates a /var/nagios directory structure,
and puts all of its files in there. Since the files aren't where the
SELinux policy expects them to be, it generates denials and Nagios
doesn't work.
So, the options boil down to change the Nagios packages to fit the
shipping RedHat SELinux policy, or modify the SELinux policy to match
the shipping Nagios package. My question is, which do you think is
the best way to go?
Yury had previously asked if the SELinux policy could be packaged and
shipped with the Nagios RPMs. The infrastructure to do that is built
into the RPM packaging system, so it would be a possibility. What I
haven't figured out is how that would interact with the policy module
that RedHat is shipping as part of the base package. I don't know if
RedHat would have to remove that module from the package, or if just
shipping a module with a higher version number would replace the
RedHat module with the Nagios module.
Thanks for any insight you have.
-Scott
_______________________________________________
users mailing list
users at lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/users

[Pavel Kankovsky]

Post by Scott Reese
Since the files aren't where the SELinux policy expects them to be, it
generates denials and Nagios doesn't work.

Denials are caused by incorrect contexts. And contexts are not initialized
correctly because files and directories are not at expected places.

Missing file context rules can be added with "semanage fcontext" and
existing files and directories relabeled with "fixfiles restore".

Anyway, the easiest solution would probably be to change the package
layout to follow FHS, as expected by the standard policy and its file
context rules.

Post by Scott Reese
Yury had previously asked if the SELinux policy could be packaged and
shipped with the Nagios RPMs.

This is probably something that should be avoided because the policy
module needs to be installed separately. RPM does no label new objects
correctly if a new policy is installed together with affected packages
(this happened several times during the lifetime of RHEL 5).

[Scott Reese]

Greetings:

I've been looking at the SELinux policy as it relates to Nagios. It's been a learning experience, and I now fully understand why people just turn SELinux off. What a hassle. In any event, I've isolated the issues, and I'm looking for advice from those of you who package software around here on which way of solving the problem is best.

RedHat is shipping a Nagios SELinux policy module as part of their base selinux-policy package. It has a few problems, some major, some minor. The major one, which causes Nagios to not be able to start if SELinux is set to Enforcing is that the policy expects certain Nagios files to be in one place, but they are somewhere else. The problem is in the /var directory structures. RedHat expects Nagios to put its files into the existing /var structures. PID files go in /var/run, spool files (which Nagios is using to get results back from the plugins) in /var/spool/nagios, etc. The way that Nagios is packaged, however, is different. It creates a /var/nagios directory structure, and puts all of its files in there. Since the files aren't where the SELinux policy expects them to be, it generates denials and Nagios doesn't work.

So, the options boil down to change the Nagios packages to fit the shipping RedHat SELinux policy, or modify the SELinux policy to match the shipping Nagios package. My question is, which do you think is the best way to go?

Yury had previously asked if the SELinux policy could be packaged and shipped with the Nagios RPMs. The infrastructure to do that is built into the RPM packaging system, so it would be a possibility. What I haven't figured out is how that would interact with the policy module that RedHat is shipping as part of the base package. I don't know if RedHat would have to remove that module from the package, or if just shipping a module with a higher version number would replace the RedHat module with the Nagios module.

Thanks for any insight you have.

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20110105/8f269429/attachment-0003.html

[Frank Bures]

Post by Scott Reese
I've been looking at the SELinux policy as it relates to Nagios. It's
been a learning experience, and I now fully understand why people just
turn SELinux off. What a hassle. In any event, I've isolated the
issues, and I'm looking for advice from those of you who package
software around here on which way of solving the problem is best.
RedHat is shipping a Nagios SELinux policy module as part of their base
selinux-policy package. It has a few problems, some major, some minor.
The major one, which causes Nagios to not be able to start if SELinux is
set to Enforcing is that the policy expects certain Nagios files to be
in one place, but they are somewhere else. The problem is in the /var
directory structures. RedHat expects Nagios to put its files into the
existing /var structures. PID files go in /var/run, spool files (which
Nagios is using to get results back from the plugins) in
/var/spool/nagios, etc. The way that Nagios is packaged, however, is
different. It creates a /var/nagios directory structure, and puts all
of its files in there. Since the files aren't where the SELinux policy
expects them to be, it generates denials and Nagios doesn't work.
So, the options boil down to change the Nagios packages to fit the
shipping RedHat SELinux policy, or modify the SELinux policy to match
the shipping Nagios package. My question is, which do you think is the
best way to go?
Yury had previously asked if the SELinux policy could be packaged and
shipped with the Nagios RPMs. The infrastructure to do that is built
into the RPM packaging system, so it would be a possibility. What I
haven't figured out is how that would interact with the policy module
that RedHat is shipping as part of the base package. I don't know if
RedHat would have to remove that module from the package, or if just
shipping a module with a higher version number would replace the RedHat
module with the Nagios module.

One can leave the Nagios structure intact and just create a local SELinux
policy related to it. Local policies are not wiped-out during SELinux
policy updates and as you stated, rpm provides tools for such purposes.

Cheers
Frank

[Eirikur Hjartarson]

Hi,

EPEL6 (beta) ships nagios-3.2.3, I would assume that the SELinux nagios
policy was set up for that build.

Regards,

Post by Scott Reese
I've been looking at the SELinux policy as it relates to Nagios. It's
been a learning experience, and I now fully understand why people just
turn SELinux off. What a hassle. In any event, I've isolated the
issues, and I'm looking for advice from those of you who package
software around here on which way of solving the problem is best.
RedHat is shipping a Nagios SELinux policy module as part of their
base selinux-policy package. It has a few problems, some major, some
minor. The major one, which causes Nagios to not be able to start if
SELinux is set to Enforcing is that the policy expects certain Nagios
files to be in one place, but they are somewhere else. The problem is
in the /var directory structures. RedHat expects Nagios to put its
files into the existing /var structures. PID files go in /var/run,
spool files (which Nagios is using to get results back from the
plugins) in /var/spool/nagios, etc. The way that Nagios is packaged,
however, is different. It creates a /var/nagios directory structure,
and puts all of its files in there. Since the files aren't where the
SELinux policy expects them to be, it generates denials and Nagios
doesn't work.
So, the options boil down to change the Nagios packages to fit the
shipping RedHat SELinux policy, or modify the SELinux policy to match
the shipping Nagios package. My question is, which do you think is
the best way to go?
Yury had previously asked if the SELinux policy could be packaged and
shipped with the Nagios RPMs. The infrastructure to do that is built
into the RPM packaging system, so it would be a possibility. What I
haven't figured out is how that would interact with the policy module
that RedHat is shipping as part of the base package. I don't know if
RedHat would have to remove that module from the package, or if just
shipping a module with a higher version number would replace the
RedHat module with the Nagios module.
Thanks for any insight you have.
-Scott
_______________________________________________
users mailing list
users at lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/users

[Pavel Kankovsky]

Post by Scott Reese
Since the files aren't where the SELinux policy expects them to be, it
generates denials and Nagios doesn't work.

Denials are caused by incorrect contexts. And contexts are not initialized
correctly because files and directories are not at expected places.

Missing file context rules can be added with "semanage fcontext" and
existing files and directories relabeled with "fixfiles restore".

Anyway, the easiest solution would probably be to change the package
layout to follow FHS, as expected by the standard policy and its file
context rules.

Post by Scott Reese
Yury had previously asked if the SELinux policy could be packaged and
shipped with the Nagios RPMs.

This is probably something that should be avoided because the policy
module needs to be installed separately. RPM does no label new objects
correctly if a new policy is installed together with affected packages
(this happened several times during the lifetime of RHEL 5).

[Scott Reese]

Greetings:

I've been looking at the SELinux policy as it relates to Nagios. It's been a learning experience, and I now fully understand why people just turn SELinux off. What a hassle. In any event, I've isolated the issues, and I'm looking for advice from those of you who package software around here on which way of solving the problem is best.

RedHat is shipping a Nagios SELinux policy module as part of their base selinux-policy package. It has a few problems, some major, some minor. The major one, which causes Nagios to not be able to start if SELinux is set to Enforcing is that the policy expects certain Nagios files to be in one place, but they are somewhere else. The problem is in the /var directory structures. RedHat expects Nagios to put its files into the existing /var structures. PID files go in /var/run, spool files (which Nagios is using to get results back from the plugins) in /var/spool/nagios, etc. The way that Nagios is packaged, however, is different. It creates a /var/nagios directory structure, and puts all of its files in there. Since the files aren't where the SELinux policy expects them to be, it generates denials and Nagios doesn't work.

So, the options boil down to change the Nagios packages to fit the shipping RedHat SELinux policy, or modify the SELinux policy to match the shipping Nagios package. My question is, which do you think is the best way to go?

Yury had previously asked if the SELinux policy could be packaged and shipped with the Nagios RPMs. The infrastructure to do that is built into the RPM packaging system, so it would be a possibility. What I haven't figured out is how that would interact with the policy module that RedHat is shipping as part of the base package. I don't know if RedHat would have to remove that module from the package, or if just shipping a module with a higher version number would replace the RedHat module with the Nagios module.

Thanks for any insight you have.

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20110105/8f269429/attachment-0004.html>

[Frank Bures]

Post by Scott Reese
I've been looking at the SELinux policy as it relates to Nagios. It's
been a learning experience, and I now fully understand why people just
turn SELinux off. What a hassle. In any event, I've isolated the
issues, and I'm looking for advice from those of you who package
software around here on which way of solving the problem is best.
RedHat is shipping a Nagios SELinux policy module as part of their base
selinux-policy package. It has a few problems, some major, some minor.
The major one, which causes Nagios to not be able to start if SELinux is
set to Enforcing is that the policy expects certain Nagios files to be
in one place, but they are somewhere else. The problem is in the /var
directory structures. RedHat expects Nagios to put its files into the
existing /var structures. PID files go in /var/run, spool files (which
Nagios is using to get results back from the plugins) in
/var/spool/nagios, etc. The way that Nagios is packaged, however, is
different. It creates a /var/nagios directory structure, and puts all
of its files in there. Since the files aren't where the SELinux policy
expects them to be, it generates denials and Nagios doesn't work.
So, the options boil down to change the Nagios packages to fit the
shipping RedHat SELinux policy, or modify the SELinux policy to match
the shipping Nagios package. My question is, which do you think is the
best way to go?
Yury had previously asked if the SELinux policy could be packaged and
shipped with the Nagios RPMs. The infrastructure to do that is built
into the RPM packaging system, so it would be a possibility. What I
haven't figured out is how that would interact with the policy module
that RedHat is shipping as part of the base package. I don't know if
RedHat would have to remove that module from the package, or if just
shipping a module with a higher version number would replace the RedHat
module with the Nagios module.

One can leave the Nagios structure intact and just create a local SELinux
policy related to it. Local policies are not wiped-out during SELinux
policy updates and as you stated, rpm provides tools for such purposes.

Cheers
Frank

[Eirikur Hjartarson]

Hi,

EPEL6 (beta) ships nagios-3.2.3, I would assume that the SELinux nagios
policy was set up for that build.

Regards,

Post by Scott Reese
I've been looking at the SELinux policy as it relates to Nagios. It's
been a learning experience, and I now fully understand why people just
turn SELinux off. What a hassle. In any event, I've isolated the
issues, and I'm looking for advice from those of you who package
software around here on which way of solving the problem is best.
RedHat is shipping a Nagios SELinux policy module as part of their
base selinux-policy package. It has a few problems, some major, some
minor. The major one, which causes Nagios to not be able to start if
SELinux is set to Enforcing is that the policy expects certain Nagios
files to be in one place, but they are somewhere else. The problem is
in the /var directory structures. RedHat expects Nagios to put its
files into the existing /var structures. PID files go in /var/run,
spool files (which Nagios is using to get results back from the
plugins) in /var/spool/nagios, etc. The way that Nagios is packaged,
however, is different. It creates a /var/nagios directory structure,
and puts all of its files in there. Since the files aren't where the
SELinux policy expects them to be, it generates denials and Nagios
doesn't work.
So, the options boil down to change the Nagios packages to fit the
shipping RedHat SELinux policy, or modify the SELinux policy to match
the shipping Nagios package. My question is, which do you think is
the best way to go?
Yury had previously asked if the SELinux policy could be packaged and
shipped with the Nagios RPMs. The infrastructure to do that is built
into the RPM packaging system, so it would be a possibility. What I
haven't figured out is how that would interact with the policy module
that RedHat is shipping as part of the base package. I don't know if
RedHat would have to remove that module from the package, or if just
shipping a module with a higher version number would replace the
RedHat module with the Nagios module.
Thanks for any insight you have.
-Scott
_______________________________________________
users mailing list
users at lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/users

[Pavel Kankovsky]

Post by Scott Reese
Since the files aren't where the SELinux policy expects them to be, it
generates denials and Nagios doesn't work.

Denials are caused by incorrect contexts. And contexts are not initialized
correctly because files and directories are not at expected places.

Missing file context rules can be added with "semanage fcontext" and
existing files and directories relabeled with "fixfiles restore".

Anyway, the easiest solution would probably be to change the package
layout to follow FHS, as expected by the standard policy and its file
context rules.

Post by Scott Reese
Yury had previously asked if the SELinux policy could be packaged and
shipped with the Nagios RPMs.

This is probably something that should be avoided because the policy
module needs to be installed separately. RPM does no label new objects
correctly if a new policy is installed together with affected packages
(this happened several times during the lifetime of RHEL 5).

[Pavel Kankovsky]

Post by Christoph Maser
- init script: it is possible to start nagios as root or nagios user on
the command line but not using the init script. the init script is
context initrc_exec_t and that context is not allowed

This is strange. What is "not allowed"? As far as I can tell, the
transition from initrc_t (the domain corresponding to initrc_exec_t)
to nagios_t is allowed:

allow initrc_t nagios_exec_t : file {read getattr execute};
allow initrc_t nagios_t : process {transition sigchld noatsecure siginh rlimitinh};
allow nagios_t nagios_exec_t : file {ioctl read getattr lock execute entrypoint};
type_transition initrc_t nagios_exec_t : process nagios_t;

(This assumes nagios_disable_trans is off.)

[Christoph Maser]

Post by Pavel Kankovsky

Post by Christoph Maser
- init script: it is possible to start nagios as root or nagios user on
the command line but not using the init script. the init script is
context initrc_exec_t and that context is not allowed

This is strange. What is "not allowed"? As far as I can tell, the
transition from initrc_t (the domain corresponding to initrc_exec_t)
allow initrc_t nagios_exec_t : file {read getattr execute};
allow initrc_t nagios_t : process {transition sigchld noatsecure siginh rlimitinh};
allow nagios_t nagios_exec_t : file {ioctl read getattr lock execute entrypoint};
type_transition initrc_t nagios_exec_t : process nagios_t;
(This assumes nagios_disable_trans is off.)

Where is that from? I took the c5 SRMP and ran rpmbuild -bp, in my BUILD
dir i dont see those:
/home/cmr/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services: grep
initrc nagios*
-> nothing

CHris

[Christoph Maser]

Post by Pavel Kankovsky

Post by Christoph Maser
- init script: it is possible to start nagios as root or nagios user on
the command line but not using the init script. the init script is
context initrc_exec_t and that context is not allowed

This is strange. What is "not allowed"? As far as I can tell, the
transition from initrc_t (the domain corresponding to initrc_exec_t)
allow initrc_t nagios_exec_t : file {read getattr execute};
allow initrc_t nagios_t : process {transition sigchld noatsecure siginh rlimitinh};
allow nagios_t nagios_exec_t : file {ioctl read getattr lock execute entrypoint};
type_transition initrc_t nagios_exec_t : process nagios_t;
(This assumes nagios_disable_trans is off.)

Where is that from? I took the c5 SRMP and ran rpmbuild -bp, in my BUILD
dir i dont see those:
/home/cmr/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services: grep
initrc nagios*
-> nothing

CHris

[Christoph Maser]

Post by Pavel Kankovsky

Post by Christoph Maser
- init script: it is possible to start nagios as root or nagios user on
the command line but not using the init script. the init script is
context initrc_exec_t and that context is not allowed

This is strange. What is "not allowed"? As far as I can tell, the
transition from initrc_t (the domain corresponding to initrc_exec_t)
allow initrc_t nagios_exec_t : file {read getattr execute};
allow initrc_t nagios_t : process {transition sigchld noatsecure siginh rlimitinh};
allow nagios_t nagios_exec_t : file {ioctl read getattr lock execute entrypoint};
type_transition initrc_t nagios_exec_t : process nagios_t;
(This assumes nagios_disable_trans is off.)

Where is that from? I took the c5 SRMP and ran rpmbuild -bp, in my BUILD
dir i dont see those:
/home/cmr/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services: grep
initrc nagios*
-> nothing

CHris

[Christoph Maser]

Post by Pavel Kankovsky

Post by Christoph Maser
- init script: it is possible to start nagios as root or nagios user on
the command line but not using the init script. the init script is
context initrc_exec_t and that context is not allowed

This is strange. What is "not allowed"? As far as I can tell, the
transition from initrc_t (the domain corresponding to initrc_exec_t)
allow initrc_t nagios_exec_t : file {read getattr execute};
allow initrc_t nagios_t : process {transition sigchld noatsecure siginh rlimitinh};
allow nagios_t nagios_exec_t : file {ioctl read getattr lock execute entrypoint};
type_transition initrc_t nagios_exec_t : process nagios_t;
(This assumes nagios_disable_trans is off.)

Where is that from? I took the c5 SRMP and ran rpmbuild -bp, in my BUILD
dir i dont see those:
/home/cmr/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services: grep
initrc nagios*
-> nothing

CHris

[Christoph Maser]

Post by Pavel Kankovsky

Post by Christoph Maser
- init script: it is possible to start nagios as root or nagios user on
the command line but not using the init script. the init script is
context initrc_exec_t and that context is not allowed

This is strange. What is "not allowed"? As far as I can tell, the
transition from initrc_t (the domain corresponding to initrc_exec_t)
allow initrc_t nagios_exec_t : file {read getattr execute};
allow initrc_t nagios_t : process {transition sigchld noatsecure siginh rlimitinh};
allow nagios_t nagios_exec_t : file {ioctl read getattr lock execute entrypoint};
type_transition initrc_t nagios_exec_t : process nagios_t;
(This assumes nagios_disable_trans is off.)

Where is that from? I took the c5 SRMP and ran rpmbuild -bp, in my BUILD
dir i dont see those:
/home/cmr/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services: grep
initrc nagios*
-> nothing

CHris

[Pavel Kankovsky]

Post by Christoph Maser
Where is that from?

Examine the binary policy with apol or sesearch.

Post by Christoph Maser
I took the c5 SRMP and ran rpmbuild -bp, in my BUILD
/home/cmr/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services: grep
initrc nagios*
-> nothing

The rules are generated by a M4 macro invoked in nagios.te:

init_daemon_domain(nagios_t, nagios_exec_t)

[Christoph Maser]

Post by Pavel Kankovsky

Post by Christoph Maser
Where is that from?

Examine the binary policy with apol or sesearch.

Post by Christoph Maser
I took the c5 SRMP and ran rpmbuild -bp, in my BUILD
/home/cmr/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services: grep
initrc nagios*
-> nothing

init_daemon_domain(nagios_t, nagios_exec_t)

Thanks for the pointers, I still couldn't find out why its not working.
Actually it doesn't produce any denials in audit.log. If I use the init
script from any other location its just works.

Chris

[Christoph Maser]

Post by Christoph Maser

Post by Pavel Kankovsky

Post by Christoph Maser
Where is that from?

Examine the binary policy with apol or sesearch.

Post by Christoph Maser
I took the c5 SRMP and ran rpmbuild -bp, in my BUILD
/home/cmr/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services: grep
initrc nagios*
-> nothing

init_daemon_domain(nagios_t, nagios_exec_t)

Thanks for the pointers, I still couldn't find out why its not working.
Actually it doesn't produce any denials in audit.log. If I use the init
script from any other location its just works.
Chris

Well have to correct myself again. It is generating denials. Actually
the policy does not allow general read/write access to the spool dir,
wich is where I think the checkresult dir belongs. I guess a workaround
would be to put the checkresults dir below /var/log/nagios. If that
works I will change the spec accordingly.

Thanks again for your support
Chris

[Christoph Maser]

Post by Christoph Maser

Post by Pavel Kankovsky

Post by Christoph Maser
Where is that from?

Examine the binary policy with apol or sesearch.

Post by Christoph Maser
I took the c5 SRMP and ran rpmbuild -bp, in my BUILD
/home/cmr/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services: grep
initrc nagios*
-> nothing

init_daemon_domain(nagios_t, nagios_exec_t)

Thanks for the pointers, I still couldn't find out why its not working.
Actually it doesn't produce any denials in audit.log. If I use the init
script from any other location its just works.
Chris

Well have to correct myself again. It is generating denials. Actually
the policy does not allow general read/write access to the spool dir,
wich is where I think the checkresult dir belongs. I guess a workaround
would be to put the checkresults dir below /var/log/nagios. If that
works I will change the spec accordingly.

Thanks again for your support
Chris

[Christoph Maser]

Post by Christoph Maser

Post by Pavel Kankovsky

Post by Christoph Maser
Where is that from?

Examine the binary policy with apol or sesearch.

Post by Christoph Maser
I took the c5 SRMP and ran rpmbuild -bp, in my BUILD
/home/cmr/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services: grep
initrc nagios*
-> nothing

init_daemon_domain(nagios_t, nagios_exec_t)

Thanks for the pointers, I still couldn't find out why its not working.
Actually it doesn't produce any denials in audit.log. If I use the init
script from any other location its just works.
Chris

Well have to correct myself again. It is generating denials. Actually
the policy does not allow general read/write access to the spool dir,
wich is where I think the checkresult dir belongs. I guess a workaround
would be to put the checkresults dir below /var/log/nagios. If that
works I will change the spec accordingly.

Thanks again for your support
Chris

[Christoph Maser]

Post by Christoph Maser

Post by Pavel Kankovsky

Post by Christoph Maser
Where is that from?

Examine the binary policy with apol or sesearch.

Post by Christoph Maser
I took the c5 SRMP and ran rpmbuild -bp, in my BUILD
/home/cmr/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services: grep
initrc nagios*
-> nothing

init_daemon_domain(nagios_t, nagios_exec_t)

Thanks for the pointers, I still couldn't find out why its not working.
Actually it doesn't produce any denials in audit.log. If I use the init
script from any other location its just works.
Chris

Well have to correct myself again. It is generating denials. Actually
the policy does not allow general read/write access to the spool dir,
wich is where I think the checkresult dir belongs. I guess a workaround
would be to put the checkresults dir below /var/log/nagios. If that
works I will change the spec accordingly.

Thanks again for your support
Chris

[Christoph Maser]

Post by Christoph Maser

Post by Pavel Kankovsky

Post by Christoph Maser
Where is that from?

Examine the binary policy with apol or sesearch.

Post by Christoph Maser
I took the c5 SRMP and ran rpmbuild -bp, in my BUILD
/home/cmr/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services: grep
initrc nagios*
-> nothing

init_daemon_domain(nagios_t, nagios_exec_t)

Thanks for the pointers, I still couldn't find out why its not working.
Actually it doesn't produce any denials in audit.log. If I use the init
script from any other location its just works.
Chris

Well have to correct myself again. It is generating denials. Actually
the policy does not allow general read/write access to the spool dir,
wich is where I think the checkresult dir belongs. I guess a workaround
would be to put the checkresults dir below /var/log/nagios. If that
works I will change the spec accordingly.

Thanks again for your support
Chris

[Christoph Maser]

Post by Pavel Kankovsky

Post by Christoph Maser
Where is that from?

Examine the binary policy with apol or sesearch.

Post by Christoph Maser
I took the c5 SRMP and ran rpmbuild -bp, in my BUILD
/home/cmr/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services: grep
initrc nagios*
-> nothing

init_daemon_domain(nagios_t, nagios_exec_t)

Thanks for the pointers, I still couldn't find out why its not working.
Actually it doesn't produce any denials in audit.log. If I use the init
script from any other location its just works.

Chris

[Christoph Maser]

Post by Pavel Kankovsky

Post by Christoph Maser
Where is that from?

Examine the binary policy with apol or sesearch.

Post by Christoph Maser
I took the c5 SRMP and ran rpmbuild -bp, in my BUILD
/home/cmr/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services: grep
initrc nagios*
-> nothing

init_daemon_domain(nagios_t, nagios_exec_t)

Thanks for the pointers, I still couldn't find out why its not working.
Actually it doesn't produce any denials in audit.log. If I use the init
script from any other location its just works.

Chris

[Christoph Maser]

Post by Pavel Kankovsky

Post by Christoph Maser
Where is that from?

Examine the binary policy with apol or sesearch.

Post by Christoph Maser
I took the c5 SRMP and ran rpmbuild -bp, in my BUILD
/home/cmr/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services: grep
initrc nagios*
-> nothing

init_daemon_domain(nagios_t, nagios_exec_t)

Thanks for the pointers, I still couldn't find out why its not working.
Actually it doesn't produce any denials in audit.log. If I use the init
script from any other location its just works.

Chris

[Christoph Maser]

Post by Pavel Kankovsky

Post by Christoph Maser
Where is that from?

Examine the binary policy with apol or sesearch.

Post by Christoph Maser
I took the c5 SRMP and ran rpmbuild -bp, in my BUILD
/home/cmr/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services: grep
initrc nagios*
-> nothing

init_daemon_domain(nagios_t, nagios_exec_t)

Thanks for the pointers, I still couldn't find out why its not working.
Actually it doesn't produce any denials in audit.log. If I use the init
script from any other location its just works.

Chris

[Pavel Kankovsky]

Post by Christoph Maser
Thanks for the pointers, I still couldn't find out why its not working.
Actually it doesn't produce any denials in audit.log.

Have you tried "semodule -i enableaudit.pp"?

[Pavel Kankovsky]

Post by Christoph Maser
- init script: it is possible to start nagios as root or nagios user on
the command line but not using the init script. the init script is
context initrc_exec_t and that context is not allowed

This is strange. What is "not allowed"? As far as I can tell, the
transition from initrc_t (the domain corresponding to initrc_exec_t)
to nagios_t is allowed:

allow initrc_t nagios_exec_t : file {read getattr execute};
allow initrc_t nagios_t : process {transition sigchld noatsecure siginh rlimitinh};
allow nagios_t nagios_exec_t : file {ioctl read getattr lock execute entrypoint};
type_transition initrc_t nagios_exec_t : process nagios_t;

(This assumes nagios_disable_trans is off.)

[Pavel Kankovsky]

Post by Christoph Maser
Where is that from?

Examine the binary policy with apol or sesearch.

Post by Christoph Maser
I took the c5 SRMP and ran rpmbuild -bp, in my BUILD
/home/cmr/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services: grep
initrc nagios*
-> nothing

The rules are generated by a M4 macro invoked in nagios.te:

init_daemon_domain(nagios_t, nagios_exec_t)

[Pavel Kankovsky]

Post by Christoph Maser
Thanks for the pointers, I still couldn't find out why its not working.
Actually it doesn't produce any denials in audit.log.

Have you tried "semodule -i enableaudit.pp"?

[Pavel Kankovsky]

Post by Christoph Maser
- init script: it is possible to start nagios as root or nagios user on
the command line but not using the init script. the init script is
context initrc_exec_t and that context is not allowed

This is strange. What is "not allowed"? As far as I can tell, the
transition from initrc_t (the domain corresponding to initrc_exec_t)
to nagios_t is allowed:

allow initrc_t nagios_exec_t : file {read getattr execute};
allow initrc_t nagios_t : process {transition sigchld noatsecure siginh rlimitinh};
allow nagios_t nagios_exec_t : file {ioctl read getattr lock execute entrypoint};
type_transition initrc_t nagios_exec_t : process nagios_t;

(This assumes nagios_disable_trans is off.)

[Pavel Kankovsky]

Post by Christoph Maser
Where is that from?

Examine the binary policy with apol or sesearch.

Post by Christoph Maser
I took the c5 SRMP and ran rpmbuild -bp, in my BUILD
/home/cmr/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services: grep
initrc nagios*
-> nothing

The rules are generated by a M4 macro invoked in nagios.te:

init_daemon_domain(nagios_t, nagios_exec_t)

[Pavel Kankovsky]

Post by Christoph Maser
Thanks for the pointers, I still couldn't find out why its not working.
Actually it doesn't produce any denials in audit.log.

Have you tried "semodule -i enableaudit.pp"?

[Pavel Kankovsky]

Post by Christoph Maser
- init script: it is possible to start nagios as root or nagios user on
the command line but not using the init script. the init script is
context initrc_exec_t and that context is not allowed

This is strange. What is "not allowed"? As far as I can tell, the
transition from initrc_t (the domain corresponding to initrc_exec_t)
to nagios_t is allowed:

allow initrc_t nagios_exec_t : file {read getattr execute};
allow initrc_t nagios_t : process {transition sigchld noatsecure siginh rlimitinh};
allow nagios_t nagios_exec_t : file {ioctl read getattr lock execute entrypoint};
type_transition initrc_t nagios_exec_t : process nagios_t;

(This assumes nagios_disable_trans is off.)

[Pavel Kankovsky]

Post by Christoph Maser
Where is that from?

Examine the binary policy with apol or sesearch.

Post by Christoph Maser
I took the c5 SRMP and ran rpmbuild -bp, in my BUILD
/home/cmr/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services: grep
initrc nagios*
-> nothing

The rules are generated by a M4 macro invoked in nagios.te:

init_daemon_domain(nagios_t, nagios_exec_t)

[Pavel Kankovsky]

Post by Christoph Maser
Thanks for the pointers, I still couldn't find out why its not working.
Actually it doesn't produce any denials in audit.log.

Have you tried "semodule -i enableaudit.pp"?

[Pavel Kankovsky]

Post by Christoph Maser
- init script: it is possible to start nagios as root or nagios user on
the command line but not using the init script. the init script is
context initrc_exec_t and that context is not allowed

This is strange. What is "not allowed"? As far as I can tell, the
transition from initrc_t (the domain corresponding to initrc_exec_t)
to nagios_t is allowed:

allow initrc_t nagios_exec_t : file {read getattr execute};
allow initrc_t nagios_t : process {transition sigchld noatsecure siginh rlimitinh};
allow nagios_t nagios_exec_t : file {ioctl read getattr lock execute entrypoint};
type_transition initrc_t nagios_exec_t : process nagios_t;

(This assumes nagios_disable_trans is off.)

[Pavel Kankovsky]

Post by Christoph Maser
Where is that from?

Examine the binary policy with apol or sesearch.

Post by Christoph Maser
I took the c5 SRMP and ran rpmbuild -bp, in my BUILD
/home/cmr/rpmbuild/BUILD/serefpolicy-2.4.6/policy/modules/services: grep
initrc nagios*
-> nothing

The rules are generated by a M4 macro invoked in nagios.te:

init_daemon_domain(nagios_t, nagios_exec_t)

[Pavel Kankovsky]

Post by Christoph Maser
Thanks for the pointers, I still couldn't find out why its not working.
Actually it doesn't produce any denials in audit.log.

Have you tried "semodule -i enableaudit.pp"?