[refpolicy] Milter Mail Filters

[refpolicy] Milter Mail Filters

[Paul Howarth]

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

Hi,

attached is a patch based on local policy I'm using on Fedora 9 to 
support two "milter" mail filter daemons in conjunction with sendmail, 
namely spamass-milter and milter-regex (I maintain the packages for both 
of these in Fedora).

I've taken the view that most milter applications will have similar 
requirements and so I've created a milter_template interface that 
contains most of what's needed, and then added the specifics that are 
needed on top of the generic stuff for each application.

However, as I'm by no means an selinux expert, there are a number of 
things I'm unsure about:

1. In a situation where sendmail is the running MTA on a system, what is 
the difference between sendmail_t and system_mail_t?

2. MTAs other than sendmail (postfix comes to mind) can also use 
milters, but as I don't have any boxes running postfix, I don't know 
what I'd need to add to postfix policy to support milters.

3. Fedora 9 has an interface spamassassin_domtrans_spamc that I used in 
my local policy. It doesn't appear to be present in refpolicy; what 
would be the right thing to use for a daemon calling spamc?

4. I cribbed the milter_port_t stuff from the only example I could find, 
and it's probably wrong. What would be the correct way of defining this?

5. Does the use of a template for these applications a sane way to do it?

Paul.

[-- Attachment #2: milters.patch --]
[-- Type: text/plain, Size: 7481 bytes --]

Index: policy/modules/services/milters.te
===================================================================
--- policy/modules/services/milters.te	(revision 0)
+++ policy/modules/services/milters.te	(revision 0)
@@ -0,0 +1,44 @@
+policy_module(milters,0.0.7)
+
+require {
+	attribute port_type;
+}
+
+type milter_port_t, port_type;
+
+#============= milter-regex policy ==============
+milter_template(regex)
+
+# Config is in /etc/mail/milter-regex.conf
+mta_read_config(milter_regex_t)
+
+# The milter creates a socket in /var/spool/milter-regex/
+# for communication with sendmail
+files_search_spool(milter_regex_t)
+manage_sock_files_pattern(milter_regex_t,milter_regex_spool_t,milter_regex_spool_t)
+
+# It removes any existing socket (not owned by root) whilst running as root
+# and then calls setgid() and setuid() to drop privileges
+allow milter_regex_t self:capability { setuid setgid dac_override };
+
+
+#============= spamass-milter policy ==============
+milter_template(spamass)
+
+# The milter creates a socket in /var/run/spamass-milter/
+# for communication with sendmail
+manage_files_pattern(milter_spamass_t,milter_spamass_var_run_t,milter_spamass_var_run_t)
+manage_sock_files_pattern(milter_spamass_t,milter_spamass_var_run_t,milter_spamass_var_run_t)
+
+# The main job of the milter is to pipe spam through spamc and act on the result
+#
+# The spamassassin_domtrans_spamc interface in Fedora 9 ???
+#spamassassin_domtrans_spamc(milter_spamass_t)
+
+# When used with -b or -B options, the milter invokes sendmail to send mail
+# to a spamtrap address, using popen()
+corecmd_exec_shell(milter_spamass_t)
+corecmd_read_bin_symlinks(milter_spamass_t)
+corecmd_search_bin(milter_spamass_t)
+kernel_read_system_state(milter_spamass_t)
+mta_send_mail(milter_spamass_t)
Index: policy/modules/services/sendmail.te
===================================================================
--- policy/modules/services/sendmail.te	(revision 2710)
+++ policy/modules/services/sendmail.te	(working copy)
@@ -112,6 +112,14 @@
 ')
 
 optional_policy(`
+	milter_regex_stream_connect(sendmail_t)
+')
+
+optional_policy(`
+	milter_spamass_stream_connect(sendmail_t)
+')
+
+optional_policy(`
 	postfix_exec_master(sendmail_t)
 	postfix_read_config(sendmail_t)
 	postfix_search_spool(sendmail_t)
Index: policy/modules/services/milters.fc
===================================================================
--- policy/modules/services/milters.fc	(revision 0)
+++ policy/modules/services/milters.fc	(revision 0)
@@ -0,0 +1,14 @@
+#================= contexts for milter-regex =================
+
+/usr/sbin/milter-regex		--	gen_context(system_u:object_r:milter_regex_exec_t,s0)
+
+/var/spool/milter-regex(/.*)?		gen_context(system_u:object_r:milter_regex_spool_t,s0)
+
+#================= contexts for spamass-milter =================
+
+/usr/sbin/spamass-milter	--	gen_context(system_u:object_r:milter_spamass_exec_t,s0)
+
+/var/run/spamass-milter\.pid	--	gen_context(system_u:object_r:milter_spamass_var_run_t,s0)
+/var/run/spamass-milter(/.*)?		gen_context(system_u:object_r:milter_spamass_var_run_t,s0)
+
+
Index: policy/modules/services/mta.te
===================================================================
--- policy/modules/services/mta.te	(revision 2710)
+++ policy/modules/services/mta.te	(working copy)
@@ -154,3 +154,7 @@
 		cron_read_system_job_tmp_files(mta_user_agent)
 	')
 ')
+
+optional_policy(`
+	milter_spamass_rw_stream_sockets(system_mail_t)
+')
Index: policy/modules/services/milters.if
===================================================================
--- policy/modules/services/milters.if	(revision 0)
+++ policy/modules/services/milters.if	(revision 0)
@@ -0,0 +1,117 @@
+## <summary>Milter mail filters</summary>
+
+########################################
+## <summary>
+##	Create a set of derived types for various
+##	mail filter applications using the milter interface.
+## </summary>
+## <param name="milter_name">
+##	<summary>
+##	The name to be used for deriving type names.
+##	</summary>
+## </param>
+#
+template(`milter_template',`
+
+	# Type that the milter application runs as
+	type milter_$1_t;
+	domain_type(milter_$1_t)
+	role system_r types milter_$1_t;
+
+	# Type for the executable file
+	type milter_$1_exec_t;
+	init_daemon_domain(milter_$1_t, milter_$1_exec_t)
+
+	# This type is for pidfiles etc.
+	type milter_$1_var_run_t;
+	files_type(milter_$1_var_run_t);
+
+	# This type is for spool/cache data etc.
+	type milter_$1_cache_t;
+	files_type(milter_$1_cache_t);
+
+	# This type is for spool/cache data etc.
+	type milter_$1_spool_t;
+	files_type(milter_$1_spool_t);
+
+	# This type is for state data etc.
+	type milter_$1_var_lib_t;
+	files_type(milter_$1_var_lib_t);
+
+	# Generic rules from policygentool
+	files_read_etc_files(milter_$1_t)
+	libs_use_ld_so(milter_$1_t)
+	libs_use_shared_libs(milter_$1_t)
+	miscfiles_read_localization(milter_$1_t)
+	sysnet_dns_name_resolve(milter_$1_t)
+	init_use_fds(milter_$1_t)
+	init_use_script_ptys(milter_$1_t)
+	domain_use_interactive_fds(milter_$1_t)
+
+	# Allow communication with MTA over a TCP socket
+	# hack since this port has no interfaces since it does not have net_contexts
+	gen_require(`
+		type milter_port_t;
+	')
+	allow milter_$1_t milter_port_t:tcp_socket name_bind;
+	corenet_tcp_bind_generic_node(milter_$1_t)
+	allow milter_$1_t self:tcp_socket { listen accept };
+
+	# Things that most milters will need to do
+	allow milter_$1_t self:fifo_file rw_fifo_file_perms;
+	logging_send_syslog_msg(milter_$1_t)
+
+')
+
+########################################
+## <summary>
+##	MTA communication with spamass-milter socket
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`milter_spamass_stream_connect',`
+	gen_require(`
+		type milter_spamass_var_run_t, milter_spamass_t;
+	')
+	stream_connect_pattern($1,milter_spamass_var_run_t,milter_spamass_var_run_t,milter_spamass_t)
+')
+
+########################################
+## <summary>
+##	Allow read/write unix stream sockets from spamass-milter
+## </summary>
+## <param name="domain">
+##      <summary>
+##      Domain allowed access.
+##      </summary>
+## </param>
+#
+interface(`milter_spamass_rw_stream_sockets',`
+        gen_require(`
+                type milter_spamass_t;
+        ')
+
+	allow $1 milter_spamass_t:unix_stream_socket { read write };
+')
+
+
+########################################
+## <summary>
+##	MTA communication with milter-regex socket
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`milter_regex_stream_connect',`
+	gen_require(`
+		type milter_regex_spool_t, milter_regex_t;
+	')
+	stream_connect_pattern($1,milter_regex_spool_t,milter_regex_spool_t,milter_regex_t)
+')
Index: policy/modules/services/spamassassin.fc
===================================================================
--- policy/modules/services/spamassassin.fc	(revision 2710)
+++ policy/modules/services/spamassassin.fc	(working copy)
@@ -10,7 +10,6 @@
 /var/lib/spamassassin(/.*)?	gen_context(system_u:object_r:spamd_var_lib_t,s0)
 
 /var/run/spamassassin(/.*)?	gen_context(system_u:object_r:spamd_var_run_t,s0)
-/var/run/spamass-milter(/.*)?	gen_context(system_u:object_r:spamd_var_run_t,s0)
 
 /var/spool/spamassassin(/.*)?	gen_context(system_u:object_r:spamd_spool_t,s0)
 /var/spool/spamd(/.*)?		gen_context(system_u:object_r:spamd_spool_t,s0)

Re: [refpolicy] Milter Mail Filters

[Paul Howarth]

Paul Howarth wrote:
> attached is a patch based on local policy I'm using on Fedora 9 to 
> support two "milter" mail filter daemons in conjunction with sendmail, 
> namely spamass-milter and milter-regex (I maintain the packages for both 
> of these in Fedora).
> 
> I've taken the view that most milter applications will have similar 
> requirements and so I've created a milter_template interface that 
> contains most of what's needed, and then added the specifics that are 
> needed on top of the generic stuff for each application.
> 
> However, as I'm by no means an selinux expert, there are a number of 
> things I'm unsure about:
> 
> 1. In a situation where sendmail is the running MTA on a system, what is 
> the difference between sendmail_t and system_mail_t?
> 
> 2. MTAs other than sendmail (postfix comes to mind) can also use 
> milters, but as I don't have any boxes running postfix, I don't know 
> what I'd need to add to postfix policy to support milters.
> 
> 3. Fedora 9 has an interface spamassassin_domtrans_spamc that I used in 
> my local policy. It doesn't appear to be present in refpolicy; what 
> would be the right thing to use for a daemon calling spamc?
> 
> 4. I cribbed the milter_port_t stuff from the only example I could find, 
> and it's probably wrong. What would be the correct way of defining this?
> 
> 5. Does the use of a template for these applications a sane way to do it?

Should I have raised this somewhere else, or in a different way? I've 
had no responses either here or on fedora-selinux-list. The 
spamass-milter is currently broken with SELinux enforcing on Fedora 9 
and I'd like to be able to make at least a little progress towards 
fixing that.

Paul.

--
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: [refpolicy] Milter Mail Filters

[Christopher J. PeBenito]

On Fri, 2008-06-13 at 13:51 +0100, Paul Howarth wrote:
> Paul Howarth wrote:
> > attached is a patch based on local policy I'm using on Fedora 9 to 
> > support two "milter" mail filter daemons in conjunction with sendmail, 
> > namely spamass-milter and milter-regex (I maintain the packages for both 
> > of these in Fedora).
> > 
> > I've taken the view that most milter applications will have similar 
> > requirements and so I've created a milter_template interface that 
> > contains most of what's needed, and then added the specifics that are 
> > needed on top of the generic stuff for each application.
> > 
> > However, as I'm by no means an selinux expert, there are a number of 
> > things I'm unsure about:
> > 
> > 1. In a situation where sendmail is the running MTA on a system, what is 
> > the difference between sendmail_t and system_mail_t?

The former is the server process, the latter is the client.  In the past
sendmail_t was also used in the client sense in too, but we've since
stuck with *_mail_t for clients with few exeptions (which I'd prefer to
fix).

> > 2. MTAs other than sendmail (postfix comes to mind) can also use 
> > milters, but as I don't have any boxes running postfix, I don't know 
> > what I'd need to add to postfix policy to support milters.

My guess would be postfix_local_t, since that is where the procmail
transition is.  Someone more familiar with postfix should confirm.

> > 3. Fedora 9 has an interface spamassassin_domtrans_spamc that I used in 
> > my local policy. It doesn't appear to be present in refpolicy; what 
> > would be the right thing to use for a daemon calling spamc?

There isn't currently a system_spamc_t domain, and adding that along
with appropriate interfaces would likely be the best choice.  Current
policies just execute spamc w/o transition, for example procmail, which
would likely be ok for now.

> > 4. I cribbed the milter_port_t stuff from the only example I could find, 
> > and it's probably wrong. What would be the correct way of defining this?

Adding it to corenetwork.

> > 5. Does the use of a template for these applications a sane way to do it?

Depends.  Based on what I see in your patch, I'd say no.  There are only
a couple rules, and there are a bunch of types declared that don't have
rules.

> Should I have raised this somewhere else, or in a different way? I've 
> had no responses either here or on fedora-selinux-list. The 
> spamass-milter is currently broken with SELinux enforcing on Fedora 9 
> and I'd like to be able to make at least a little progress towards 
> fixing that.

Here is fine.  I can only speak for myself about not responding earlier
of course, but since there was a policy patch I added it to my queue to
review.  There are still items in the queue before 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: [refpolicy] Milter Mail Filters

[Paul Howarth]

On Fri, 13 Jun 2008 10:23:25 -0400
"Christopher J. PeBenito" <cpebenito@tresys.com> wrote:

> On Fri, 2008-06-13 at 13:51 +0100, Paul Howarth wrote:
> > Paul Howarth wrote:
> > > attached is a patch based on local policy I'm using on Fedora 9
> > > to support two "milter" mail filter daemons in conjunction with
> > > sendmail, namely spamass-milter and milter-regex (I maintain the
> > > packages for both of these in Fedora).
> > > 
> > > I've taken the view that most milter applications will have
> > > similar requirements and so I've created a milter_template
> > > interface that contains most of what's needed, and then added the
> > > specifics that are needed on top of the generic stuff for each
> > > application.
> > > 
> > > However, as I'm by no means an selinux expert, there are a number
> > > of things I'm unsure about:
> > > 
> > > 1. In a situation where sendmail is the running MTA on a system,
> > > what is the difference between sendmail_t and system_mail_t?
> 
> The former is the server process, the latter is the client.  In the
> past sendmail_t was also used in the client sense in too, but we've
> since stuck with *_mail_t for clients with few exeptions (which I'd
> prefer to fix).

OK, understood.

> > > 2. MTAs other than sendmail (postfix comes to mind) can also use 
> > > milters, but as I don't have any boxes running postfix, I don't
> > > know what I'd need to add to postfix policy to support milters.
> 
> My guess would be postfix_local_t, since that is where the procmail
> transition is.  Someone more familiar with postfix should confirm.

Not sure about that; that would be local delivery and the milter
communications happen during the SMTP transaction, which would be
earlier in the process.

> > > 3. Fedora 9 has an interface spamassassin_domtrans_spamc that I
> > > used in my local policy. It doesn't appear to be present in
> > > refpolicy; what would be the right thing to use for a daemon
> > > calling spamc?
> 
> There isn't currently a system_spamc_t domain, and adding that
> along with appropriate interfaces would likely be the
> best choice. Current policies just execute spamc w/o transition, for
> example procmail, which would likely be ok for now.

I was happy to find the spamassassin_domtrans_spamc interface in the
Fedora policy as without the domain transition to spamc_t, I'd have had
a lot more rules to add to the milter_spamass policy. Is adding the
system_spamc_t domain likely to be a big job?

> > > 4. I cribbed the milter_port_t stuff from the only example I
> > > could find, and it's probably wrong. What would be the correct
> > > way of defining this?
> 
> Adding it to corenetwork.

Thanks.

> > > 5. Does the use of a template for these applications a sane way
> > > to do it?
> 
> Depends.  Based on what I see in your patch, I'd say no.  There are
> only a couple rules, and there are a bunch of types declared that
> don't have rules.

I could probably combine most of the types into a single type.
Different milters put their sockets in different places and I was
trying to anticipate future requirements whilst sticking with the type
naming conventions for the various subdirectories within /var; I expect
I'd get away with just using something like milter_$1_socket_t and
using that wherever each milter wanted to put its socket, be
it /var/lib/, /var/run/, /var/spool/ etc.

> > Should I have raised this somewhere else, or in a different way?
> > I've had no responses either here or on fedora-selinux-list. The 
> > spamass-milter is currently broken with SELinux enforcing on Fedora
> > 9 and I'd like to be able to make at least a little progress
> > towards fixing that.
> 
> Here is fine.  I can only speak for myself about not responding
> earlier of course, but since there was a policy patch I added it to
> my queue to review.  There are still items in the queue before this :)

Thanks for looking at it. I'll now wait patiently in line, as we Brits
tend to do ;-)

Paul.

--
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: [refpolicy] Milter Mail Filters

[Christopher J. PeBenito]

On Mon, 2008-06-09 at 16:25 +0100, Paul Howarth wrote:
> Hi,
> 
> attached is a patch based on local policy I'm using on Fedora 9 to 
> support two "milter" mail filter daemons in conjunction with
> sendmail, 
> namely spamass-milter and milter-regex (I maintain the packages for
> both 
> of these in Fedora).
> 
> I've taken the view that most milter applications will have similar 
> requirements and so I've created a milter_template interface that 
> contains most of what's needed, and then added the specifics that are 
> needed on top of the generic stuff for each application.
> 
> However, as I'm by no means an selinux expert, there are a number of 
> things I'm unsure about:
> 
> 1. In a situation where sendmail is the running MTA on a system, what
> is 
> the difference between sendmail_t and system_mail_t?
> 
> 2. MTAs other than sendmail (postfix comes to mind) can also use 
> milters, but as I don't have any boxes running postfix, I don't know 
> what I'd need to add to postfix policy to support milters.
> 
> 3. Fedora 9 has an interface spamassassin_domtrans_spamc that I used
> in 
> my local policy. It doesn't appear to be present in refpolicy; what 
> would be the right thing to use for a daemon calling spamc?
> 
> 4. I cribbed the milter_port_t stuff from the only example I could
> find, 
> and it's probably wrong. What would be the correct way of defining
> this?
> 
> 5. Does the use of a template for these applications a sane way to do
> it?
> 
> Paul.
> 
> 
> 
> 
> 
> 
> 
> plain text
> document
> attachment
> (milters.patch)
> 
> Index: policy/modules/services/milters.te
> ===================================================================
> --- policy/modules/services/milters.te  (revision 0)
> +++ policy/modules/services/milters.te  (revision 0)
> @@ -0,0 +1,44 @@
> +policy_module(milters,0.0.7)
> +
> +require {
> +       attribute port_type;
> +}
> +
> +type milter_port_t, port_type;

This declaration would move to corenetwork

> +#============= milter-regex policy ==============
> +milter_template(regex)

As I mentioned before, it doesn't look like a template is needed, unless
you think there will be many more milter domains.  Then put all the
declarations in a section.

> +# Config is in /etc/mail/milter-regex.conf
> +mta_read_config(milter_regex_t)
> +
> +# The milter creates a socket in /var/spool/milter-regex/
> +# for communication with sendmail
> +files_search_spool(milter_regex_t)
> +manage_sock_files_pattern(milter_regex_t,milter_regex_spool_t,milter_regex_spool_t)

If the /var/sool/milter-regex directory can be created by the milter,
then there should be a files_spool_filetrans().  If you think templates
are warranted, then it would seem that this should go into the template

> +
> +# It removes any existing socket (not owned by root) whilst running
> as root
> +# and then calls setgid() and setuid() to drop privileges
> +allow milter_regex_t self:capability { setuid setgid dac_override };
> +
> +
> +#============= spamass-milter policy ==============
> +milter_template(spamass)
> +
> +# The milter creates a socket in /var/run/spamass-milter/
> +# for communication with sendmail
> +manage_files_pattern(milter_spamass_t,milter_spamass_var_run_t,milter_spamass_var_run_t)
> +manage_sock_files_pattern(milter_spamass_t,milter_spamass_var_run_t,milter_spamass_var_run_t)
> +
> +# The main job of the milter is to pipe spam through spamc and act on
> the result
> +#
> +# The spamassassin_domtrans_spamc interface in Fedora 9 ???
> +#spamassassin_domtrans_spamc(milter_spamass_t)
> +
> +# When used with -b or -B options, the milter invokes sendmail to
> send mail
> +# to a spamtrap address, using popen()
> +corecmd_exec_shell(milter_spamass_t)
> +corecmd_read_bin_symlinks(milter_spamass_t)
> +corecmd_search_bin(milter_spamass_t)
> +kernel_read_system_state(milter_spamass_t)
> +mta_send_mail(milter_spamass_t)

Similar comments as the previous domain.

> --- policy/modules/services/sendmail.te (revision 2710)
> +++ policy/modules/services/sendmail.te (working copy)
> @@ -112,6 +112,14 @@
>  ')
>  
>  optional_policy(`
> +       milter_regex_stream_connect(sendmail_t)
> +')
> +
> +optional_policy(`
> +       milter_spamass_stream_connect(sendmail_t)
> +')

Perhaps this should be a single milter_stream_connect_all(), since it
seems like sendmail would want to connect to all milters.


> --- policy/modules/services/milters.fc  (revision 0)
> +++ policy/modules/services/milters.fc  (revision 0)
> @@ -0,0 +1,14 @@
> +#================= contexts for milter-regex =================
> +
> +/usr/sbin/milter-regex         --      gen_context(system_u:object_r:milter_regex_exec_t,s0)
> +
> +/var/spool/milter-regex(/.*)?          gen_context(system_u:object_r:milter_regex_spool_t,s0)
> +
> +#================= contexts for spamass-milter =================
> +
> +/usr/sbin/spamass-milter       --      gen_context(system_u:object_r:milter_spamass_exec_t,s0)
> +
> +/var/run/spamass-milter
> \.pid   --      gen_context(system_u:object_r:milter_spamass_var_run_t,s0)
> +/var/run/spamass-milter(/.*)?          gen_context(system_u:object_r:milter_spamass_var_run_t,s0)

The comments don't really add anything here IMO.


> +template(`milter_template',`
[...]
> +       # This type is for pidfiles etc.
> +       type milter_$1_var_run_t;
> +       files_type(milter_$1_var_run_t);
> +
> +       # This type is for spool/cache data etc.
> +       type milter_$1_cache_t;
> +       files_type(milter_$1_cache_t);
> +
> +       # This type is for spool/cache data etc.
> +       type milter_$1_spool_t;
> +       files_type(milter_$1_spool_t);
> +
> +       # This type is for state data etc.
> +       type milter_$1_var_lib_t;
> +       files_type(milter_$1_var_lib_t);

Most of these types aren't used, so they should be dropped.

> +interface(`milter_spamass_stream_connect',`
> +       gen_require(`
> +               type milter_spamass_var_run_t, milter_spamass_t;
> +       ')
> +       stream_connect_pattern($1,milter_spamass_var_run_t,milter_spamass_var_run_t,milter_spamass_t)
> +')
> +

Missing a files_search_spool().  Interface name needs to be fixed [1].

> +interface(`milter_spamass_rw_stream_sockets',`
> +        gen_require(`
> +                type milter_spamass_t;
> +        ')
> +
> +       allow $1 milter_spamass_t:unix_stream_socket { read write };
> +')

Interface naming fix.


> +interface(`milter_regex_stream_connect',`
> +       gen_require(`
> +               type milter_regex_spool_t, milter_regex_t;
> +       ')
> +       stream_connect_pattern($1,milter_regex_spool_t,milter_regex_spool_t,milter_regex_t)
> +')

Also missing a files_search_spool() and interface naming fix.


[1] http://oss.tresys.com/projects/refpolicy/wiki/InterfaceNaming

-- 
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: [refpolicy] Milter Mail Filters

[Paul Howarth]

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

Christopher J. PeBenito wrote:
> On Mon, 2008-06-09 at 16:25 +0100, Paul Howarth wrote:
>> Hi,
>>
>> attached is a patch based on local policy I'm using on Fedora 9 to 
>> support two "milter" mail filter daemons in conjunction with
>> sendmail, 
>> namely spamass-milter and milter-regex (I maintain the packages for
>> both 
>> of these in Fedora).
>>
>> I've taken the view that most milter applications will have similar 
>> requirements and so I've created a milter_template interface that 
>> contains most of what's needed, and then added the specifics that are 
>> needed on top of the generic stuff for each application.
>>
>> However, as I'm by no means an selinux expert, there are a number of 
>> things I'm unsure about:
>>
>> 1. In a situation where sendmail is the running MTA on a system, what
>> is 
>> the difference between sendmail_t and system_mail_t?
>>
>> 2. MTAs other than sendmail (postfix comes to mind) can also use 
>> milters, but as I don't have any boxes running postfix, I don't know 
>> what I'd need to add to postfix policy to support milters.
>>
>> 3. Fedora 9 has an interface spamassassin_domtrans_spamc that I used
>> in 
>> my local policy. It doesn't appear to be present in refpolicy; what 
>> would be the right thing to use for a daemon calling spamc?
>>
>> 4. I cribbed the milter_port_t stuff from the only example I could
>> find, 
>> and it's probably wrong. What would be the correct way of defining
>> this?
>>
>> 5. Does the use of a template for these applications a sane way to do
>> it?
>>
>> Paul.
>>
>>
>>
>>
>>
>>
>>
>> plain text
>> document
>> attachment
>> (milters.patch)
>>
>> Index: policy/modules/services/milters.te
>> ===================================================================
>> --- policy/modules/services/milters.te  (revision 0)
>> +++ policy/modules/services/milters.te  (revision 0)
>> @@ -0,0 +1,44 @@
>> +policy_module(milters,0.0.7)
>> +
>> +require {
>> +       attribute port_type;
>> +}
>> +
>> +type milter_port_t, port_type;
> 
> This declaration would move to corenetwork

Moved.

>> +#============= milter-regex policy ==============
>> +milter_template(regex)
> 
> As I mentioned before, it doesn't look like a template is needed, unless
> you think there will be many more milter domains.  Then put all the
> declarations in a section.

There are plenty of milters out there - see http://www.milter.org/milters

Not sure what you mean by "put all the declarations in a section". The 
current version has very few declarations anyway now.

>> +# Config is in /etc/mail/milter-regex.conf
>> +mta_read_config(milter_regex_t)
>> +
>> +# The milter creates a socket in /var/spool/milter-regex/
>> +# for communication with sendmail
>> +files_search_spool(milter_regex_t)
>> +manage_sock_files_pattern(milter_regex_t,milter_regex_spool_t,milter_regex_spool_t)
> 
> If the /var/sool/milter-regex directory can be created by the milter,
> then there should be a files_spool_filetrans().  If you think templates
> are warranted, then it would seem that this should go into the template

That directory would be part of the package for the milter and wouldn't 
need to be created at runtime (it needs specific DAC 
permissions/ownership anyway).

>> +# It removes any existing socket (not owned by root) whilst running
>> as root
>> +# and then calls setgid() and setuid() to drop privileges
>> +allow milter_regex_t self:capability { setuid setgid dac_override };
>> +
>> +
>> +#============= spamass-milter policy ==============
>> +milter_template(spamass)
>> +
>> +# The milter creates a socket in /var/run/spamass-milter/
>> +# for communication with sendmail
>> +manage_files_pattern(milter_spamass_t,milter_spamass_var_run_t,milter_spamass_var_run_t)
>> +manage_sock_files_pattern(milter_spamass_t,milter_spamass_var_run_t,milter_spamass_var_run_t)
>> +
>> +# The main job of the milter is to pipe spam through spamc and act on
>> the result
>> +#
>> +# The spamassassin_domtrans_spamc interface in Fedora 9 ???
>> +#spamassassin_domtrans_spamc(milter_spamass_t)

This interface is part of the big patch merge from Fedora. I could split 
out the part needed by spamass-milter as a separate patch if that's helpful.

>> +# When used with -b or -B options, the milter invokes sendmail to
>> send mail
>> +# to a spamtrap address, using popen()
>> +corecmd_exec_shell(milter_spamass_t)
>> +corecmd_read_bin_symlinks(milter_spamass_t)
>> +corecmd_search_bin(milter_spamass_t)
>> +kernel_read_system_state(milter_spamass_t)
>> +mta_send_mail(milter_spamass_t)
> 
> Similar comments as the previous domain.
> 
>> --- policy/modules/services/sendmail.te (revision 2710)
>> +++ policy/modules/services/sendmail.te (working copy)
>> @@ -112,6 +112,14 @@
>>  ')
>>  
>>  optional_policy(`
>> +       milter_regex_stream_connect(sendmail_t)
>> +')
>> +
>> +optional_policy(`
>> +       milter_spamass_stream_connect(sendmail_t)
>> +')
> 
> Perhaps this should be a single milter_stream_connect_all(), since it
> seems like sendmail would want to connect to all milters.

Indeed it does, and postfix too. I'm using typeattributes to achieve 
this now.

>> --- policy/modules/services/milters.fc  (revision 0)
>> +++ policy/modules/services/milters.fc  (revision 0)
>> @@ -0,0 +1,14 @@
>> +#================= contexts for milter-regex =================
>> +
>> +/usr/sbin/milter-regex         --      gen_context(system_u:object_r:milter_regex_exec_t,s0)
>> +
>> +/var/spool/milter-regex(/.*)?          gen_context(system_u:object_r:milter_regex_spool_t,s0)
>> +
>> +#================= contexts for spamass-milter =================
>> +
>> +/usr/sbin/spamass-milter       --      gen_context(system_u:object_r:milter_spamass_exec_t,s0)
>> +
>> +/var/run/spamass-milter
>> \.pid   --      gen_context(system_u:object_r:milter_spamass_var_run_t,s0)
>> +/var/run/spamass-milter(/.*)?          gen_context(system_u:object_r:milter_spamass_var_run_t,s0)
> 
> The comments don't really add anything here IMO.

OK, removed.

>> +template(`milter_template',`
> [...]
>> +       # This type is for pidfiles etc.
>> +       type milter_$1_var_run_t;
>> +       files_type(milter_$1_var_run_t);
>> +
>> +       # This type is for spool/cache data etc.
>> +       type milter_$1_cache_t;
>> +       files_type(milter_$1_cache_t);
>> +
>> +       # This type is for spool/cache data etc.
>> +       type milter_$1_spool_t;
>> +       files_type(milter_$1_spool_t);
>> +
>> +       # This type is for state data etc.
>> +       type milter_$1_var_lib_t;
>> +       files_type(milter_$1_var_lib_t);
> 
> Most of these types aren't used, so they should be dropped.

I've merged most of the types together now.

>> +interface(`milter_spamass_stream_connect',`
>> +       gen_require(`
>> +               type milter_spamass_var_run_t, milter_spamass_t;
>> +       ')
>> +       stream_connect_pattern($1,milter_spamass_var_run_t,milter_spamass_var_run_t,milter_spamass_t)
>> +')
>> +
> 
> Missing a files_search_spool().  Interface name needs to be fixed [1].

I have two interfaces now, common to all milters:

milter_stream_connect
milter_getattr_socket_dir

I'll try claiming that "milter" is an abbreviation of "milters"; any 
suggestions for better predicate names?

>> +interface(`milter_spamass_rw_stream_sockets',`
>> +        gen_require(`
>> +                type milter_spamass_t;
>> +        ')
>> +
>> +       allow $1 milter_spamass_t:unix_stream_socket { read write };
>> +')
> 
> Interface naming fix.
> 
> 
>> +interface(`milter_regex_stream_connect',`
>> +       gen_require(`
>> +               type milter_regex_spool_t, milter_regex_t;
>> +       ')
>> +       stream_connect_pattern($1,milter_regex_spool_t,milter_regex_spool_t,milter_regex_t)
>> +')
> 
> Also missing a files_search_spool() and interface naming fix.

I'm now using milter_$1_data_dir_t in the interface, where this 
directory might live under /var/spool for some milters, /var/run for 
others etc. So I added files_search_spool() in the te file for the 
milter(s) that needed it (only).

Heavily revised patch attached. The individual milter policies are quite 
brief now (and there are plenty more that could be added), which I think 
justifies the template approach. No further changes should need to be 
made to the sendmail and postfix policies to support additional milters 
either.

Paul.

[-- Attachment #2: milters.patch --]
[-- Type: text/plain, Size: 9029 bytes --]

Index: policy/modules/kernel/corenetwork.te.in
===================================================================
--- policy/modules/kernel/corenetwork.te.in	(revision 2770)
+++ policy/modules/kernel/corenetwork.te.in	(working copy)
@@ -119,6 +119,7 @@
 type lrrd_port_t, port_type; dnl network_port(lrrd_port_t) # no defined portcon
 network_port(lmtp, tcp,24,s0, udp,24,s0)
 network_port(mail, tcp,2000,s0)
+type milter_port_t, port_type; dnl network_port(milter) # no defined portcon
 network_port(mmcc, tcp,5050,s0, udp,5050,s0)
 network_port(monopd, tcp,1234,s0)
 network_port(msnp, tcp,1863,s0, udp,1863,s0)
Index: policy/modules/services/milters.te
===================================================================
--- policy/modules/services/milters.te	(revision 0)
+++ policy/modules/services/milters.te	(revision 0)
@@ -0,0 +1,42 @@
+policy_module(milters,0.1.4)
+
+require {
+	attribute port_type;
+}
+
+#============= declarations ================
+
+# attributes common to all milters
+attribute milter_domains;
+attribute milter_socket_directories;
+attribute milter_socket_type;
+
+
+#============= milter-regex policy ==============
+milter_template(regex)
+
+# Config is in /etc/mail/milter-regex.conf
+mta_read_config(milter_regex_t)
+
+# The milter's socket directory lives under /var/spool
+files_search_spool(milter_regex_t)
+
+# It removes any existing socket (not owned by root) whilst running as root
+# and then calls setgid() and setuid() to drop privileges
+allow milter_regex_t self:capability { setuid setgid dac_override };
+
+
+#============= spamass-milter policy ==============
+milter_template(spamass)
+
+# The main job of the milter is to pipe spam through spamc and act on the result
+spamassassin_domtrans_spamc(milter_spamass_t)
+
+# When used with -b or -B options, the milter invokes sendmail to send mail
+# to a spamtrap address, using popen()
+corecmd_exec_shell(milter_spamass_t)
+corecmd_read_bin_symlinks(milter_spamass_t)
+corecmd_search_bin(milter_spamass_t)
+kernel_read_system_state(milter_spamass_t)
+mta_send_mail(milter_spamass_t)
+
Index: policy/modules/services/sendmail.te
===================================================================
--- policy/modules/services/sendmail.te	(revision 2770)
+++ policy/modules/services/sendmail.te	(working copy)
@@ -112,6 +112,10 @@
 ')
 
 optional_policy(`
+	milter_stream_connect(sendmail_t)
+')
+
+optional_policy(`
 	postfix_exec_master(sendmail_t)
 	postfix_read_config(sendmail_t)
 	postfix_search_spool(sendmail_t)
Index: policy/modules/services/milters.fc
===================================================================
--- policy/modules/services/milters.fc	(revision 0)
+++ policy/modules/services/milters.fc	(revision 0)
@@ -0,0 +1,13 @@
+/usr/sbin/milter-regex				--	gen_context(system_u:object_r:milter_regex_exec_t,s0)
+/var/spool/milter-regex				-d	gen_context(system_u:object_r:milter_regex_data_dir_t,s0)
+/var/spool/milter-regex/sock			-s	gen_context(system_u:object_r:milter_regex_socket_t,s0)
+/var/spool/milter-regex/.+				gen_context(system_u:object_r:milter_regex_data_t,s0)
+
+/usr/sbin/spamass-milter			--	gen_context(system_u:object_r:milter_spamass_exec_t,s0)
+/var/run/spamass-milter				-d	gen_context(system_u:object_r:milter_spamass_data_dir_t,s0)
+/var/run/spamass-milter\.pid			--	gen_context(system_u:object_r:milter_spamass_data_t,s0)
+/var/run/spamass-milter/spamass-milter\.sock	-s	gen_context(system_u:object_r:milter_spamass_socket_t,s0)
+/var/run/spamass-milter/.+				gen_context(system_u:object_r:milter_spamass_data_t,s0)
+/var/run/spamass-milter/postfix			-d	gen_context(system_u:object_r:milter_spamass_data_dir_t,s0)
+/var/run/spamass-milter/postfix/sock		-s	gen_context(system_u:object_r:milter_spamass_socket_t,s0)
+
Index: policy/modules/services/mta.te
===================================================================
--- policy/modules/services/mta.te	(revision 2770)
+++ policy/modules/services/mta.te	(working copy)
@@ -105,6 +105,9 @@
 	# postfix needs this for newaliases
 	files_getattr_tmp_dirs(system_mail_t)
 
+	# newaliases runs as system_mail_t when the sendmail initscript does a restart
+	milter_getattr_socket_dir(system_mail_t)
+
 	postfix_exec_master(system_mail_t)
 	postfix_read_config(system_mail_t)
 	postfix_search_spool(system_mail_t)
Index: policy/modules/services/milters.if
===================================================================
--- policy/modules/services/milters.if	(revision 0)
+++ policy/modules/services/milters.if	(revision 0)
@@ -0,0 +1,108 @@
+## <summary>Milter mail filters</summary>
+
+########################################
+## <summary>
+##	Create a set of derived types for various
+##	mail filter applications using the milter interface.
+## </summary>
+## <param name="milter_name">
+##	<summary>
+##	The name to be used for deriving type names.
+##	</summary>
+## </param>
+#
+template(`milter_template',`
+
+	# attributes common to all milters, plus port type for milter TCP sockets
+	gen_require(`
+		attribute milter_socket_directories, milter_socket_type, milter_domains;
+		type milter_port_t;
+	')
+
+	# Type that the milter application runs as
+	type milter_$1_t, milter_domains;
+	domain_type(milter_$1_t)
+	role system_r types milter_$1_t;
+
+	# Type for the executable file
+	type milter_$1_exec_t;
+	init_daemon_domain(milter_$1_t, milter_$1_exec_t)
+
+	# Type for the directory that the unix-domain socket for MTA
+	# communication will live in
+	type milter_$1_data_dir_t, milter_socket_directories;
+	files_type(milter_$1_data_dir_t)
+
+	# Type for the unix-domain socket for MTA communication
+	type milter_$1_socket_t, milter_socket_type;
+	files_type(milter_$1_socket_t);
+	filetrans_pattern(milter_$1_t,milter_$1_data_dir_t,milter_$1_socket_t,sock_file)
+
+	# Any other data the milter puts in a milter_data_dir_t directory
+	type milter_$1_data_t;
+	files_type(milter_$1_data_t);
+	filetrans_pattern(milter_$1_t,milter_$1_data_dir_t,milter_$1_data_t,{ dir file })
+
+	# Generic rules from policygentool
+	files_read_etc_files(milter_$1_t)
+	libs_use_ld_so(milter_$1_t)
+	libs_use_shared_libs(milter_$1_t)
+	miscfiles_read_localization(milter_$1_t)
+	sysnet_dns_name_resolve(milter_$1_t)
+	init_use_fds(milter_$1_t)
+	init_use_script_ptys(milter_$1_t)
+	domain_use_interactive_fds(milter_$1_t)
+
+	# Allow communication with MTA over a TCP socket
+	allow milter_$1_t milter_port_t:tcp_socket name_bind;
+	corenet_tcp_bind_generic_node(milter_$1_t)
+	allow milter_$1_t self:tcp_socket { listen accept };
+
+	# Allow communication with MTA over a unix-domain socket
+	manage_sock_files_pattern(milter_$1_t,milter_$1_data_dir_t,milter_$1_socket_t)
+
+	# Create other data files and directories in the socket directory
+	manage_files_pattern(milter_$1_t,milter_$1_data_dir_t,milter_$1_data_t)
+	manage_files_pattern(milter_$1_t,milter_$1_data_t,milter_$1_data_t)
+
+	# Things that most milters will need to do
+	allow milter_$1_t self:fifo_file rw_fifo_file_perms;
+	logging_send_syslog_msg(milter_$1_t)
+
+')
+
+########################################
+## <summary>
+##	MTA communication with milter sockets
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`milter_stream_connect',`
+	gen_require(`
+		attribute milter_socket_directories, milter_socket_type, milter_domains;
+	')
+	getattr_dirs_pattern($1,milter_socket_directories,milter_socket_directories)
+	stream_connect_pattern($1,milter_socket_directories,milter_socket_type,milter_domains)
+')
+
+########################################
+## <summary>
+##	Allow search of milter socket directory
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`milter_getattr_socket_dir',`
+	gen_require(`
+		attribute milter_socket_directories;
+	')
+	getattr_dirs_pattern($1,milter_socket_directories,milter_socket_directories)
+')
+
Index: policy/modules/services/spamassassin.fc
===================================================================
--- policy/modules/services/spamassassin.fc	(revision 2770)
+++ policy/modules/services/spamassassin.fc	(working copy)
@@ -10,7 +10,6 @@
 /var/lib/spamassassin(/.*)?	gen_context(system_u:object_r:spamd_var_lib_t,s0)
 
 /var/run/spamassassin(/.*)?	gen_context(system_u:object_r:spamd_var_run_t,s0)
-/var/run/spamass-milter(/.*)?	gen_context(system_u:object_r:spamd_var_run_t,s0)
 
 /var/spool/spamassassin(/.*)?	gen_context(system_u:object_r:spamd_spool_t,s0)
 /var/spool/spamd(/.*)?		gen_context(system_u:object_r:spamd_spool_t,s0)
Index: policy/modules/services/postfix.te
===================================================================
--- policy/modules/services/postfix.te	(revision 2770)
+++ policy/modules/services/postfix.te	(working copy)
@@ -530,6 +530,10 @@
 	cyrus_stream_connect(postfix_smtp_t)
 ')
 
+optional_policy(`
+	milter_stream_connect(postfix_smtp_t)
+')
+
 ########################################
 #
 # Postfix smtpd local policy

Re: [refpolicy] Milter Mail Filters

[Christopher J. PeBenito]

On Tue, 2008-08-05 at 11:03 +0100, Paul Howarth wrote:
> Christopher J. PeBenito wrote:
> > On Mon, 2008-06-09 at 16:25 +0100, Paul Howarth wrote:
> >> attached is a patch based on local policy I'm using on Fedora 9 to 
> >> support two "milter" mail filter daemons in conjunction with
> >> sendmail, 
> >> namely spamass-milter and milter-regex (I maintain the packages for
> >> both 
> >> of these in Fedora).
> >>
> >> I've taken the view that most milter applications will have similar 
> >> requirements and so I've created a milter_template interface that 
> >> contains most of what's needed, and then added the specifics that are 
> >> needed on top of the generic stuff for each application.

> >> +#============= milter-regex policy ==============
> >> +milter_template(regex)
> > 
> > As I mentioned before, it doesn't look like a template is needed, unless
> > you think there will be many more milter domains.  Then put all the
> > declarations in a section.
> 
> There are plenty of milters out there - see http://www.milter.org/milters
> 
> Not sure what you mean by "put all the declarations in a section". The 
> current version has very few declarations anyway now.

The style (including the commenting style) needs to match the rest of
refpolicy.  If you're invoking a template like this, it means there are
some declarations.  Other refpolicy modules have calls like this in the
declarations section.

> >> +interface(`milter_spamass_stream_connect',`
> >> +       gen_require(`
> >> +               type milter_spamass_var_run_t, milter_spamass_t;
> >> +       ')
> >> +       stream_connect_pattern($1,milter_spamass_var_run_t,milter_spamass_var_run_t,milter_spamass_t)
> >> +')
> >> +
> > 
> > Missing a files_search_spool().  Interface name needs to be fixed [1].
> 
> I have two interfaces now, common to all milters:
> 
> milter_stream_connect
> milter_getattr_socket_dir
> 
> I'll try claiming that "milter" is an abbreviation of "milters"; any 
> suggestions for better predicate names?

The target domain/object name, eg. milter_stream_connect_regex()

> I'm now using milter_$1_data_dir_t in the interface, where this 
> directory might live under /var/spool for some milters, /var/run for 
> others etc. So I added files_search_spool() in the te file for the 
> milter(s) that needed it (only).

It seems that milter_$1_data_dir_t and milter_$1_socket_t can be merged
into milter_$1_data_t.  They're all objects in the data dir, with
different classes.  The object class differentiation should be
sufficient IMO.

> Heavily revised patch attached. The individual milter policies are quite 
> brief now (and there are plenty more that could be added), which I think 
> justifies the template approach. No further changes should need to be 
> made to the sendmail and postfix policies to support additional milters 
> either.

The main thing that worries me about template usage is too many rules
going into them just for convenience.  We don't want rules that aren't
common to all milters.

> plain text document attachment (milters.patch)
[...]
> --- policy/modules/services/milters.te	(revision 0)
> +++ policy/modules/services/milters.te	(revision 0)
> @@ -0,0 +1,42 @@
> +policy_module(milters,0.1.4)
> +
> +require {
> +	attribute port_type;
> +}

This should be removed.

> +#============= declarations ================

The commenting style needs to be fixed.

[...]
> +interface(`milter_stream_connect',`
> +	gen_require(`
> +		attribute milter_socket_directories, milter_socket_type, milter_domains;
> +	')
> +	getattr_dirs_pattern($1,milter_socket_directories,milter_socket_directories)
> +	stream_connect_pattern($1,milter_socket_directories,milter_socket_type,milter_domains)
> +')

Needs to be named so that it shows that you can connect to all milters:
milter_stream_connect_all()

-- 
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: [refpolicy] Milter Mail Filters

[Paul Howarth]

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

Christopher J. PeBenito wrote:
> On Tue, 2008-08-05 at 11:03 +0100, Paul Howarth wrote:
>> Christopher J. PeBenito wrote:
>>> On Mon, 2008-06-09 at 16:25 +0100, Paul Howarth wrote:
>>>> attached is a patch based on local policy I'm using on Fedora 9 to 
>>>> support two "milter" mail filter daemons in conjunction with
>>>> sendmail, 
>>>> namely spamass-milter and milter-regex (I maintain the packages for
>>>> both 
>>>> of these in Fedora).
>>>>
>>>> I've taken the view that most milter applications will have similar 
>>>> requirements and so I've created a milter_template interface that 
>>>> contains most of what's needed, and then added the specifics that are 
>>>> needed on top of the generic stuff for each application.
> 
>>>> +#============= milter-regex policy ==============
>>>> +milter_template(regex)
>>> As I mentioned before, it doesn't look like a template is needed, unless
>>> you think there will be many more milter domains.  Then put all the
>>> declarations in a section.
>> There are plenty of milters out there - see http://www.milter.org/milters
>>
>> Not sure what you mean by "put all the declarations in a section". The 
>> current version has very few declarations anyway now.
> 
> The style (including the commenting style) needs to match the rest of
> refpolicy.  If you're invoking a template like this, it means there are
> some declarations.  Other refpolicy modules have calls like this in the
> declarations section.

OK, template invocations moved and commenting style revised.

>>>> +interface(`milter_spamass_stream_connect',`
>>>> +       gen_require(`
>>>> +               type milter_spamass_var_run_t, milter_spamass_t;
>>>> +       ')
>>>> +       stream_connect_pattern($1,milter_spamass_var_run_t,milter_spamass_var_run_t,milter_spamass_t)
>>>> +')
>>>> +
>>> Missing a files_search_spool().  Interface name needs to be fixed [1].
>> I have two interfaces now, common to all milters:
>>
>> milter_stream_connect
>> milter_getattr_socket_dir
>>
>> I'll try claiming that "milter" is an abbreviation of "milters"; any 
>> suggestions for better predicate names?
> 
> The target domain/object name, eg. milter_stream_connect_regex()
> 
>> I'm now using milter_$1_data_dir_t in the interface, where this 
>> directory might live under /var/spool for some milters, /var/run for 
>> others etc. So I added files_search_spool() in the te file for the 
>> milter(s) that needed it (only).
> 
> It seems that milter_$1_data_dir_t and milter_$1_socket_t can be merged
> into milter_$1_data_t.  They're all objects in the data dir, with
> different classes.  The object class differentiation should be
> sufficient IMO.

OK, I've done this now. I originally split this up so that if a milter 
wanted to create some other socket other than the one it used to 
communicate with the MTA, then it would get a different context type. Of 
course, if that happens, it's just as easy for the milter-specific 
policy to arrange for a different context type to be used.

>> Heavily revised patch attached. The individual milter policies are quite 
>> brief now (and there are plenty more that could be added), which I think 
>> justifies the template approach. No further changes should need to be 
>> made to the sendmail and postfix policies to support additional milters 
>> either.
> 
> The main thing that worries me about template usage is too many rules
> going into them just for convenience.  We don't want rules that aren't
> common to all milters.

I've removed more of the stuff from policygentool and kept the stuff I 
really think is necessary now.

>> plain text document attachment (milters.patch)
> [...]
>> --- policy/modules/services/milters.te	(revision 0)
>> +++ policy/modules/services/milters.te	(revision 0)
>> @@ -0,0 +1,42 @@
>> +policy_module(milters,0.1.4)
>> +
>> +require {
>> +	attribute port_type;
>> +}
> 
> This should be removed.

Done.

>> +#============= declarations ================
> 
> The commenting style needs to be fixed.

Done.

> [...]
>> +interface(`milter_stream_connect',`
>> +	gen_require(`
>> +		attribute milter_socket_directories, milter_socket_type, milter_domains;
>> +	')
>> +	getattr_dirs_pattern($1,milter_socket_directories,milter_socket_directories)
>> +	stream_connect_pattern($1,milter_socket_directories,milter_socket_type,milter_domains)
>> +')
> 
> Needs to be named so that it shows that you can connect to all milters:
> milter_stream_connect_all()

Done.

Revised patch attached.

Paul.

[-- Attachment #2: milters.patch --]
[-- Type: text/plain, Size: 8182 bytes --]

Index: refpolicy/policy/modules/kernel/corenetwork.te.in
===================================================================
--- refpolicy/policy/modules/kernel/corenetwork.te.in	(revision 2800)
+++ refpolicy/policy/modules/kernel/corenetwork.te.in	(working copy)
@@ -121,6 +121,7 @@
 type lrrd_port_t, port_type; dnl network_port(lrrd_port_t) # no defined portcon
 network_port(lmtp, tcp,24,s0, udp,24,s0)
 network_port(mail, tcp,2000,s0)
+type milter_port_t, port_type; dnl network_port(milter) # no defined portcon
 network_port(mmcc, tcp,5050,s0, udp,5050,s0)
 network_port(monopd, tcp,1234,s0)
 network_port(msnp, tcp,1863,s0, udp,1863,s0)
Index: refpolicy/policy/modules/services/milters.te
===================================================================
--- refpolicy/policy/modules/services/milters.te	(revision 0)
+++ refpolicy/policy/modules/services/milters.te	(revision 0)
@@ -0,0 +1,54 @@
+policy_module(milters,0.2.0)
+
+########################################
+#
+# Declarations
+#
+
+# attributes common to all milters
+attribute milter_domains;
+attribute milter_data_type;
+
+# currently-supported milters are milter-regex and spamass-milter
+milter_template(regex)
+milter_template(spamass)
+
+########################################
+#
+# milter-regex local policy
+#   filter emails using regular expressions
+#   http://www.benzedrine.cx/milter-regex.html
+#
+
+# Look up username for dropping privs
+auth_use_nsswitch(milter_regex_t)
+
+# Config is in /etc/mail/milter-regex.conf
+mta_read_config(milter_regex_t)
+
+# The milter's socket directory lives under /var/spool
+files_search_spool(milter_regex_t)
+
+# It removes any existing socket (not owned by root) whilst running as root
+# and then calls setgid() and setuid() to drop privileges
+allow milter_regex_t self:capability { setuid setgid dac_override };
+
+
+########################################
+#
+# spamass-milter local policy
+#   pipe emails through SpamAssassin
+#   http://savannah.nongnu.org/projects/spamass-milt/
+#
+
+# The main job of the milter is to pipe spam through spamc and act on the result
+spamassassin_domtrans_spamc(milter_spamass_t)
+
+# When used with -b or -B options, the milter invokes sendmail to send mail
+# to a spamtrap address, using popen()
+corecmd_exec_shell(milter_spamass_t)
+corecmd_read_bin_symlinks(milter_spamass_t)
+corecmd_search_bin(milter_spamass_t)
+kernel_read_system_state(milter_spamass_t)
+mta_send_mail(milter_spamass_t)
+
Index: refpolicy/policy/modules/services/sendmail.te
===================================================================
--- refpolicy/policy/modules/services/sendmail.te	(revision 2800)
+++ refpolicy/policy/modules/services/sendmail.te	(working copy)
@@ -112,6 +112,10 @@
 ')
 
 optional_policy(`
+	milter_stream_connect_all(sendmail_t)
+')
+
+optional_policy(`
 	postfix_exec_master(sendmail_t)
 	postfix_read_config(sendmail_t)
 	postfix_search_spool(sendmail_t)
Index: refpolicy/policy/modules/services/milters.fc
===================================================================
--- refpolicy/policy/modules/services/milters.fc	(revision 0)
+++ refpolicy/policy/modules/services/milters.fc	(revision 0)
@@ -0,0 +1,7 @@
+/usr/sbin/milter-regex				--	gen_context(system_u:object_r:milter_regex_exec_t,s0)
+/var/spool/milter-regex(/.*)?				gen_context(system_u:object_r:milter_regex_data_t,s0)
+
+/usr/sbin/spamass-milter			--	gen_context(system_u:object_r:milter_spamass_exec_t,s0)
+/var/run/spamass-milter(/.*)?				gen_context(system_u:object_r:milter_spamass_data_t,s0)
+/var/run/spamass-milter\.pid			--	gen_context(system_u:object_r:milter_spamass_data_t,s0)
+
Index: refpolicy/policy/modules/services/mta.te
===================================================================
--- refpolicy/policy/modules/services/mta.te	(revision 2800)
+++ refpolicy/policy/modules/services/mta.te	(working copy)
@@ -105,6 +105,9 @@
 	# postfix needs this for newaliases
 	files_getattr_tmp_dirs(system_mail_t)
 
+	# newaliases runs as system_mail_t when the sendmail initscript does a restart
+	milter_getattr_all_data_dirs(system_mail_t)
+
 	postfix_exec_master(system_mail_t)
 	postfix_read_config(system_mail_t)
 	postfix_search_spool(system_mail_t)
Index: refpolicy/policy/modules/services/milters.if
===================================================================
--- refpolicy/policy/modules/services/milters.if	(revision 0)
+++ refpolicy/policy/modules/services/milters.if	(revision 0)
@@ -0,0 +1,90 @@
+## <summary>Milter mail filters</summary>
+
+########################################
+## <summary>
+##	Create a set of derived types for various
+##	mail filter applications using the milter interface.
+## </summary>
+## <param name="milter_name">
+##	<summary>
+##	The name to be used for deriving type names.
+##	</summary>
+## </param>
+#
+template(`milter_template',`
+
+	# attributes common to all milters, plus port type for milter TCP sockets
+	gen_require(`
+		attribute milter_data_type, milter_domains;
+		type milter_port_t;
+	')
+
+	# Type that the milter application runs as
+	type milter_$1_t, milter_domains;
+	domain_type(milter_$1_t)
+	role system_r types milter_$1_t;
+
+	# Type for the executable file
+	type milter_$1_exec_t;
+	init_daemon_domain(milter_$1_t, milter_$1_exec_t)
+
+	# Type for the milter data (e.g. the socket used to communicate with the MTA)
+	type milter_$1_data_t, milter_data_type;
+	files_type(milter_$1_data_t);
+
+	# Allow communication with MTA over a TCP socket
+	allow milter_$1_t milter_port_t:tcp_socket name_bind;
+	corenet_tcp_bind_generic_node(milter_$1_t)
+	allow milter_$1_t self:tcp_socket { listen accept };
+
+	# Allow communication with MTA over a unix-domain socket
+	manage_sock_files_pattern(milter_$1_t,milter_$1_data_t,milter_$1_data_t)
+
+	# Create other data files and directories in the data directory
+	manage_files_pattern(milter_$1_t,milter_$1_data_t,milter_$1_data_t)
+
+	# Things that all(?) milters will need to do
+	libs_use_ld_so(milter_$1_t)
+	libs_use_shared_libs(milter_$1_t)
+	miscfiles_read_localization(milter_$1_t)
+	init_use_fds(milter_$1_t)
+	allow milter_$1_t self:fifo_file rw_fifo_file_perms;
+	logging_send_syslog_msg(milter_$1_t)
+
+')
+
+########################################
+## <summary>
+##	MTA communication with milter sockets
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`milter_stream_connect_all',`
+	gen_require(`
+		attribute milter_data_type, milter_domains;
+	')
+	getattr_dirs_pattern($1,milter_data_type,milter_data_type)
+	stream_connect_pattern($1,milter_data_type,milter_data_type,milter_domains)
+')
+
+########################################
+## <summary>
+##	Allow search of milter data directory
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`milter_getattr_all_data_dirs',`
+	gen_require(`
+		attribute milter_data_type;
+	')
+	getattr_dirs_pattern($1,milter_data_type,milter_data_type)
+')
+
Index: refpolicy/policy/modules/services/spamassassin.fc
===================================================================
--- refpolicy/policy/modules/services/spamassassin.fc	(revision 2800)
+++ refpolicy/policy/modules/services/spamassassin.fc	(working copy)
@@ -10,7 +10,6 @@
 /var/lib/spamassassin(/.*)?	gen_context(system_u:object_r:spamd_var_lib_t,s0)
 
 /var/run/spamassassin(/.*)?	gen_context(system_u:object_r:spamd_var_run_t,s0)
-/var/run/spamass-milter(/.*)?	gen_context(system_u:object_r:spamd_var_run_t,s0)
 
 /var/spool/spamassassin(/.*)?	gen_context(system_u:object_r:spamd_spool_t,s0)
 /var/spool/spamd(/.*)?		gen_context(system_u:object_r:spamd_spool_t,s0)
Index: refpolicy/policy/modules/services/postfix.te
===================================================================
--- refpolicy/policy/modules/services/postfix.te	(revision 2800)
+++ refpolicy/policy/modules/services/postfix.te	(working copy)
@@ -530,6 +530,10 @@
 	cyrus_stream_connect(postfix_smtp_t)
 ')
 
+optional_policy(`
+	milter_stream_connect_all(postfix_smtp_t)
+')
+
 ########################################
 #
 # Postfix smtpd local policy

Re: [refpolicy] Milter Mail Filters

[Paul Howarth]

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

Updated patch: sendmail, when run as "newaliases", tries to getattr() 
milter sockets as well as the directories they live in, so I changed the 
milter_getattr_all_data_dirs interface to milter_getattr_all_sockets.

I also moved the call to this interface in mta.te out from the middle of 
a bunch of postfix-related lines.

Paul.

[-- Attachment #2: milters.patch --]
[-- Type: text/x-patch, Size: 8175 bytes --]

Index: refpolicy/policy/modules/kernel/corenetwork.te.in
===================================================================
--- refpolicy/policy/modules/kernel/corenetwork.te.in	(revision 2800)
+++ refpolicy/policy/modules/kernel/corenetwork.te.in	(working copy)
@@ -121,6 +121,7 @@
 type lrrd_port_t, port_type; dnl network_port(lrrd_port_t) # no defined portcon
 network_port(lmtp, tcp,24,s0, udp,24,s0)
 network_port(mail, tcp,2000,s0)
+type milter_port_t, port_type; dnl network_port(milter) # no defined portcon
 network_port(mmcc, tcp,5050,s0, udp,5050,s0)
 network_port(monopd, tcp,1234,s0)
 network_port(msnp, tcp,1863,s0, udp,1863,s0)
Index: refpolicy/policy/modules/services/milters.te
===================================================================
--- refpolicy/policy/modules/services/milters.te	(revision 0)
+++ refpolicy/policy/modules/services/milters.te	(revision 0)
@@ -0,0 +1,54 @@
+policy_module(milters,0.2.0)
+
+########################################
+#
+# Declarations
+#
+
+# attributes common to all milters
+attribute milter_domains;
+attribute milter_data_type;
+
+# currently-supported milters are milter-regex and spamass-milter
+milter_template(regex)
+milter_template(spamass)
+
+########################################
+#
+# milter-regex local policy
+#   filter emails using regular expressions
+#   http://www.benzedrine.cx/milter-regex.html
+#
+
+# Look up username for dropping privs
+auth_use_nsswitch(milter_regex_t)
+
+# Config is in /etc/mail/milter-regex.conf
+mta_read_config(milter_regex_t)
+
+# The milter's socket directory lives under /var/spool
+files_search_spool(milter_regex_t)
+
+# It removes any existing socket (not owned by root) whilst running as root
+# and then calls setgid() and setuid() to drop privileges
+allow milter_regex_t self:capability { setuid setgid dac_override };
+
+
+########################################
+#
+# spamass-milter local policy
+#   pipe emails through SpamAssassin
+#   http://savannah.nongnu.org/projects/spamass-milt/
+#
+
+# The main job of the milter is to pipe spam through spamc and act on the result
+spamassassin_domtrans_spamc(milter_spamass_t)
+
+# When used with -b or -B options, the milter invokes sendmail to send mail
+# to a spamtrap address, using popen()
+corecmd_exec_shell(milter_spamass_t)
+corecmd_read_bin_symlinks(milter_spamass_t)
+corecmd_search_bin(milter_spamass_t)
+kernel_read_system_state(milter_spamass_t)
+mta_send_mail(milter_spamass_t)
+
Index: refpolicy/policy/modules/services/sendmail.te
===================================================================
--- refpolicy/policy/modules/services/sendmail.te	(revision 2800)
+++ refpolicy/policy/modules/services/sendmail.te	(working copy)
@@ -112,6 +112,10 @@
 ')
 
 optional_policy(`
+	milter_stream_connect_all(sendmail_t)
+')
+
+optional_policy(`
 	postfix_exec_master(sendmail_t)
 	postfix_read_config(sendmail_t)
 	postfix_search_spool(sendmail_t)
Index: refpolicy/policy/modules/services/milters.fc
===================================================================
--- refpolicy/policy/modules/services/milters.fc	(revision 0)
+++ refpolicy/policy/modules/services/milters.fc	(revision 0)
@@ -0,0 +1,7 @@
+/usr/sbin/milter-regex				--	gen_context(system_u:object_r:milter_regex_exec_t,s0)
+/var/spool/milter-regex(/.*)?				gen_context(system_u:object_r:milter_regex_data_t,s0)
+
+/usr/sbin/spamass-milter			--	gen_context(system_u:object_r:milter_spamass_exec_t,s0)
+/var/run/spamass-milter(/.*)?				gen_context(system_u:object_r:milter_spamass_data_t,s0)
+/var/run/spamass-milter\.pid			--	gen_context(system_u:object_r:milter_spamass_data_t,s0)
+
Index: refpolicy/policy/modules/services/mta.te
===================================================================
--- refpolicy/policy/modules/services/mta.te	(revision 2800)
+++ refpolicy/policy/modules/services/mta.te	(working copy)
@@ -102,6 +102,9 @@
 
 	domain_use_interactive_fds(system_mail_t)
 
+	# newaliases runs as system_mail_t when the sendmail initscript does a restart
+	milter_getattr_all_sockets(system_mail_t)
+
 	# postfix needs this for newaliases
 	files_getattr_tmp_dirs(system_mail_t)
 
Index: refpolicy/policy/modules/services/milters.if
===================================================================
--- refpolicy/policy/modules/services/milters.if	(revision 0)
+++ refpolicy/policy/modules/services/milters.if	(revision 0)
@@ -0,0 +1,91 @@
+## <summary>Milter mail filters</summary>
+
+########################################
+## <summary>
+##	Create a set of derived types for various
+##	mail filter applications using the milter interface.
+## </summary>
+## <param name="milter_name">
+##	<summary>
+##	The name to be used for deriving type names.
+##	</summary>
+## </param>
+#
+template(`milter_template',`
+
+	# attributes common to all milters, plus port type for milter TCP sockets
+	gen_require(`
+		attribute milter_data_type, milter_domains;
+		type milter_port_t;
+	')
+
+	# Type that the milter application runs as
+	type milter_$1_t, milter_domains;
+	domain_type(milter_$1_t)
+	role system_r types milter_$1_t;
+
+	# Type for the executable file
+	type milter_$1_exec_t;
+	init_daemon_domain(milter_$1_t, milter_$1_exec_t)
+
+	# Type for the milter data (e.g. the socket used to communicate with the MTA)
+	type milter_$1_data_t, milter_data_type;
+	files_type(milter_$1_data_t);
+
+	# Allow communication with MTA over a TCP socket
+	allow milter_$1_t milter_port_t:tcp_socket name_bind;
+	corenet_tcp_bind_generic_node(milter_$1_t)
+	allow milter_$1_t self:tcp_socket { listen accept };
+
+	# Allow communication with MTA over a unix-domain socket
+	manage_sock_files_pattern(milter_$1_t,milter_$1_data_t,milter_$1_data_t)
+
+	# Create other data files and directories in the data directory
+	manage_files_pattern(milter_$1_t,milter_$1_data_t,milter_$1_data_t)
+
+	# Things that all(?) milters will need to do
+	libs_use_ld_so(milter_$1_t)
+	libs_use_shared_libs(milter_$1_t)
+	miscfiles_read_localization(milter_$1_t)
+	init_use_fds(milter_$1_t)
+	allow milter_$1_t self:fifo_file rw_fifo_file_perms;
+	logging_send_syslog_msg(milter_$1_t)
+
+')
+
+########################################
+## <summary>
+##	MTA communication with milter sockets
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`milter_stream_connect_all',`
+	gen_require(`
+		attribute milter_data_type, milter_domains;
+	')
+	getattr_dirs_pattern($1,milter_data_type,milter_data_type)
+	stream_connect_pattern($1,milter_data_type,milter_data_type,milter_domains)
+')
+
+########################################
+## <summary>
+##	Allow getattr of milter sockets
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`milter_getattr_all_sockets',`
+	gen_require(`
+		attribute milter_data_type;
+	')
+	getattr_dirs_pattern($1,milter_data_type,milter_data_type)
+	getattr_sock_files_pattern($1,milter_data_type,milter_data_type)
+')
+
Index: refpolicy/policy/modules/services/spamassassin.fc
===================================================================
--- refpolicy/policy/modules/services/spamassassin.fc	(revision 2800)
+++ refpolicy/policy/modules/services/spamassassin.fc	(working copy)
@@ -10,7 +10,6 @@
 /var/lib/spamassassin(/.*)?	gen_context(system_u:object_r:spamd_var_lib_t,s0)
 
 /var/run/spamassassin(/.*)?	gen_context(system_u:object_r:spamd_var_run_t,s0)
-/var/run/spamass-milter(/.*)?	gen_context(system_u:object_r:spamd_var_run_t,s0)
 
 /var/spool/spamassassin(/.*)?	gen_context(system_u:object_r:spamd_spool_t,s0)
 /var/spool/spamd(/.*)?		gen_context(system_u:object_r:spamd_spool_t,s0)
Index: refpolicy/policy/modules/services/postfix.te
===================================================================
--- refpolicy/policy/modules/services/postfix.te	(revision 2800)
+++ refpolicy/policy/modules/services/postfix.te	(working copy)
@@ -530,6 +530,10 @@
 	cyrus_stream_connect(postfix_smtp_t)
 ')
 
+optional_policy(`
+	milter_stream_connect_all(postfix_smtp_t)
+')
+
 ########################################
 #
 # Postfix smtpd local policy

Re: [refpolicy] Milter Mail Filters

[Christopher J. PeBenito]

On Mon, 2008-09-22 at 13:27 +0100, Paul Howarth wrote:
> Updated patch: sendmail, when run as "newaliases", tries to getattr() 
> milter sockets as well as the directories they live in, so I changed
> the 
> milter_getattr_all_data_dirs interface to milter_getattr_all_sockets.
> 
> I also moved the call to this interface in mta.te out from the middle
> of 
> a bunch of postfix-related lines.
> 
> Paul.

I think my last two comments are

* you can't require milter_port_t.  It doesn't seem like a generic port
type would be useful anyway, otherwise there would be a port defined.

* milter vs milters inconsistency of naming

* derived types should have the prefix first, eg, $1_milter_t not
milter_$1_t.

> 
> 
> 
> 
> 
> 
> differences
> between files
> attachment
> (milters.patch)
> 
> Index: refpolicy/policy/modules/kernel/corenetwork.te.in
> ===================================================================
> --- refpolicy/policy/modules/kernel/corenetwork.te.in   (revision
> 2800)
> +++ refpolicy/policy/modules/kernel/corenetwork.te.in   (working copy)
> @@ -121,6 +121,7 @@
>  type lrrd_port_t, port_type; dnl network_port(lrrd_port_t) # no
> defined portcon
>  network_port(lmtp, tcp,24,s0, udp,24,s0)
>  network_port(mail, tcp,2000,s0)
> +type milter_port_t, port_type; dnl network_port(milter) # no defined
> portcon
>  network_port(mmcc, tcp,5050,s0, udp,5050,s0)
>  network_port(monopd, tcp,1234,s0)
>  network_port(msnp, tcp,1863,s0, udp,1863,s0)
> Index: refpolicy/policy/modules/services/milters.te
> ===================================================================
> --- refpolicy/policy/modules/services/milters.te        (revision 0)
> +++ refpolicy/policy/modules/services/milters.te        (revision 0)
> @@ -0,0 +1,54 @@
> +policy_module(milters,0.2.0)
> +
> +########################################
> +#
> +# Declarations
> +#
> +
> +# attributes common to all milters
> +attribute milter_domains;
> +attribute milter_data_type;
> +
> +# currently-supported milters are milter-regex and spamass-milter
> +milter_template(regex)
> +milter_template(spamass)
> +
> +########################################
> +#
> +# milter-regex local policy
> +#   filter emails using regular expressions
> +#   http://www.benzedrine.cx/milter-regex.html
> +#
> +
> +# Look up username for dropping privs
> +auth_use_nsswitch(milter_regex_t)
> +
> +# Config is in /etc/mail/milter-regex.conf
> +mta_read_config(milter_regex_t)
> +
> +# The milter's socket directory lives under /var/spool
> +files_search_spool(milter_regex_t)
> +
> +# It removes any existing socket (not owned by root) whilst running
> as root
> +# and then calls setgid() and setuid() to drop privileges
> +allow milter_regex_t self:capability { setuid setgid dac_override };
> +
> +
> +########################################
> +#
> +# spamass-milter local policy
> +#   pipe emails through SpamAssassin
> +#   http://savannah.nongnu.org/projects/spamass-milt/
> +#
> +
> +# The main job of the milter is to pipe spam through spamc and act on
> the result
> +spamassassin_domtrans_spamc(milter_spamass_t)
> +
> +# When used with -b or -B options, the milter invokes sendmail to
> send mail
> +# to a spamtrap address, using popen()
> +corecmd_exec_shell(milter_spamass_t)
> +corecmd_read_bin_symlinks(milter_spamass_t)
> +corecmd_search_bin(milter_spamass_t)
> +kernel_read_system_state(milter_spamass_t)
> +mta_send_mail(milter_spamass_t)
> +
> Index: refpolicy/policy/modules/services/sendmail.te
> ===================================================================
> --- refpolicy/policy/modules/services/sendmail.te       (revision
> 2800)
> +++ refpolicy/policy/modules/services/sendmail.te       (working copy)
> @@ -112,6 +112,10 @@
>  ')
>  
>  optional_policy(`
> +       milter_stream_connect_all(sendmail_t)
> +')
> +
> +optional_policy(`
>         postfix_exec_master(sendmail_t)
>         postfix_read_config(sendmail_t)
>         postfix_search_spool(sendmail_t)
> Index: refpolicy/policy/modules/services/milters.fc
> ===================================================================
> --- refpolicy/policy/modules/services/milters.fc        (revision 0)
> +++ refpolicy/policy/modules/services/milters.fc        (revision 0)
> @@ -0,0 +1,7 @@
> +/usr/sbin/milter-regex                         --      gen_context(system_u:object_r:milter_regex_exec_t,s0)
> +/var/spool/milter-regex(/.*)?                          gen_context(system_u:object_r:milter_regex_data_t,s0)
> +
> +/usr/sbin/spamass-milter                       --      gen_context(system_u:object_r:milter_spamass_exec_t,s0)
> +/var/run/spamass-milter(/.*)?                          gen_context(system_u:object_r:milter_spamass_data_t,s0)
> +/var/run/spamass-milter
> \.pid                   --      gen_context(system_u:object_r:milter_spamass_data_t,s0)
> +
> Index: refpolicy/policy/modules/services/mta.te
> ===================================================================
> --- refpolicy/policy/modules/services/mta.te    (revision 2800)
> +++ refpolicy/policy/modules/services/mta.te    (working copy)
> @@ -102,6 +102,9 @@
>  
>         domain_use_interactive_fds(system_mail_t)
>  
> +       # newaliases runs as system_mail_t when the sendmail
> initscript does a restart
> +       milter_getattr_all_sockets(system_mail_t)
> +
>         # postfix needs this for newaliases
>         files_getattr_tmp_dirs(system_mail_t)
>  
> Index: refpolicy/policy/modules/services/milters.if
> ===================================================================
> --- refpolicy/policy/modules/services/milters.if        (revision 0)
> +++ refpolicy/policy/modules/services/milters.if        (revision 0)
> @@ -0,0 +1,91 @@
> +## <summary>Milter mail filters</summary>
> +
> +########################################
> +## <summary>
> +##     Create a set of derived types for various
> +##     mail filter applications using the milter interface.
> +## </summary>
> +## <param name="milter_name">
> +##     <summary>
> +##     The name to be used for deriving type names.
> +##     </summary>
> +## </param>
> +#
> +template(`milter_template',`
> +
> +       # attributes common to all milters, plus port type for milter
> TCP sockets
> +       gen_require(`
> +               attribute milter_data_type, milter_domains;
> +               type milter_port_t;
> +       ')
> +
> +       # Type that the milter application runs as
> +       type milter_$1_t, milter_domains;
> +       domain_type(milter_$1_t)
> +       role system_r types milter_$1_t;
> +
> +       # Type for the executable file
> +       type milter_$1_exec_t;
> +       init_daemon_domain(milter_$1_t, milter_$1_exec_t)
> +
> +       # Type for the milter data (e.g. the socket used to
> communicate with the MTA)
> +       type milter_$1_data_t, milter_data_type;
> +       files_type(milter_$1_data_t);
> +
> +       # Allow communication with MTA over a TCP socket
> +       allow milter_$1_t milter_port_t:tcp_socket name_bind;
> +       corenet_tcp_bind_generic_node(milter_$1_t)
> +       allow milter_$1_t self:tcp_socket { listen accept };
> +
> +       # Allow communication with MTA over a unix-domain socket
> +       manage_sock_files_pattern(milter_$1_t,milter_$1_data_t,milter_
> $1_data_t)
> +
> +       # Create other data files and directories in the data
> directory
> +       manage_files_pattern(milter_$1_t,milter_$1_data_t,milter_
> $1_data_t)
> +
> +       # Things that all(?) milters will need to do
> +       libs_use_ld_so(milter_$1_t)
> +       libs_use_shared_libs(milter_$1_t)
> +       miscfiles_read_localization(milter_$1_t)
> +       init_use_fds(milter_$1_t)
> +       allow milter_$1_t self:fifo_file rw_fifo_file_perms;
> +       logging_send_syslog_msg(milter_$1_t)
> +
> +')
> +
> +########################################
> +## <summary>
> +##     MTA communication with milter sockets
> +## </summary>
> +## <param name="domain">
> +##     <summary>
> +##     Domain allowed access.
> +##     </summary>
> +## </param>
> +#
> +interface(`milter_stream_connect_all',`
> +       gen_require(`
> +               attribute milter_data_type, milter_domains;
> +       ')
> +       getattr_dirs_pattern($1,milter_data_type,milter_data_type)
> +       stream_connect_pattern($1,milter_data_type,milter_data_type,milter_domains)
> +')
> +
> +########################################
> +## <summary>
> +##     Allow getattr of milter sockets
> +## </summary>
> +## <param name="domain">
> +##     <summary>
> +##     Domain allowed access.
> +##     </summary>
> +## </param>
> +#
> +interface(`milter_getattr_all_sockets',`
> +       gen_require(`
> +               attribute milter_data_type;
> +       ')
> +       getattr_dirs_pattern($1,milter_data_type,milter_data_type)
> +       getattr_sock_files_pattern($1,milter_data_type,milter_data_type)
> +')
> +
> Index: refpolicy/policy/modules/services/spamassassin.fc
> ===================================================================
> --- refpolicy/policy/modules/services/spamassassin.fc   (revision
> 2800)
> +++ refpolicy/policy/modules/services/spamassassin.fc   (working copy)
> @@ -10,7 +10,6 @@
>  /var/lib/spamassassin(/.*)?    gen_context(system_u:object_r:spamd_var_lib_t,s0)
>  
>  /var/run/spamassassin(/.*)?    gen_context(system_u:object_r:spamd_var_run_t,s0)
> -/var/run/spamass-milter(/.*)?  gen_context(system_u:object_r:spamd_var_run_t,s0)
>  
>  /var/spool/spamassassin(/.*)?  gen_context(system_u:object_r:spamd_spool_t,s0)
>  /var/spool/spamd(/.*)?         gen_context(system_u:object_r:spamd_spool_t,s0)
> Index: refpolicy/policy/modules/services/postfix.te
> ===================================================================
> --- refpolicy/policy/modules/services/postfix.te        (revision
> 2800)
> +++ refpolicy/policy/modules/services/postfix.te        (working copy)
> @@ -530,6 +530,10 @@
>         cyrus_stream_connect(postfix_smtp_t)
>  ')
>  
> +optional_policy(`
> +       milter_stream_connect_all(postfix_smtp_t)
> +')
> +
>  ########################################
>  #
>  # Postfix smtpd local policy
> 
-- 
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: [refpolicy] Milter Mail Filters

[Paul Howarth]

Christopher J. PeBenito wrote:
> On Mon, 2008-09-22 at 13:27 +0100, Paul Howarth wrote:
>> Updated patch: sendmail, when run as "newaliases", tries to getattr() 
>> milter sockets as well as the directories they live in, so I changed
>> the 
>> milter_getattr_all_data_dirs interface to milter_getattr_all_sockets.
>>
>> I also moved the call to this interface in mta.te out from the middle
>> of 
>> a bunch of postfix-related lines.
>>
>> Paul.
> 
> I think my last two comments are
> 
> * you can't require milter_port_t.  It doesn't seem like a generic port
> type would be useful anyway, otherwise there would be a port defined.

So I should change "allow milter_$1_t milter_port_t:tcp_socket 
name_bind;" to "corenet_tcp_bind_generic_port($1_milter_t)"?

I can do that but I don't understand why milter_port_t should be any 
different than say stunnel_port_t, which also doesn't have a default 
port defined, and would be used in a similar way, i.e. an admin would 
set up an application to use a specific port (a milter running over tcp 
needs to have a port specified, just a tunnel set up using stunnel does 
- they don't just bind to random generic ports).

> * milter vs milters inconsistency of naming

I'll rename the module and the file to milter then, though I'd hoped 
that "milter" would have been accepted as an abbreviation of "milters".

> * derived types should have the prefix first, eg, $1_milter_t not
> milter_$1_t.

I'll change those.

Paul.


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

[refpolicy] Milter Mail Filters

[Christopher J. PeBenito]

Moving to refpolicy list.

On Wed, 2008-10-08 at 14:05 +0100, Paul Howarth wrote:
> Christopher J. PeBenito wrote:
> > On Mon, 2008-09-22 at 13:27 +0100, Paul Howarth wrote:
> >> Updated patch: sendmail, when run as "newaliases", tries to getattr() 
> >> milter sockets as well as the directories they live in, so I changed
> >> the 
> >> milter_getattr_all_data_dirs interface to milter_getattr_all_sockets.
> >>
> >> I also moved the call to this interface in mta.te out from the middle
> >> of 
> >> a bunch of postfix-related lines.
> >>
> >> Paul.
> > 
> > I think my last two comments are
> > 
> > * you can't require milter_port_t.  It doesn't seem like a generic port
> > type would be useful anyway, otherwise there would be a port defined.
> 
> So I should change "allow milter_$1_t milter_port_t:tcp_socket 
> name_bind;" to "corenet_tcp_bind_generic_port($1_milter_t)"?

No.  I don't see how it makes sense to have a port type common to all
milters.

> I can do that but I don't understand why milter_port_t should be any 
> different than say stunnel_port_t, which also doesn't have a default 
> port defined, and would be used in a similar way, i.e. an admin would 
> set up an application to use a specific port (a milter running over tcp 
> needs to have a port specified, just a tunnel set up using stunnel does 
> - they don't just bind to random generic ports).

This is not comparable, as there is only one stunnel domain, whereas
there are several milter domains.

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

[refpolicy] Milter Mail Filters

[Paul Howarth]

On Wed, 8 Oct 2008 15:22:25 -0400
"Christopher J. PeBenito" <cpebenito@tresys.com> wrote:

> Moving to refpolicy list.
> 
> On Wed, 2008-10-08 at 14:05 +0100, Paul Howarth wrote:
> > Christopher J. PeBenito wrote:
> > > On Mon, 2008-09-22 at 13:27 +0100, Paul Howarth wrote:
> > >> Updated patch: sendmail, when run as "newaliases", tries to
> > >> getattr() milter sockets as well as the directories they live
> > >> in, so I changed the 
> > >> milter_getattr_all_data_dirs interface to
> > >> milter_getattr_all_sockets.
> > >>
> > >> I also moved the call to this interface in mta.te out from the
> > >> middle of 
> > >> a bunch of postfix-related lines.
> > >>
> > >> Paul.
> > > 
> > > I think my last two comments are
> > > 
> > > * you can't require milter_port_t.  It doesn't seem like a
> > > generic port type would be useful anyway, otherwise there would
> > > be a port defined.
> > 
> > So I should change "allow milter_$1_t milter_port_t:tcp_socket 
> > name_bind;" to "corenet_tcp_bind_generic_port($1_milter_t)"?
> 
> No.  I don't see how it makes sense to have a port type common to all
> milters.
> 
> > I can do that but I don't understand why milter_port_t should be
> > any different than say stunnel_port_t, which also doesn't have a
> > default port defined, and would be used in a similar way, i.e. an
> > admin would set up an application to use a specific port (a milter
> > running over tcp needs to have a port specified, just a tunnel set
> > up using stunnel does 
> > - they don't just bind to random generic ports).
> 
> This is not comparable, as there is only one stunnel domain, whereas
> there are several milter domains.

OK, I get that now, I'll use $1_milter_port_t instead then. But the 
question then arises: how to interface to it? You say I can't require 
milter_port_t and I guess that applies to $1_milter_port_t too.
However, as there are no defined ports for these types, there's no
expansion of network_port() for these types from corenetwork.te.in and
hence no corenet_tcp_bind_$1_milter_port interface for me to call. I
got the "require milter_port_t" idea from a similar structure in the
stunnel policy.

How to proceed with this?

Paul.

[refpolicy] Milter Mail Filters

[Christopher J. PeBenito]

On Fri, 2008-10-10 at 19:24 +0100, Paul Howarth wrote:
> On Wed, 8 Oct 2008 15:22:25 -0400
> "Christopher J. PeBenito" <cpebenito@tresys.com> wrote:
> 
> > Moving to refpolicy list.
> > 
> > On Wed, 2008-10-08 at 14:05 +0100, Paul Howarth wrote:
> > > Christopher J. PeBenito wrote:
> > > > On Mon, 2008-09-22 at 13:27 +0100, Paul Howarth wrote:
> > > >> Updated patch: sendmail, when run as "newaliases", tries to
> > > >> getattr() milter sockets as well as the directories they live
> > > >> in, so I changed the 
> > > >> milter_getattr_all_data_dirs interface to
> > > >> milter_getattr_all_sockets.
> > > >>
> > > >> I also moved the call to this interface in mta.te out from the
> > > >> middle of 
> > > >> a bunch of postfix-related lines.
> > > >>
> > > >> Paul.
> > > > 
> > > > I think my last two comments are
> > > > 
> > > > * you can't require milter_port_t.  It doesn't seem like a
> > > > generic port type would be useful anyway, otherwise there would
> > > > be a port defined.
> > > 
> > > So I should change "allow milter_$1_t milter_port_t:tcp_socket 
> > > name_bind;" to "corenet_tcp_bind_generic_port($1_milter_t)"?
> > 
> > No.  I don't see how it makes sense to have a port type common to all
> > milters.
> > 
> > > I can do that but I don't understand why milter_port_t should be
> > > any different than say stunnel_port_t, which also doesn't have a
> > > default port defined, and would be used in a similar way, i.e. an
> > > admin would set up an application to use a specific port (a milter
> > > running over tcp needs to have a port specified, just a tunnel set
> > > up using stunnel does 
> > > - they don't just bind to random generic ports).
> > 
> > This is not comparable, as there is only one stunnel domain, whereas
> > there are several milter domains.
> 
> OK, I get that now, I'll use $1_milter_port_t instead then. But the 
> question then arises: how to interface to it? You say I can't require 
> milter_port_t and I guess that applies to $1_milter_port_t too.
> However, as there are no defined ports for these types, there's no
> expansion of network_port() for these types from corenetwork.te.in and
> hence no corenet_tcp_bind_$1_milter_port interface for me to call. I
> got the "require milter_port_t" idea from a similar structure in the
> stunnel policy.
> 
> How to proceed with this?

Sorry for the slow response; I've been consumed with the UBAC stuff.

I'd say don't declare the port in the template and we'll add ports as
milters require them.

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

[refpolicy] Milter Mail Filters

[Paul Howarth]

Christopher J. PeBenito wrote:
> On Fri, 2008-10-10 at 19:24 +0100, Paul Howarth wrote:
>> On Wed, 8 Oct 2008 15:22:25 -0400
>> "Christopher J. PeBenito" <cpebenito@tresys.com> wrote:
>>
>>> Moving to refpolicy list.
>>>
>>> On Wed, 2008-10-08 at 14:05 +0100, Paul Howarth wrote:
>>>> Christopher J. PeBenito wrote:
>>>>> On Mon, 2008-09-22 at 13:27 +0100, Paul Howarth wrote:
>>>>>> Updated patch: sendmail, when run as "newaliases", tries to
>>>>>> getattr() milter sockets as well as the directories they live
>>>>>> in, so I changed the 
>>>>>> milter_getattr_all_data_dirs interface to
>>>>>> milter_getattr_all_sockets.
>>>>>>
>>>>>> I also moved the call to this interface in mta.te out from the
>>>>>> middle of 
>>>>>> a bunch of postfix-related lines.
>>>>>>
>>>>>> Paul.
>>>>> I think my last two comments are
>>>>>
>>>>> * you can't require milter_port_t.  It doesn't seem like a
>>>>> generic port type would be useful anyway, otherwise there would
>>>>> be a port defined.
>>>> So I should change "allow milter_$1_t milter_port_t:tcp_socket 
>>>> name_bind;" to "corenet_tcp_bind_generic_port($1_milter_t)"?
>>> No.  I don't see how it makes sense to have a port type common to all
>>> milters.
>>>
>>>> I can do that but I don't understand why milter_port_t should be
>>>> any different than say stunnel_port_t, which also doesn't have a
>>>> default port defined, and would be used in a similar way, i.e. an
>>>> admin would set up an application to use a specific port (a milter
>>>> running over tcp needs to have a port specified, just a tunnel set
>>>> up using stunnel does 
>>>> - they don't just bind to random generic ports).
>>> This is not comparable, as there is only one stunnel domain, whereas
>>> there are several milter domains.
>> OK, I get that now, I'll use $1_milter_port_t instead then. But the 
>> question then arises: how to interface to it? You say I can't require 
>> milter_port_t and I guess that applies to $1_milter_port_t too.
>> However, as there are no defined ports for these types, there's no
>> expansion of network_port() for these types from corenetwork.te.in and
>> hence no corenet_tcp_bind_$1_milter_port interface for me to call. I
>> got the "require milter_port_t" idea from a similar structure in the
>> stunnel policy.
>>
>> How to proceed with this?
> 
> Sorry for the slow response; I've been consumed with the UBAC stuff.
> 
> I'd say don't declare the port in the template and we'll add ports as
> milters require them.

It's not a case of one milter needing it and another not needing it; 
potentially any milter can be used in conjunction with TCP ports. The 
usual convention is to use a unix domain socket for communication 
between a milter and the MTA but the milter library supports both 
approaches, and some sysadmins may wish to configure their milters to 
use TCP sockets, so that for instance they can run the milters on 
separate hosts from the MTA in order to spread load. When they do this, 
each milter will need support in policy, which is why I included it in 
the template.

Paul.

[refpolicy] Milter Mail Filters

[Christopher J. PeBenito]

On Thu, 2008-11-06 at 15:24 +0000, Paul Howarth wrote:
> Christopher J. PeBenito wrote:
> > On Fri, 2008-10-10 at 19:24 +0100, Paul Howarth wrote:
> >> On Wed, 8 Oct 2008 15:22:25 -0400
> >> "Christopher J. PeBenito" <cpebenito@tresys.com> wrote:
> >>
> >>> Moving to refpolicy list.
> >>>
> >>> On Wed, 2008-10-08 at 14:05 +0100, Paul Howarth wrote:
> >>>> Christopher J. PeBenito wrote:
> >>>>> On Mon, 2008-09-22 at 13:27 +0100, Paul Howarth wrote:
> >>>>>> Updated patch: sendmail, when run as "newaliases", tries to
> >>>>>> getattr() milter sockets as well as the directories they live
> >>>>>> in, so I changed the 
> >>>>>> milter_getattr_all_data_dirs interface to
> >>>>>> milter_getattr_all_sockets.
> >>>>>>
> >>>>>> I also moved the call to this interface in mta.te out from the
> >>>>>> middle of 
> >>>>>> a bunch of postfix-related lines.
> >>>>>>
> >>>>>> Paul.
> >>>>> I think my last two comments are
> >>>>>
> >>>>> * you can't require milter_port_t.  It doesn't seem like a
> >>>>> generic port type would be useful anyway, otherwise there would
> >>>>> be a port defined.
> >>>> So I should change "allow milter_$1_t milter_port_t:tcp_socket 
> >>>> name_bind;" to "corenet_tcp_bind_generic_port($1_milter_t)"?
> >>> No.  I don't see how it makes sense to have a port type common to all
> >>> milters.
> >>>
> >>>> I can do that but I don't understand why milter_port_t should be
> >>>> any different than say stunnel_port_t, which also doesn't have a
> >>>> default port defined, and would be used in a similar way, i.e. an
> >>>> admin would set up an application to use a specific port (a milter
> >>>> running over tcp needs to have a port specified, just a tunnel set
> >>>> up using stunnel does 
> >>>> - they don't just bind to random generic ports).
> >>> This is not comparable, as there is only one stunnel domain, whereas
> >>> there are several milter domains.
> >> OK, I get that now, I'll use $1_milter_port_t instead then. But the 
> >> question then arises: how to interface to it? You say I can't require 
> >> milter_port_t and I guess that applies to $1_milter_port_t too.
> >> However, as there are no defined ports for these types, there's no
> >> expansion of network_port() for these types from corenetwork.te.in and
> >> hence no corenet_tcp_bind_$1_milter_port interface for me to call. I
> >> got the "require milter_port_t" idea from a similar structure in the
> >> stunnel policy.
> >>
> >> How to proceed with this?
> > 
> > Sorry for the slow response; I've been consumed with the UBAC stuff.
> > 
> > I'd say don't declare the port in the template and we'll add ports as
> > milters require them.
> 
> It's not a case of one milter needing it and another not needing it; 
> potentially any milter can be used in conjunction with TCP ports. The 
> usual convention is to use a unix domain socket for communication 
> between a milter and the MTA but the milter library supports both 
> approaches, and some sysadmins may wish to configure their milters to 
> use TCP sockets, so that for instance they can run the milters on 
> separate hosts from the MTA in order to spread load. When they do this, 
> each milter will need support in policy, which is why I included it in 
> the template.

We can't realistically support all possible configurations.  At some
point we have to draw the line on trying.  I think the standard
configuration that covers 80%+ of the users is a reasonable starting
point.

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

[refpolicy] Milter Mail Filters

[Paul Howarth]

Christopher J. PeBenito wrote:
> On Thu, 2008-11-06 at 15:24 +0000, Paul Howarth wrote:
>> Christopher J. PeBenito wrote:
>>> On Fri, 2008-10-10 at 19:24 +0100, Paul Howarth wrote:
>>>> On Wed, 8 Oct 2008 15:22:25 -0400
>>>> "Christopher J. PeBenito" <cpebenito@tresys.com> wrote:
>>>>
>>>>> Moving to refpolicy list.
>>>>>
>>>>> On Wed, 2008-10-08 at 14:05 +0100, Paul Howarth wrote:
>>>>>> Christopher J. PeBenito wrote:
>>>>>>> On Mon, 2008-09-22 at 13:27 +0100, Paul Howarth wrote:
>>>>>>>> Updated patch: sendmail, when run as "newaliases", tries to
>>>>>>>> getattr() milter sockets as well as the directories they live
>>>>>>>> in, so I changed the 
>>>>>>>> milter_getattr_all_data_dirs interface to
>>>>>>>> milter_getattr_all_sockets.
>>>>>>>>
>>>>>>>> I also moved the call to this interface in mta.te out from the
>>>>>>>> middle of 
>>>>>>>> a bunch of postfix-related lines.
>>>>>>>>
>>>>>>>> Paul.
>>>>>>> I think my last two comments are
>>>>>>>
>>>>>>> * you can't require milter_port_t.  It doesn't seem like a
>>>>>>> generic port type would be useful anyway, otherwise there would
>>>>>>> be a port defined.
>>>>>> So I should change "allow milter_$1_t milter_port_t:tcp_socket 
>>>>>> name_bind;" to "corenet_tcp_bind_generic_port($1_milter_t)"?
>>>>> No.  I don't see how it makes sense to have a port type common to all
>>>>> milters.
>>>>>
>>>>>> I can do that but I don't understand why milter_port_t should be
>>>>>> any different than say stunnel_port_t, which also doesn't have a
>>>>>> default port defined, and would be used in a similar way, i.e. an
>>>>>> admin would set up an application to use a specific port (a milter
>>>>>> running over tcp needs to have a port specified, just a tunnel set
>>>>>> up using stunnel does 
>>>>>> - they don't just bind to random generic ports).
>>>>> This is not comparable, as there is only one stunnel domain, whereas
>>>>> there are several milter domains.
>>>> OK, I get that now, I'll use $1_milter_port_t instead then. But the 
>>>> question then arises: how to interface to it? You say I can't require 
>>>> milter_port_t and I guess that applies to $1_milter_port_t too.
>>>> However, as there are no defined ports for these types, there's no
>>>> expansion of network_port() for these types from corenetwork.te.in and
>>>> hence no corenet_tcp_bind_$1_milter_port interface for me to call. I
>>>> got the "require milter_port_t" idea from a similar structure in the
>>>> stunnel policy.
>>>>
>>>> How to proceed with this?
>>> Sorry for the slow response; I've been consumed with the UBAC stuff.
>>>
>>> I'd say don't declare the port in the template and we'll add ports as
>>> milters require them.
>> It's not a case of one milter needing it and another not needing it; 
>> potentially any milter can be used in conjunction with TCP ports. The 
>> usual convention is to use a unix domain socket for communication 
>> between a milter and the MTA but the milter library supports both 
>> approaches, and some sysadmins may wish to configure their milters to 
>> use TCP sockets, so that for instance they can run the milters on 
>> separate hosts from the MTA in order to spread load. When they do this, 
>> each milter will need support in policy, which is why I included it in 
>> the template.
> 
> We can't realistically support all possible configurations.  At some
> point we have to draw the line on trying.  I think the standard
> configuration that covers 80%+ of the users is a reasonable starting
> point.

Updated patch attached with TCP socket support removed.

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: milters.patch
Type: text/x-patch
Size: 7099 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20081117/a83e17e2/attachment.bin 

[refpolicy] Milter Mail Filters

[Christopher J. PeBenito]

On Mon, 2008-11-17 at 10:05 -0500, Paul Howarth wrote:
> Updated patch attached with TCP socket support removed.

Last question

> Index: policy/modules/services/mta.te
> ===================================================================
> --- policy/modules/services/mta.te      (revision 2878)
> +++ policy/modules/services/mta.te      (working copy)
> @@ -116,6 +116,9 @@
>  
>         domain_use_interactive_fds(system_mail_t)
>  
> +       # newaliases runs as system_mail_t when the sendmail initscript does a restart
> +       milter_getattr_all_sockets(system_mail_t)
> +
>         # postfix needs this for newaliases
>         files_getattr_tmp_dirs(system_mail_t)

Why is this bit in the optional_policy for postfix instead of its own
optional_policy at the top level?

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

[refpolicy] Milter Mail Filters

[Paul Howarth]

Christopher J. PeBenito wrote:
> On Mon, 2008-11-17 at 10:05 -0500, Paul Howarth wrote:
>> Updated patch attached with TCP socket support removed.
> 
> Last question
> 
>> Index: policy/modules/services/mta.te
>> ===================================================================
>> --- policy/modules/services/mta.te      (revision 2878)
>> +++ policy/modules/services/mta.te      (working copy)
>> @@ -116,6 +116,9 @@
>>  
>>         domain_use_interactive_fds(system_mail_t)
>>  
>> +       # newaliases runs as system_mail_t when the sendmail initscript does a restart
>> +       milter_getattr_all_sockets(system_mail_t)
>> +
>>         # postfix needs this for newaliases
>>         files_getattr_tmp_dirs(system_mail_t)
> 
> Why is this bit in the optional_policy for postfix instead of its own
> optional_policy at the top level?

Not intentional. I saw the similar entry for postfix and put the extra 
line near it, not realizing the significance of the multiple 
optional_policy blocks.

Revised patch attached.

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: milters.patch
Type: text/x-patch
Size: 7065 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20081124/1f16af29/attachment.bin 

[refpolicy] Milter Mail Filters

[Christopher J. PeBenito]

On Mon, 2008-11-24 at 14:34 +0000, Paul Howarth wrote:
> Christopher J. PeBenito wrote:
> > On Mon, 2008-11-17 at 10:05 -0500, Paul Howarth wrote:
> >> Updated patch attached with TCP socket support removed.
> > 
> > Last question
> > 
> >> Index: policy/modules/services/mta.te
> >> ===================================================================
> >> --- policy/modules/services/mta.te      (revision 2878)
> >> +++ policy/modules/services/mta.te      (working copy)
> >> @@ -116,6 +116,9 @@
> >>  
> >>         domain_use_interactive_fds(system_mail_t)
> >>  
> >> +       # newaliases runs as system_mail_t when the sendmail
> initscript does a restart
> >> +       milter_getattr_all_sockets(system_mail_t)
> >> +
> >>         # postfix needs this for newaliases
> >>         files_getattr_tmp_dirs(system_mail_t)
> > 
> > Why is this bit in the optional_policy for postfix instead of its
> own
> > optional_policy at the top level?
> 
> Not intentional. I saw the similar entry for postfix and put the
> extra 
> line near it, not realizing the significance of the multiple 
> optional_policy blocks.
> 
> Revised patch attached.

Merged, with a couple tweaks.

> 
> 
> 
> 
> 
> 
> differences
> between files
> attachment
> (milters.patch)
> 
> Index: policy/modules/services/sendmail.te
> ===================================================================
> --- policy/modules/services/sendmail.te (revision 2882)
> +++ policy/modules/services/sendmail.te (working copy)
> @@ -109,6 +109,10 @@
>  ')
>  
>  optional_policy(`
> +       milter_stream_connect_all(sendmail_t)
> +')
> +
> +optional_policy(`
>         postfix_exec_master(sendmail_t)
>         postfix_read_config(sendmail_t)
>         postfix_search_spool(sendmail_t)
> Index: policy/modules/services/mta.te
> ===================================================================
> --- policy/modules/services/mta.te      (revision 2882)
> +++ policy/modules/services/mta.te      (working copy)
> @@ -103,6 +103,11 @@
>  ')
>  
>  optional_policy(`
> +       # newaliases runs as system_mail_t when the sendmail
> initscript does a restart
> +       milter_getattr_all_sockets(system_mail_t)
> +')
> +
> +optional_policy(`
>         nagios_read_tmp_files(system_mail_t)
>  ')
>  
> Index: policy/modules/services/milter.te
> ===================================================================
> --- policy/modules/services/milter.te   (revision 0)
> +++ policy/modules/services/milter.te   (revision 0)
> @@ -0,0 +1,54 @@
> +policy_module(milter,0.3.1)
> +
> +########################################
> +#
> +# Declarations
> +#
> +
> +# attributes common to all milters
> +attribute milter_domains;
> +attribute milter_data_type;
> +
> +# currently-supported milters are milter-regex and spamass-milter
> +milter_template(regex)
> +milter_template(spamass)
> +
> +########################################
> +#
> +# milter-regex local policy
> +#   filter emails using regular expressions
> +#   http://www.benzedrine.cx/milter-regex.html
> +#
> +
> +# Look up username for dropping privs
> +auth_use_nsswitch(regex_milter_t)
> +
> +# Config is in /etc/mail/milter-regex.conf
> +mta_read_config(regex_milter_t)
> +
> +# The milter's socket directory lives under /var/spool
> +files_search_spool(regex_milter_t)
> +
> +# It removes any existing socket (not owned by root) whilst running
> as root
> +# and then calls setgid() and setuid() to drop privileges
> +allow regex_milter_t self:capability { setuid setgid dac_override };
> +
> +
> +########################################
> +#
> +# spamass-milter local policy
> +#   pipe emails through SpamAssassin
> +#   http://savannah.nongnu.org/projects/spamass-milt/
> +#
> +
> +# The main job of the milter is to pipe spam through spamc and act on
> the result
> +spamassassin_domtrans_spamc(spamass_milter_t)
> +
> +# When used with -b or -B options, the milter invokes sendmail to
> send mail
> +# to a spamtrap address, using popen()
> +corecmd_exec_shell(spamass_milter_t)
> +corecmd_read_bin_symlinks(spamass_milter_t)
> +corecmd_search_bin(spamass_milter_t)
> +kernel_read_system_state(spamass_milter_t)
> +mta_send_mail(spamass_milter_t)
> +
> Index: policy/modules/services/spamassassin.fc
> ===================================================================
> --- policy/modules/services/spamassassin.fc     (revision 2882)
> +++ policy/modules/services/spamassassin.fc     (working copy)
> @@ -10,7 +10,6 @@
>  /var/lib/spamassassin(/.*)?    gen_context(system_u:object_r:spamd_var_lib_t,s0)
>  
>  /var/run/spamassassin(/.*)?    gen_context(system_u:object_r:spamd_var_run_t,s0)
> -/var/run/spamass-milter(/.*)?  gen_context(system_u:object_r:spamd_var_run_t,s0)
>  
>  /var/spool/spamassassin(/.*)?  gen_context(system_u:object_r:spamd_spool_t,s0)
>  /var/spool/spamd(/.*)?         gen_context(system_u:object_r:spamd_spool_t,s0)
> Index: policy/modules/services/milter.fc
> ===================================================================
> --- policy/modules/services/milter.fc   (revision 0)
> +++ policy/modules/services/milter.fc   (revision 0)
> @@ -0,0 +1,7 @@
> +/usr/sbin/milter-regex                         --      gen_context(system_u:object_r:regex_milter_exec_t,s0)
> +/var/spool/milter-regex(/.*)?                          gen_context(system_u:object_r:regex_milter_data_t,s0)
> +
> +/usr/sbin/spamass-milter                       --      gen_context(system_u:object_r:spamass_milter_exec_t,s0)
> +/var/run/spamass-milter(/.*)?                          gen_context(system_u:object_r:spamass_milter_data_t,s0)
> +/var/run/spamass-milter
> \.pid                   --      gen_context(system_u:object_r:spamass_milter_data_t,s0)
> +
> Index: policy/modules/services/milter.if
> ===================================================================
> --- policy/modules/services/milter.if   (revision 0)
> +++ policy/modules/services/milter.if   (revision 0)
> @@ -0,0 +1,86 @@
> +## <summary>Milter mail filters</summary>
> +
> +########################################
> +## <summary>
> +##     Create a set of derived types for various
> +##     mail filter applications using the milter interface.
> +## </summary>
> +## <param name="milter_name">
> +##     <summary>
> +##     The name to be used for deriving type names.
> +##     </summary>
> +## </param>
> +#
> +template(`milter_template',`
> +
> +       # attributes common to all milters
> +       gen_require(`
> +               attribute milter_data_type, milter_domains;
> +       ')
> +
> +       # Type that the milter application runs as
> +       type $1_milter_t, milter_domains;
> +       domain_type($1_milter_t)
> +       role system_r types $1_milter_t;
> +
> +       # Type for the executable file
> +       type $1_milter_exec_t;
> +       init_daemon_domain($1_milter_t, $1_milter_exec_t)
> +
> +       # Type for the milter data (e.g. the socket used to
> communicate with the MTA)
> +       type $1_milter_data_t, milter_data_type;
> +       files_type($1_milter_data_t);
> +
> +       # Allow communication with MTA over a unix-domain socket
> +       # Note: usage with TCP sockets requires additional policy
> +       manage_sock_files_pattern($1_milter_t,$1_milter_data_t,
> $1_milter_data_t)
> +
> +       # Create other data files and directories in the data
> directory
> +       manage_files_pattern($1_milter_t,$1_milter_data_t,
> $1_milter_data_t)
> +
> +       # Things that all(?) milters will need to do
> +       libs_use_ld_so($1_milter_t)
> +       libs_use_shared_libs($1_milter_t)
> +       miscfiles_read_localization($1_milter_t)
> +       init_use_fds($1_milter_t)
> +       allow $1_milter_t self:fifo_file rw_fifo_file_perms;
> +       logging_send_syslog_msg($1_milter_t)
> +
> +')
> +
> +########################################
> +## <summary>
> +##     MTA communication with milter sockets
> +## </summary>
> +## <param name="domain">
> +##     <summary>
> +##     Domain allowed access.
> +##     </summary>
> +## </param>
> +#
> +interface(`milter_stream_connect_all',`
> +       gen_require(`
> +               attribute milter_data_type, milter_domains;
> +       ')
> +       getattr_dirs_pattern($1,milter_data_type,milter_data_type)
> +       stream_connect_pattern($1,milter_data_type,milter_data_type,milter_domains)
> +')
> +
> +########################################
> +## <summary>
> +##     Allow getattr of milter sockets
> +## </summary>
> +## <param name="domain">
> +##     <summary>
> +##     Domain allowed access.
> +##     </summary>
> +## </param>
> +#
> +interface(`milter_getattr_all_sockets',`
> +       gen_require(`
> +               attribute milter_data_type;
> +       ')
> +       getattr_dirs_pattern($1,milter_data_type,milter_data_type)
> +       getattr_sock_files_pattern($1,milter_data_type,milter_data_type)
> +')
> +
> Index: policy/modules/services/postfix.te
> ===================================================================
> --- policy/modules/services/postfix.te  (revision 2882)
> +++ policy/modules/services/postfix.te  (working copy)
> @@ -519,6 +519,10 @@
>         cyrus_stream_connect(postfix_smtp_t)
>  ')
>  
> +optional_policy(`
> +       milter_stream_connect_all(postfix_smtp_t)
> +')
> +
>  ########################################
>  #
>  # Postfix smtpd local policy
> 
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] Milter Mail Filters

[Paul Howarth]

Christopher J. PeBenito wrote:
> On Mon, 2008-11-24 at 14:34 +0000, Paul Howarth wrote:
>> Christopher J. PeBenito wrote:
>>> On Mon, 2008-11-17 at 10:05 -0500, Paul Howarth wrote:
>>>> Updated patch attached with TCP socket support removed.
>>> Last question
>>>
>>>> Index: policy/modules/services/mta.te
>>>> ===================================================================
>>>> --- policy/modules/services/mta.te      (revision 2878)
>>>> +++ policy/modules/services/mta.te      (working copy)
>>>> @@ -116,6 +116,9 @@
>>>>  
>>>>         domain_use_interactive_fds(system_mail_t)
>>>>  
>>>> +       # newaliases runs as system_mail_t when the sendmail
>> initscript does a restart
>>>> +       milter_getattr_all_sockets(system_mail_t)
>>>> +
>>>>         # postfix needs this for newaliases
>>>>         files_getattr_tmp_dirs(system_mail_t)
>>> Why is this bit in the optional_policy for postfix instead of its
>> own
>>> optional_policy at the top level?
>> Not intentional. I saw the similar entry for postfix and put the
>> extra 
>> line near it, not realizing the significance of the multiple 
>> optional_policy blocks.
>>
>> Revised patch attached.
> 
> Merged, with a couple tweaks.

The tweaks seem quite significant:

$ diff milter.if.pgh milter.if
21d20
< 	domain_type($1_milter_t)
39,41d37
< 	# Things that all(?) milters will need to do
< 	libs_use_ld_so($1_milter_t)
< 	libs_use_shared_libs($1_milter_t)
43d38
< 	init_use_fds($1_milter_t)


Are these four interface calls omitted deliberately?

Paul.

[refpolicy] Milter Mail Filters

[Christopher J. PeBenito]

On Mon, 2008-11-24 at 16:07 +0000, Paul Howarth wrote:
> Christopher J. PeBenito wrote:
> > On Mon, 2008-11-24 at 14:34 +0000, Paul Howarth wrote:
> >> Revised patch attached.
> > 
> > Merged, with a couple tweaks.
> 
> The tweaks seem quite significant:
> 
> $ diff milter.if.pgh milter.if
> 21d20
> < 	domain_type($1_milter_t)

redundant due to init_daemon_domain()

> 39,41d37
> < 	# Things that all(?) milters will need to do
> < 	libs_use_ld_so($1_milter_t)
> < 	libs_use_shared_libs($1_milter_t)

All domains now have these rules (see line 109 of domain.te).

> 43d38
> < 	init_use_fds($1_milter_t)

Its actually the fd for the console, which isn't necessary to be
inherited, nor would we want used by services.  Its dontaudited by
init_daemon_domain().

> Are these four interface calls omitted deliberately?

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