Sendmail & SELinux policies, again

Sendmail & SELinux policies, again

[Tanel Kokk]

Hello

Everything works fine with sendmail & SELinux most of time. However, 
sometimes SELinux in our server rejects such activities:

Apr 12 03:40:08 mx.internal audit(1144802408.867:9): avc:  denied  { 
recv_msg } for  saddr=201.37.237.52 src=5989 daddr=192.168.xxx.xxx 
dest=8025 netif=eth0 scontext=user_u:system_r:sendmail_t 
tcontext=system_u:object_r:pegasus_https_port_t tclass=tcp_socket

Apr 12 03:40:11 mx.internal audit(1144802411.714:10): avc:  denied  { 
recv_msg } for  saddr=201.37.237.52 src=5989 daddr=192.168.xxx.xxx 
dest=8025 netif=eth0 scontext=user_u:system_r:sendmail_t 
tcontext=system_u:object_r:pegasus_https_port_t tclass=tcp_socket

Apr 12 03:40:17 mx.internal audit(1144802417.727:11): avc:  denied  { 
recv_msg } for  saddr=201.37.237.52 src=5989 daddr=192.168.xxx.xxx 
dest=8025 netif=eth0 scontext=user_u:system_r:sendmail_t 
tcontext=system_u:object_r:pegasus_https_port_t tclass=tcp_socket

, where mx.internal [192.168.xxx.xxx] is our email gateway and dest=8025 
is port, where sendmail actually listening from (iptables forwards port 
25 to 8025 in transparent way).

With audit2allow I get:
allow sendmail_t pegasus_https_port_t:tcp_socket recv_msg;

I found that there are some specific ports, which are defined as:
portcon tcp 5989  system_u:object_r:pegasus_https_port_t
portcon tcp 3306 system_u:object_r:mysqld_port_t
portcon tcp 5432 system_u:object_r:postgresql_port_t
portcon tcp 5988  system_u:object_r:pegasus_http_port_t
portcon tcp 3128  system_u:object_r:http_cache_port_t
portcon tcp 8080  system_u:object_r:http_cache_port_t
portcon tcp 1-1023 system_u:object_r:reserved_port_t

So as I understand, when source connection come from so called 
"specific" port (for example 5989) and goes to port 25, then this 
connection will be rejected by default. What is that good for?

IMHO it is quite possible, that source port would be something like 
3128, 5988 or 3306.

I just thought to add such policies for sendmail_t:

allow sendmail_t pegasus_https_port_t:tcp_socket recv_msg;
allow sendmail_t mysqld_port_t:tcp_socket recv_msg;
allow sendmail_t postgresql_port_t:tcp_socket recv_msg;
allow sendmail_t pegasus_http_port_t:tcp_socket recv_msg;
allow sendmail_t http_cache_port_t:tcp_socket recv_msg;

Is it good solusion?


-- 
Tanel Kokk


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Sendmail & SELinux policies, again

[Stephen Smalley]

On Wed, 2006-04-12 at 11:03 +0300, Tanel Kokk wrote:
> Hello
> 
> Everything works fine with sendmail & SELinux most of time. However, 
> sometimes SELinux in our server rejects such activities:
> 
> Apr 12 03:40:08 mx.internal audit(1144802408.867:9): avc:  denied  { 
> recv_msg } for  saddr=201.37.237.52 src=5989 daddr=192.168.xxx.xxx 
> dest=8025 netif=eth0 scontext=user_u:system_r:sendmail_t 
> tcontext=system_u:object_r:pegasus_https_port_t tclass=tcp_socket
> 
> Apr 12 03:40:11 mx.internal audit(1144802411.714:10): avc:  denied  { 
> recv_msg } for  saddr=201.37.237.52 src=5989 daddr=192.168.xxx.xxx 
> dest=8025 netif=eth0 scontext=user_u:system_r:sendmail_t 
> tcontext=system_u:object_r:pegasus_https_port_t tclass=tcp_socket
> 
> Apr 12 03:40:17 mx.internal audit(1144802417.727:11): avc:  denied  { 
> recv_msg } for  saddr=201.37.237.52 src=5989 daddr=192.168.xxx.xxx 
> dest=8025 netif=eth0 scontext=user_u:system_r:sendmail_t 
> tcontext=system_u:object_r:pegasus_https_port_t tclass=tcp_socket
> 
> , where mx.internal [192.168.xxx.xxx] is our email gateway and dest=8025 
> is port, where sendmail actually listening from (iptables forwards port 
> 25 to 8025 in transparent way).
> 
> With audit2allow I get:
> allow sendmail_t pegasus_https_port_t:tcp_socket recv_msg;
> 
> I found that there are some specific ports, which are defined as:
> portcon tcp 5989  system_u:object_r:pegasus_https_port_t
> portcon tcp 3306 system_u:object_r:mysqld_port_t
> portcon tcp 5432 system_u:object_r:postgresql_port_t
> portcon tcp 5988  system_u:object_r:pegasus_http_port_t
> portcon tcp 3128  system_u:object_r:http_cache_port_t
> portcon tcp 8080  system_u:object_r:http_cache_port_t
> portcon tcp 1-1023 system_u:object_r:reserved_port_t
> 
> So as I understand, when source connection come from so called 
> "specific" port (for example 5989) and goes to port 25, then this 
> connection will be rejected by default. What is that good for?
> 
> IMHO it is quite possible, that source port would be something like 
> 3128, 5988 or 3306.
> 
> I just thought to add such policies for sendmail_t:
> 
> allow sendmail_t pegasus_https_port_t:tcp_socket recv_msg;
> allow sendmail_t mysqld_port_t:tcp_socket recv_msg;
> allow sendmail_t postgresql_port_t:tcp_socket recv_msg;
> allow sendmail_t pegasus_http_port_t:tcp_socket recv_msg;
> allow sendmail_t http_cache_port_t:tcp_socket recv_msg;
> 
> Is it good solusion?

If you just want to allow sendmail_t to receive from any port, then you
can just use:
allow sendmail_t port_type:tcp_socket { recv_msg };

port_type is then expanded to the set of all types that have the
"port_type" attribute listed, either in their type declaration (ala type
foo_t, port_type;) or in a separate typeattribute declaration (ala
typeattribute foo_t port_type;).  All port types should have that
attribute.

I think that the example sendmail policy does allow send_msg and
recv_msg to all port types (via the can_network macro).  

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Sendmail & SELinux policies, again

[Tanel Kokk]

Stephen Smalley wrote:
> If you just want to allow sendmail_t to receive from any port, then you
> can just use:
> allow sendmail_t port_type:tcp_socket { recv_msg };
OK.

> 
> port_type is then expanded to the set of all types that have the
> "port_type" attribute listed, either in their type declaration (ala type
> foo_t, port_type;) or in a separate typeattribute declaration (ala
> typeattribute foo_t port_type;).  All port types should have that
> attribute.
> 
> I think that the example sendmail policy does allow send_msg and
> recv_msg to all port types (via the can_network macro).  
> 
Can I just add such macro to my policy?

can_network(sendmail_t)

Where I can get example sendmail policies? CentOS doesn'n have these
ones for sendmail.


-- 
Tanel Kokk


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Sendmail & SELinux policies, again

[Christopher J. PeBenito]

On Wed, 2006-04-12 at 08:43 -0400, Stephen Smalley wrote:
> On Wed, 2006-04-12 at 11:03 +0300, Tanel Kokk wrote:
> > I just thought to add such policies for sendmail_t:
> > 
> > allow sendmail_t pegasus_https_port_t:tcp_socket recv_msg;
> > allow sendmail_t mysqld_port_t:tcp_socket recv_msg;
> > allow sendmail_t postgresql_port_t:tcp_socket recv_msg;
> > allow sendmail_t pegasus_http_port_t:tcp_socket recv_msg;
> > allow sendmail_t http_cache_port_t:tcp_socket recv_msg;
> > 
> > Is it good solusion?
> 
> If you just want to allow sendmail_t to receive from any port, then you
> can just use:
> allow sendmail_t port_type:tcp_socket { recv_msg };

> I think that the example sendmail policy does allow send_msg and
> recv_msg to all port types (via the can_network macro).  

Both example policy and refpolicy already have this rule.  I don't know
why you would be hitting this.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Sendmail & SELinux policies, again

[Stephen Smalley]

On Wed, 2006-04-12 at 09:16 -0400, Christopher J. PeBenito wrote:
> On Wed, 2006-04-12 at 08:43 -0400, Stephen Smalley wrote:
> > On Wed, 2006-04-12 at 11:03 +0300, Tanel Kokk wrote:
> > > I just thought to add such policies for sendmail_t:
> > > 
> > > allow sendmail_t pegasus_https_port_t:tcp_socket recv_msg;
> > > allow sendmail_t mysqld_port_t:tcp_socket recv_msg;
> > > allow sendmail_t postgresql_port_t:tcp_socket recv_msg;
> > > allow sendmail_t pegasus_http_port_t:tcp_socket recv_msg;
> > > allow sendmail_t http_cache_port_t:tcp_socket recv_msg;
> > > 
> > > Is it good solusion?
> > 
> > If you just want to allow sendmail_t to receive from any port, then you
> > can just use:
> > allow sendmail_t port_type:tcp_socket { recv_msg };
> 
> > I think that the example sendmail policy does allow send_msg and
> > recv_msg to all port types (via the can_network macro).  
> 
> Both example policy and refpolicy already have this rule.  I don't know
> why you would be hitting this.

Because he rolled his own sendmail policy from scratch, since the
targeted policy in CentOS (derived from RHEL) didn't include a sendmail
policy.  Although I suspect the necessary .te files were included in
the .src.rpm, just omitted from the build.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Sendmail & SELinux policies, again

[Tanel Kokk]

Stephen Smalley wrote:
>> Both example policy and refpolicy already have this rule.  I don't know
>> why you would be hitting this.

 From where can I get the current/latest/working sendmail SELinux 
policy? Redhat, Fedora, nsa.gov/selinux?

> 
> Because he rolled his own sendmail policy from scratch, since the
> targeted policy in CentOS (derived from RHEL) didn't include a sendmail
> policy.  Although I suspect the necessary .te files were included in
> the .src.rpm, just omitted from the build.
> 


-- 
Tanel Kokk


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Sendmail & SELinux policies, again

[Tanel Kokk]

Stephen Smalley wrote:
> Given your situation, it may be best to just use what you have (i.e.
> your own custom sendmail policy) and adjust it as needed.  The reason I
> say that is that:
> a) targeted policy doesn't confine sendmail presently.  Even if you grab
> the latest sendmail.te, it has ifdefs to turn sendmail_t into an
> unconfined domain if building targeted policy.  You would have to remove
> that block and adapt the sendmail policy to work with targeted policy
> properly.
> b) you are using CentOS, so you have an older policy base and an older
> policy toolchain.  Trying to use the current/latest sendmail.te and
> mta.te with that older base and toolchain might yield a policy that
> doesn't even compile, much less work.

Thanks!


-- 
Tanel Kokk


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Sendmail & SELinux policies, again

[Stephen Smalley]

On Wed, 2006-04-12 at 16:45 +0300, Tanel Kokk wrote:
>  From where can I get the current/latest/working sendmail SELinux 
> policy? Redhat, Fedora, nsa.gov/selinux?

Given your situation, it may be best to just use what you have (i.e.
your own custom sendmail policy) and adjust it as needed.  The reason I
say that is that:
a) targeted policy doesn't confine sendmail presently.  Even if you grab
the latest sendmail.te, it has ifdefs to turn sendmail_t into an
unconfined domain if building targeted policy.  You would have to remove
that block and adapt the sendmail policy to work with targeted policy
properly.
b) you are using CentOS, so you have an older policy base and an older
policy toolchain.  Trying to use the current/latest sendmail.te and
mta.te with that older base and toolchain might yield a policy that
doesn't even compile, much less work.

You can certainly look at the example policy and reference policy
definitions for sendmail and mta for reference in writing your own, but
I'm not sure you can really use them directly in a useful manner
(without switching to -strict, which should have a sendmail policy
already).

For reference, the NSA example policy is available at
http://www.nsa.gov/selinux/archives/old/policy.tgz
and its cvs tree is at:
http://cvs.sourceforge.net/viewcvs.py/selinux/nsa/selinux-usr/policy/

And the reference policy is available from the sourceforge site,
http://serefpolicy.sf.net.

But I don't think you want to try to just plug-and-play those files into
your current base policy.   They likely rely on other changes made to
the base policies, like newer macro definitions, as well as newer policy
language features, that aren't supported by the CentOS base policy.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.