spamassassin transition

[Scott Radvan]

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

[Dominick Grift]

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

[Daniel Fazekas]

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.

[Dominick Grift]

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(a)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

[Vadym Chepkov]

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(a)redhat.com&gt; wrote:

>  From: Scott Radvan <sradvan(a)redhat.com&gt;
>  Subject: spamassassin transition
>  To: fedora-selinux-list(a)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(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>

[Scott Radvan]

On Mon, 3 Aug 2009 06:31:31 -0700 (PDT)
Vadym Chepkov <chepkov(a)yahoo.com&gt; 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.

-- 
Scott Radvan
Content Author, Platform (Installation and Deployment)
Red Hat Asia Pacific (Brisbane) http://www.apac.redhat.com