postfix.te

postfix.te

[Russell Coker]

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

Where did the recent patch for postfix.te come from?

r_dir_file(postfix_$1_t, cert_t)

The above is added to the macro postfix_domain().  This is a bad idea, we want 
to restrict access to cert_t not allow commands run by unprivileged users 
such as "mailq" to read it.

Do we know which domains actually need this access?

file_type_auto_trans({ sysadm_mail_t system_mail_t postfix_master_t }, etc_t, 
etc_aliases_t)

The above was added within the distro_redhat section.  Do we have a plan to 
change the way the aliases file is managed in FC5 or RHEL5?  
Currently /etc/aliases is read the /etc/postfix/aliases.db is produced as a 
result.  So the above line is not needed (and grants postfix_master_t write 
access to etc_t:dir which is not desired).

# for SSP

The changes to the urandom_device_t access didn't remove the above comment and 
leaves it unattached.

dontaudit postfix_smtpd_t { home_root_t boot_t }:dir getattr;

The above line is added in the section with a comment referring to prng_exch.  
Why is that access needed and what does it have to do with prng_exch?

r_dir_file(postfix_local_t, etc_mail_t)
can_exec(postfix_local_t, bin_t)

These two additions are bad.  Firstly etc_mail_t is defined in sendmail.te.  
There should not be any dependencies between the different mail server .te 
files.

As for the reference to bin_t, I can only guess that it's to execute 
spamassasin when spamassasin.te is not installed (spamassasin has some files 
in /etc/mail).

Is it possible to have the postfix "local" execute spamassasin directly or 
would that be from someone who has spamassasin running from procmail (which 
seems to be the most common way of running spamassasin on a server) and not 
having procmail.te installed?

I suggest the attached patch to fix these issues.

-- 
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: 2239 bytes --]

--- domains/program/postfix.te.orig	2005-09-30 15:17:51.000000000 +1000
+++ domains/program/postfix.te	2005-09-30 15:19:52.000000000 +1000
@@ -54,7 +54,6 @@
 allow postfix_$1_t proc_net_t:dir search;
 allow postfix_$1_t proc_net_t:file { getattr read };
 can_exec(postfix_$1_t, postfix_$1_exec_t)
-r_dir_file(postfix_$1_t, cert_t)
 allow postfix_$1_t { urandom_device_t random_device_t }:chr_file { read getattr };
 
 allow postfix_$1_t tmp_t:dir getattr;
@@ -103,7 +102,6 @@
 can_exec({ sysadm_mail_t system_mail_t }, postfix_master_exec_t)
 ifdef(`distro_redhat', `
 file_type_auto_trans({ sysadm_mail_t system_mail_t postfix_master_t }, postfix_etc_t, etc_aliases_t)
-file_type_auto_trans({ sysadm_mail_t system_mail_t postfix_master_t }, etc_t, etc_aliases_t)
 ', `
 file_type_auto_trans({ sysadm_mail_t system_mail_t }, etc_t, etc_aliases_t)
 ')
@@ -145,8 +143,6 @@
 # for ls to get the current context
 allow postfix_master_t self:file { getattr read };
 
-# for SSP
-
 # allow access to deferred queue and allow removing bogus incoming entries
 allow postfix_master_t postfix_spool_t:dir create_dir_perms;
 allow postfix_master_t postfix_spool_t:file create_file_perms;
@@ -186,7 +182,6 @@
 
 # for prng_exch
 allow postfix_smtpd_t postfix_spool_t:file rw_file_perms;
-dontaudit postfix_smtpd_t { home_root_t boot_t }:dir getattr;
 allow { postfix_smtp_t postfix_smtpd_t } postfix_prng_t:file rw_file_perms;
 
 postfix_server_domain(local, `, mta_delivery_agent')
@@ -198,7 +193,7 @@
 ')
 allow postfix_local_t etc_aliases_t:file r_file_perms;
 allow postfix_local_t self:fifo_file rw_file_perms;
-allow postfix_local_t postfix_local_t:process { setsched setrlimit };
+allow postfix_local_t self:process { setsched setrlimit };
 allow postfix_local_t postfix_spool_t:file rw_file_perms;
 # for .forward - maybe we need a new type for it?
 allow postfix_local_t postfix_private_t:dir search;
@@ -351,8 +346,5 @@
 dontaudit postfix_map_t var_t:dir search;
 can_network_server(postfix_map_t)
 allow postfix_map_t port_type:tcp_socket name_connect;
-r_dir_file(postfix_local_t, etc_mail_t)
 allow postfix_local_t mail_spool_t:dir { remove_name };
 allow postfix_local_t mail_spool_t:file { unlink };
-can_exec(postfix_local_t, bin_t)
-

Re: postfix.te

[Daniel J Walsh]

Russell Coker wrote:

>Where did the recent patch for postfix.te come from?
>
>r_dir_file(postfix_$1_t, cert_t)
>
>The above is added to the macro postfix_domain().  This is a bad idea, we want 
>to restrict access to cert_t not allow commands run by unprivileged users 
>such as "mailq" to read it.
>
>Do we know which domains actually need this access?
>
>file_type_auto_trans({ sysadm_mail_t system_mail_t postfix_master_t }, etc_t, 
>etc_aliases_t)
>
>  
>
>The above was added within the distro_redhat section.  Do we have a plan to 
>change the way the aliases file is managed in FC5 or RHEL5?  
>Currently /etc/aliases is read the /etc/postfix/aliases.db is produced as a 
>result.  So the above line is not needed (and grants postfix_master_t write 
>access to etc_t:dir which is not desired).
>
Not on the machine I was looking at (rawhide), /etc/aliases.db was being 
created. 

# for SSPThe changes to the urandom_device_t access didn't remove the 
above comment and leaves it unattached.

>dontaudit postfix_smtpd_t { home_root_t boot_t }:dir getattr;
>
>The above line is added in the section with a comment referring to prng_exch.  
>Why is that access needed and what does it have to do with prng_exch?
>
>  
>
Because postfix_smtpd_t is trying to getattr on everying thing in / is 
my guess.

>r_dir_file(postfix_local_t, etc_mail_t)
>can_exec(postfix_local_t, bin_t)
>
>These two additions are bad.  Firstly etc_mail_t is defined in sendmail.te.  
>There should not be any dependencies between the different mail server .te 
>files.
>  
>
So etc_mail should be moved to a global file.

>As for the reference to bin_t, I can only guess that it's to execute 
>spamassasin when spamassasin.te is not installed (spamassasin has some files 
>in /etc/mail).
>
>Is it possible to have the postfix "local" execute spamassasin directly or 
>would that be from someone who has spamassasin running from procmail (which 
>seems to be the most common way of running spamassasin on a server) and not 
>having procmail.te installed?
>
>I suggest the attached patch to fix these issues.
>
>  
>
Huh?  So we just allow spamassassin to fail if policy is not installed, 
which it is not in targeted policy.

>------------------------------------------------------------------------
>
>--- domains/program/postfix.te.orig	2005-09-30 15:17:51.000000000 +1000
>+++ domains/program/postfix.te	2005-09-30 15:19:52.000000000 +1000
>@@ -54,7 +54,6 @@
> allow postfix_$1_t proc_net_t:dir search;
> allow postfix_$1_t proc_net_t:file { getattr read };
> can_exec(postfix_$1_t, postfix_$1_exec_t)
>-r_dir_file(postfix_$1_t, cert_t)
> allow postfix_$1_t { urandom_device_t random_device_t }:chr_file { read getattr };
> 
> allow postfix_$1_t tmp_t:dir getattr;
>@@ -103,7 +102,6 @@
> can_exec({ sysadm_mail_t system_mail_t }, postfix_master_exec_t)
> ifdef(`distro_redhat', `
> file_type_auto_trans({ sysadm_mail_t system_mail_t postfix_master_t }, postfix_etc_t, etc_aliases_t)
>-file_type_auto_trans({ sysadm_mail_t system_mail_t postfix_master_t }, etc_t, etc_aliases_t)
> ', `
> file_type_auto_trans({ sysadm_mail_t system_mail_t }, etc_t, etc_aliases_t)
> ')
>@@ -145,8 +143,6 @@
> # for ls to get the current context
> allow postfix_master_t self:file { getattr read };
> 
>-# for SSP
>-
> # allow access to deferred queue and allow removing bogus incoming entries
> allow postfix_master_t postfix_spool_t:dir create_dir_perms;
> allow postfix_master_t postfix_spool_t:file create_file_perms;
>@@ -186,7 +182,6 @@
> 
> # for prng_exch
> allow postfix_smtpd_t postfix_spool_t:file rw_file_perms;
>-dontaudit postfix_smtpd_t { home_root_t boot_t }:dir getattr;
> allow { postfix_smtp_t postfix_smtpd_t } postfix_prng_t:file rw_file_perms;
> 
> postfix_server_domain(local, `, mta_delivery_agent')
>@@ -198,7 +193,7 @@
> ')
> allow postfix_local_t etc_aliases_t:file r_file_perms;
> allow postfix_local_t self:fifo_file rw_file_perms;
>-allow postfix_local_t postfix_local_t:process { setsched setrlimit };
>+allow postfix_local_t self:process { setsched setrlimit };
> allow postfix_local_t postfix_spool_t:file rw_file_perms;
> # for .forward - maybe we need a new type for it?
> allow postfix_local_t postfix_private_t:dir search;
>@@ -351,8 +346,5 @@
> dontaudit postfix_map_t var_t:dir search;
> can_network_server(postfix_map_t)
> allow postfix_map_t port_type:tcp_socket name_connect;
>-r_dir_file(postfix_local_t, etc_mail_t)
> allow postfix_local_t mail_spool_t:dir { remove_name };
> allow postfix_local_t mail_spool_t:file { unlink };
>-can_exec(postfix_local_t, bin_t)
>-
>  
>


-- 



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

[Russell Coker]

On Friday 30 September 2005 21:44, Daniel J Walsh <dwalsh@redhat.com> wrote:
> >The above was added within the distro_redhat section.  Do we have a plan
> > to change the way the aliases file is managed in FC5 or RHEL5?
> >Currently /etc/aliases is read the /etc/postfix/aliases.db is produced as
> > a result.  So the above line is not needed (and grants postfix_master_t
> > write access to etc_t:dir which is not desired).
>
> Not on the machine I was looking at (rawhide), /etc/aliases.db was being
> created.

OK, it looks like the default configuration of the Postfix package has been 
made more similar to other distributions such as Debian in this regard.

> >dontaudit postfix_smtpd_t { home_root_t boot_t }:dir getattr;
> >
> >The above line is added in the section with a comment referring to
> > prng_exch. Why is that access needed and what does it have to do with
> > prng_exch?
>
> Because postfix_smtpd_t is trying to getattr on everying thing in / is
> my guess.

Why would it be doing that?  For so long it's been not doing so on so many 
machines with so many distributions.

> >As for the reference to bin_t, I can only guess that it's to execute
> >spamassasin when spamassasin.te is not installed (spamassasin has some
> > files in /etc/mail).
> >
> >Is it possible to have the postfix "local" execute spamassasin directly or
> >would that be from someone who has spamassasin running from procmail
> > (which seems to be the most common way of running spamassasin on a
> > server) and not having procmail.te installed?
> >
> >I suggest the attached patch to fix these issues.
>
> Huh?  So we just allow spamassassin to fail if policy is not installed,
> which it is not in targeted policy.

We remove the bad policy until we can determine how to write good policy.

Allowing everything is easy, but that diminishes the value of SE Linux.  
Determining what we really need is the hard work.

Who submitted the policy patch in regard to etc_mail_t and bin_t?  We need to 
ask that person why they did it and find out what they were trying to do.  
There is a better way of achieving the same result, but until we know what 
they are trying to do it's not possible.  The questions we need to ask that 
person are:
1)  Are you using procmail for delivery?
2)  If not how are you running spamassasin?

The last thing I want to do is imagine how Postfix might be working, get it 
wrong, and end up writing policy to permit Postfix to do things it can never 
be configured to do!

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

[Daniel J Walsh]

Russell Coker wrote:
> On Friday 30 September 2005 21:44, Daniel J Walsh <dwalsh@redhat.com> wrote:
>   
>>> The above was added within the distro_redhat section.  Do we have a plan
>>> to change the way the aliases file is managed in FC5 or RHEL5?
>>> Currently /etc/aliases is read the /etc/postfix/aliases.db is produced as
>>> a result.  So the above line is not needed (and grants postfix_master_t
>>> write access to etc_t:dir which is not desired).
>>>       
>> Not on the machine I was looking at (rawhide), /etc/aliases.db was being
>> created.
>>     
>
> OK, it looks like the default configuration of the Postfix package has been 
> made more similar to other distributions such as Debian in this regard.
>
>   
>>> dontaudit postfix_smtpd_t { home_root_t boot_t }:dir getattr;
>>>
>>> The above line is added in the section with a comment referring to
>>> prng_exch. Why is that access needed and what does it have to do with
>>> prng_exch?
>>>       
>> Because postfix_smtpd_t is trying to getattr on everying thing in / is
>> my guess.
>>     
>
> Why would it be doing that?  For so long it's been not doing so on so many 
> machines with so many distributions.
>
>   
I don't know.
>>> As for the reference to bin_t, I can only guess that it's to execute
>>> spamassasin when spamassasin.te is not installed (spamassasin has some
>>> files in /etc/mail).
>>>
>>> Is it possible to have the postfix "local" execute spamassasin directly or
>>> would that be from someone who has spamassasin running from procmail
>>> (which seems to be the most common way of running spamassasin on a
>>> server) and not having procmail.te installed?
>>>
>>> I suggest the attached patch to fix these issues.
>>>       
>> Huh?  So we just allow spamassassin to fail if policy is not installed,
>> which it is not in targeted policy.
>>     
>
> We remove the bad policy until we can determine how to write good policy.
>
>   
No We make it work on a customers machine or they turn off selinux, 
never to turn it on again.
Turns out this is not bad policy and does not open up security holes.
> Allowing everything is easy, but that diminishes the value of SE Linux.  
> Determining what we really need is the hard work.
>
>   
Turning off SELinux everywhere diminishes SELinux.
> Who submitted the policy patch in regard to etc_mail_t and bin_t?  We need to 
> ask that person why they did it and find out what they were trying to do.  
> There is a better way of achieving the same result, but until we know what 
> they are trying to do it's not possible.  The questions we need to ask that 
> person are:
> 1)  Are you using procmail for delivery?
> 2)  If not how are you running spamassasin?
>
> The last thing I want to do is imagine how Postfix might be working, get it 
> wrong, and end up writing policy to permit Postfix to do things it can never 
> be configured to do!
>
>   
It is running postfix-script which is executing /bin/sed.

This is standard postfix out of the box, running on steve grubb machine.



-- 



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

[Russell Coker]

On Saturday 01 October 2005 00:03, Daniel J Walsh <dwalsh@redhat.com> wrote:
> >> Huh?  So we just allow spamassassin to fail if policy is not installed,
> >> which it is not in targeted policy.
> >
> > We remove the bad policy until we can determine how to write good policy.
>
> No We make it work on a customers machine or they turn off selinux,
> never to turn it on again.
> Turns out this is not bad policy and does not open up security holes.

The approach of adding allow rules when we don't know what the program is 
doing is not productive.  If we combine that with an extreme reluctance to 
ever remove allow rules then the result is an increasing permission creep 
that is not managable.

> > Who submitted the policy patch in regard to etc_mail_t and bin_t?  We
> > need to ask that person why they did it and find out what they were
> > trying to do. There is a better way of achieving the same result, but
> > until we know what they are trying to do it's not possible.  The
> > questions we need to ask that person are:
> > 1)  Are you using procmail for delivery?
> > 2)  If not how are you running spamassasin?
> >
> > The last thing I want to do is imagine how Postfix might be working, get
> > it wrong, and end up writing policy to permit Postfix to do things it can
> > never be configured to do!
>
> It is running postfix-script which is executing /bin/sed.
>
> This is standard postfix out of the box, running on steve grubb machine.

Running a default config of postfix on a rawhide machine I sent mail to a 
local address and had it delivered without any such access.  The file 
"postfix-script" has the comment "The postfix-script script executes Postfix 
administrative commands in an environment that is set up by the postfix(1) 
command".

Administrative commands shouldn't (and can't) be run from postfix_local_t.  
The normal use of "postfix-script" is to be run when starting postfix.  To 
verify this put "ls -l /tmp" near the start of the script (it doesn't do much 
error checking so that won't affect the operation in any serious way).  You 
will see an audit message similar to the following:

avc:  denied  { read } for  pid=13843 comm="ls" name="/" dev=dm-2 ino=2 
scontext=rjc:system_r:postfix_master_t:s0-s0:c0.c127 
tcontext=system_u:object_r:tmp_t:s0 tclass=dir

To test postfix local delivery I ran "mail rjc" from the command-line where 
"rjc" is a local account.  Mail was delivered to /var/spool/mail/rjc with no 
need for postfix_local_t to access bin_t.  I've tested without sendmail and 
spamassassin installed (with no /etc/mail) and it worked OK, I've tested it 
with them installed and there was no access to /etc/mail by postfix_local_t.

-- 
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.