Hi,
Working on the Postfix chapter in my SELinux managing confined services book [0] and am having trouble with Postfix/spamassassin.
I have got email traversing back and forth just fine, but I am trying to invoke a denial or a problem for which I can document the work-around. spamassassin_can_network seems to be a good Boolean to explain, show the denial and then show the work-around for.
This Boolean is off by default, which as far as I can tell would stop spamassassin from launching as a daemon listening on the machine's actual IP/interface.
But my problem is that it is launching without a problem and listening on the machine's interface without error. I am assuming that it is working fine because the spamassassin processes are only launching as initrc_t, when it should be transitioning to something else..?
# ps -eZ | grep spamd unconfined_u:system_r:initrc_t:s0 3085 ? 00:00:01 spamd unconfined_u:system_r:initrc_t:s0 3087 ? 00:00:00 spamd unconfined_u:system_r:initrc_t:s0 3088 ? 00:00:00 spamd
# ls -lZ /etc/init.d/spamassassin -rwxr-xr-x. rootrootsystem_u:object_r:initrc_exec_t:s0 /etc/init.d/spamassassin
(I tried labelling this differently to this default setting, to spamd_initrc_exec_t, but to no avail.)
# getsebool -a | grep spam spamassassin_can_network --> off spamd_enable_home_dirs --> on
Basically I need to make sure spamassassin is starting normally so that the Boolean mentioned will block access. So any help is appreciated, should spamassassin as a daemon transition to something other than initrc_t? And how do I get it to do so?
Or am I going down the wrong track to get this Boolean which is off by default to do something which I can demonstrate and fix?
Thank you,
On Mon, 2009-08-03 at 10:20 +1000, Scott Radvan wrote:
Hi,
Working on the Postfix chapter in my SELinux managing confined services book [0] and am having trouble with Postfix/spamassassin.
I have got email traversing back and forth just fine, but I am trying to invoke a denial or a problem for which I can document the work-around. spamassassin_can_network seems to be a good Boolean to explain, show the denial and then show the work-around for.
This Boolean is off by default, which as far as I can tell would stop spamassassin from launching as a daemon listening on the machine's actual IP/interface.
But my problem is that it is launching without a problem and listening on the machine's interface without error. I am assuming that it is working fine because the spamassassin processes are only launching as initrc_t, when it should be transitioning to something else..?
# ps -eZ | grep spamd unconfined_u:system_r:initrc_t:s0 3085 ? 00:00:01 spamd unconfined_u:system_r:initrc_t:s0 3087 ? 00:00:00 spamd unconfined_u:system_r:initrc_t:s0 3088 ? 00:00:00 spamd
# ls -lZ /etc/init.d/spamassassin -rwxr-xr-x. rootrootsystem_u:object_r:initrc_exec_t:s0 /etc/init.d/spamassassin
(I tried labelling this differently to this default setting, to spamd_initrc_exec_t, but to no avail.)
# getsebool -a | grep spam spamassassin_can_network --> off spamd_enable_home_dirs --> on
Basically I need to make sure spamassassin is starting normally so that the Boolean mentioned will block access. So any help is appreciated, should spamassassin as a daemon transition to something other than initrc_t? And how do I get it to do so?
Or am I going down the wrong track to get this Boolean which is off by default to do something which I can demonstrate and fix?
Thank you,
Not sure but probably a bug.
This is a application domain. i cannot find a init_daemon_domain declaration, meaning initrc_t does not transition.
There is a spamassassin_role() in the interface file with a transition defined for users however this interface is probably not called by the user domains.
hth
So first see if you can get it to run in its domain by restoring the locations mentioned under contexts. If that does
On Aug 3, 2009, at 02:20, Scott Radvan wrote:
spamassassin_can_network seems to be a good Boolean to explain, show the denial and then show the work-around for. This Boolean is off by default, which as far as I can tell would stop spamassassin from launching as a daemon listening on the machine's actual IP/interface.
I thought spamassassin_can_network was for allowing SpamAssassin to access various online services, such as Razor2 or Pyzor, for more accurate spam detection.
On Mon, 2009-08-03 at 10:13 +0200, Daniel Fazekas wrote:
On Aug 3, 2009, at 02:20, Scott Radvan wrote:
spamassassin_can_network seems to be a good Boolean to explain, show the denial and then show the work-around for. This Boolean is off by default, which as far as I can tell would stop spamassassin from launching as a daemon listening on the machine's actual IP/interface.
I thought spamassassin_can_network was for allowing SpamAssassin to access various online services, such as Razor2 or Pyzor, for more accurate spam detection.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
basically it allow spamassassin_t to connect to any tcp port and sendrecv udp.
# set tunable if you have spamassassin do DNS lookups tunable_policy(`spamassassin_can_network',` allow spamassassin_t self:tcp_socket create_stream_socket_perms; allow spamassassin_t self:udp_socket create_socket_perms;
corenet_all_recvfrom_unlabeled(spamassassin_t) corenet_all_recvfrom_netlabel(spamassassin_t) corenet_tcp_sendrecv_generic_if(spamassassin_t) corenet_udp_sendrecv_generic_if(spamassassin_t) corenet_tcp_sendrecv_generic_node(spamassassin_t) corenet_udp_sendrecv_generic_node(spamassassin_t) corenet_tcp_sendrecv_all_ports(spamassassin_t) corenet_udp_sendrecv_all_ports(spamassassin_t) corenet_tcp_connect_all_ports(spamassassin_t) corenet_sendrecv_all_client_packets(spamassassin_t) corenet_udp_bind_generic_node(spamassassin_t)
sysnet_read_config(spamassassin_t) ')
hth
I filed bugzilla report about it, https://bugzilla.redhat.com/show_bug.cgi?id=509644
Sincerely yours, Vadym Chepkov
--- On Sun, 8/2/09, Scott Radvan sradvan@redhat.com wrote:
From: Scott Radvan sradvan@redhat.com Subject: spamassassin transition To: fedora-selinux-list@redhat.com Date: Sunday, August 2, 2009, 8:20 PM Hi,
Working on the Postfix chapter in my SELinux managing confined services book [0] and am having trouble with Postfix/spamassassin.
I have got email traversing back and forth just fine, but I am trying to invoke a denial or a problem for which I can document the work-around. spamassassin_can_network seems to be a good Boolean to explain, show the denial and then show the work-around for.
This Boolean is off by default, which as far as I can tell would stop spamassassin from launching as a daemon listening on the machine's actual IP/interface.
But my problem is that it is launching without a problem and listening on the machine's interface without error. I am assuming that it is working fine because the spamassassin processes are only launching as initrc_t, when it should be transitioning to something else..?
# ps -eZ | grep spamd unconfined_u:system_r:initrc_t:s0 3085 ? 00:00:01 spamd unconfined_u:system_r:initrc_t:s0 3087 ? 00:00:00 spamd unconfined_u:system_r:initrc_t:s0 3088 ? 00:00:00 spamd
# ls -lZ /etc/init.d/spamassassin -rwxr-xr-x. rootrootsystem_u:object_r:initrc_exec_t:s0 /etc/init.d/spamassassin
(I tried labelling this differently to this default setting, to spamd_initrc_exec_t, but to no avail.)
# getsebool -a | grep spam spamassassin_can_network --> off spamd_enable_home_dirs --> on
Basically I need to make sure spamassassin is starting normally so that the Boolean mentioned will block access. So any help is appreciated, should spamassassin as a daemon transition to something other than initrc_t? And how do I get it to do so?
Or am I going down the wrong track to get this Boolean which is off by default to do something which I can demonstrate and fix?
Thank you,
-- Scott Radvan Content Author, Platform (Installation and Deployment) Red Hat Asia Pacific (Brisbane) http://www.apac.redhat.com
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Mon, 3 Aug 2009 06:31:31 -0700 (PDT) Vadym Chepkov chepkov@yahoo.com wrote:
I filed bugzilla report about it, https://bugzilla.redhat.com/show_bug.cgi?id=509644 Sincerely yours, Vadym Chepkov
Great, thank you for this! It fixed my problem.
selinux@lists.fedoraproject.org