mail_client_macros.te

mail_client_macros.te

[Russell Coker]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

The attached patch is needed to compile a policy without innd.te.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

[-- Attachment #2: diff --]
[-- Type: text/x-diff, Size: 716 bytes --]

--- macros/program/mail_client_macros.te.orig	2005-06-17 08:23:23.000000000 +1000
+++ macros/program/mail_client_macros.te	2005-06-17 08:24:19.000000000 +1000
@@ -25,8 +25,8 @@
 
 # Allow POP/IMAP/SMTP/NNTP/LDAP/IPP(printing)
 can_ypbind($1_t)
-can_network_client_tcp($1_t, { pop_port_t smtp_port_t innd_port_t ldap_port_t ipp_port_t })
-allow $1_t { pop_port_t smtp_port_t innd_port_t ldap_port_t ipp_port_t }:tcp_socket name_connect;
+can_network_client_tcp($1_t, { pop_port_t smtp_port_t ifdef(`innd.te', `innd_port_t') ldap_port_t ipp_port_t })
+allow $1_t { pop_port_t smtp_port_t ifdef(`innd.te', `innd_port_t') ldap_port_t ipp_port_t }:tcp_socket name_connect;
 
 # Allow printing the mail
 ifdef(`cups.te',`

Re: mail_client_macros.te

[Ivan Gyurdiev]

On Fri, 2005-06-17 at 08:27 +1000, Russell Coker wrote:
> The attached patch is needed to compile a policy without innd.te.

I don't see why the innd port is dependent on the innd policy.

The client is usually on a different machine than the server.

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: mail_client_macros.te

[Russell Coker]

On Friday 17 June 2005 09:19, Ivan Gyurdiev <ivg2@cornell.edu> wrote:
> On Fri, 2005-06-17 at 08:27 +1000, Russell Coker wrote:
> > The attached patch is needed to compile a policy without innd.te.
>
> I don't see why the innd port is dependent on the innd policy.

As long as the type is defined in innd.te it is.  The policy won't compile 
without innd.te included.

The other option is to move the type to types/network.te.

Do you think we should change the policy to move all port type definitions to 
types/network.te and have all ports labeled unconditionally?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: mail_client_macros.te

[Ivan Gyurdiev]

On Fri, 2005-06-17 at 11:32 +1000, Russell Coker wrote:
> On Friday 17 June 2005 09:19, Ivan Gyurdiev <ivg2@cornell.edu> wrote:
> > On Fri, 2005-06-17 at 08:27 +1000, Russell Coker wrote:
> > > The attached patch is needed to compile a policy without innd.te.
> >
> > I don't see why the innd port is dependent on the innd policy.
> 
> As long as the type is defined in innd.te it is.  The policy won't compile 
> without innd.te included.
> 
> The other option is to move the type to types/network.te.
> 
> Do you think we should change the policy to move all port type definitions to 
> types/network.te and have all ports labeled unconditionally?

I think so... at least most of them.

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: mail_client_macros.te

[Stephen Smalley]

On Thu, 2005-06-16 at 21:56 -0400, Ivan Gyurdiev wrote:
> On Fri, 2005-06-17 at 11:32 +1000, Russell Coker wrote:
> > Do you think we should change the policy to move all port type definitions to 
> > types/network.te and have all ports labeled unconditionally?
> 
> I think so... at least most of them.

Concur.   I think that was discussed earlier - it lets us properly
restrict name_bind for the well-defined ports even when that service
isn't on the machine (without requiring the full domain for the service
to also be present), as well to define proper policy over name_connect
on the client side.

-- 
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: mail_client_macros.te

[Christopher J. PeBenito]

On Fri, 2005-06-17 at 07:33 -0400, Stephen Smalley wrote:
> On Thu, 2005-06-16 at 21:56 -0400, Ivan Gyurdiev wrote:
> > On Fri, 2005-06-17 at 11:32 +1000, Russell Coker wrote:
> > > Do you think we should change the policy to move all port type definitions to 
> > > types/network.te and have all ports labeled unconditionally?
> > 
> > I think so... at least most of them.
> 
> Concur.   I think that was discussed earlier - it lets us properly
> restrict name_bind for the well-defined ports even when that service
> isn't on the machine (without requiring the full domain for the service
> to also be present), as well to define proper policy over name_connect
> on the client side.

I agree too.  We've defined all of the ports too, in reference policy,
for the same reasons.  See corenetwork.{te,if}.

-- 
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: mail_client_macros.te

[Daniel J Walsh]

Russell Coker wrote:

>On Friday 17 June 2005 09:19, Ivan Gyurdiev <ivg2@cornell.edu> wrote:
>  
>
>>On Fri, 2005-06-17 at 08:27 +1000, Russell Coker wrote:
>>    
>>
>>>The attached patch is needed to compile a policy without innd.te.
>>>      
>>>
>>I don't see why the innd port is dependent on the innd policy.
>>    
>>
>
>As long as the type is defined in innd.te it is.  The policy won't compile 
>without innd.te included.
>
>The other option is to move the type to types/network.te.
>
>Do you think we should change the policy to move all port type definitions to 
>types/network.te and have all ports labeled unconditionally?
>
>  
>
Now that we are using named_connect, yes.  The port needs to be defined 
so both the client and server app can connect to it.

Dan

-- 



--
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: mail_client_macros.te

[Russell Coker]

[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]

On Friday 17 June 2005 13:14, Daniel J Walsh <dwalsh@redhat.com> wrote:
> >The other option is to move the type to types/network.te.
> >
> >Do you think we should change the policy to move all port type definitions
> > to types/network.te and have all ports labeled unconditionally?
>
> Now that we are using named_connect, yes.  The port needs to be defined
> so both the client and server app can connect to it.

I've attached a patch to implement this change.

There is one potential problem.  I can imagine people wanting to use some 
ports with obvious numbers (such as 1234 for monopd) for other uses.

For example if someone wanted to use netcat to test out some network 
operations they may choose 1234 as an arbitrary port.  Naturally this could 
fail anyway if you have two users on the machine doing similar things, but in 
the case of a single user machine they may be slightly unhappy to have this.

My patch is against the current rawhide policy package and covers all cases 
apart from AFS, GIFT, and inetd children (I'll do those later if the current 
patch is considered a good thing, they are a little more invasive so I just 
did the simple ones for the first pass).

It may be that we want to reserve ports only for the most commonly used 
programs.  So we would reserve ports that are in /etc/services and ports for 
commonly used programs regardless of whether the programs in question are 
installed.  For port assignments that aren't in /etc/services and which are 
not really common (port 1234 for monopd is the best example) we could use the 
previous system of only assigning them if the .te file in question is 
included.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

[-- Attachment #2: diff.gz --]
[-- Type: application/x-gzip, Size: 6324 bytes --]