Greetings, while attempting to set up leafnode http://leafnode.sourceforge.net I had a problem with mounting its spool, /var/spool/news:
Sep 14 00:36:11 camelot kernel: audit(1158186712.955:375): avc: denied { mounton } for pid=1353 comm="mount" name="news" dev=dm-3 ino=65600 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:news_spool_t:s0 tclass=dir
Using audit2why and then audit2allow I was able to come up with the following .te policy:
module news 1.0;
require { class dir mounton; type mount_t; type news_spool_t; role system_r; };
allow mount_t news_spool_t:dir mounton;
which to my untrained eye looked good. Researching the archives before writing this, however, I came upon the answer for a similar problem:
https://www.redhat.com/archives/fedora-selinux-list/2006-August/msg00096.htm...
and found out that it would probably have been enough to label the mount point mnt_t (haven't tried it yet). Assuming it works, how should I have found out about it ? I tried rpm -qd and found out about the selinux-policy documentation, but nothing showed up for the targeted policy. In this context, isn't audit2allow somewhat ... dangerous ?
Or was it just a shortcoming in the leafnode RPM, so I should be looking at what INN is doing instead ?
Thank you for your consideration, Davide Bolcioni
On Sat, 2006-09-30 at 01:16 +0200, Davide Bolcioni wrote:
Greetings, while attempting to set up leafnode http://leafnode.sourceforge.net I had a problem with mounting its spool, /var/spool/news:
Sep 14 00:36:11 camelot kernel: audit(1158186712.955:375): avc: denied { mounton } for pid=1353 comm="mount" name="news" dev=dm-3 ino=65600 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:news_spool_t:s0 tclass=dir
Using audit2why and then audit2allow I was able to come up with the following .te policy:
module news 1.0;
require { class dir mounton; type mount_t; type news_spool_t; role system_r; };
allow mount_t news_spool_t:dir mounton;
which to my untrained eye looked good. Researching the archives before writing this, however, I came upon the answer for a similar problem:
https://www.redhat.com/archives/fedora-selinux-list/2006-August/msg00096.htm...
and found out that it would probably have been enough to label the mount point mnt_t (haven't tried it yet). Assuming it works, how should I have found out about it ? I tried rpm -qd and found out about the selinux-policy documentation, but nothing showed up for the targeted policy. In this context, isn't audit2allow somewhat ... dangerous ?
Or was it just a shortcoming in the leafnode RPM, so I should be looking at what INN is doing instead ?
This sort of problem only usually crops up when you add a mountpoint post-installation. It's not really something that can be anticipated by packagers of general applications like leafnode (in fact it's a problem for mount rather than a problem for leafnode). It might be useful for SELinux diagnostic tools to note that "mounton" problems are usually the result of a labelling problem rather than a policy problem though.
Labelling the mountpoint as mnt_t should indeed fix this problem.
Paul.
Paul Howarth wrote:
On Sat, 2006-09-30 at 01:16 +0200, Davide Bolcioni wrote:
Greetings, while attempting to set up leafnode http://leafnode.sourceforge.net I had a problem with mounting its spool, /var/spool/news:
Sep 14 00:36:11 camelot kernel: audit(1158186712.955:375): avc: denied { mounton } for pid=1353 comm="mount" name="news" dev=dm-3 ino=65600 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:news_spool_t:s0 tclass=dir
Using audit2why and then audit2allow I was able to come up with the following .te policy:
module news 1.0;
require { class dir mounton; type mount_t; type news_spool_t; role system_r; };
allow mount_t news_spool_t:dir mounton;
which to my untrained eye looked good. Researching the archives before writing this, however, I came upon the answer for a similar problem:
https://www.redhat.com/archives/fedora-selinux-list/2006-August/msg00096.htm...
and found out that it would probably have been enough to label the mount point mnt_t (haven't tried it yet). Assuming it works, how should I have found out about it ? I tried rpm -qd and found out about the selinux-policy documentation, but nothing showed up for the targeted policy. In this context, isn't audit2allow somewhat ... dangerous ?
Or was it just a shortcoming in the leafnode RPM, so I should be looking at what INN is doing instead ?
This sort of problem only usually crops up when you add a mountpoint post-installation. It's not really something that can be anticipated by packagers of general applications like leafnode (in fact it's a problem for mount rather than a problem for leafnode). It might be useful for SELinux diagnostic tools to note that "mounton" problems are usually the result of a labelling problem rather than a policy problem though.
There already is one.
Labelling the mountpoint as mnt_t should indeed fix this problem.
Paul.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Daniel J Walsh wrote:
Paul Howarth wrote:
This sort of problem only usually crops up when you add a mountpoint post-installation. It's not really something that can be anticipated by packagers of general applications like leafnode (in fact it's a problem for mount rather than a problem for leafnode). It might be useful for SELinux diagnostic tools to note that "mounton" problems are usually the result of a labelling problem rather than a policy problem though.
There already is one.
(setroubleshoot plugin snipped)
Splendid. Looking forward to FC6, won't be long now :-)
Paul.
selinux@lists.fedoraproject.org