[refpolicy] new policy for dkim-filter

[refpolicy] new policy for dkim-filter

[Stefan Schulze Frielinghaus]

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

Attached is a new policy for the dkim-filter application.

Chris, is the policy OK/ready for merge?

[-- Attachment #2: dkimfilter.fc --]
[-- Type: text/plain, Size: 239 bytes --]

/usr/sbin/dkim-filter	--	gen_context(system_u:object_r:dkimfilter_exec_t,s0)

/var/db/dkim(/.*)?		gen_context(system_u:object_r:dkimfilter_private_key_t,s0)
/var/run/dkim-filter(/.*)?	gen_context(system_u:object_r:dkimfilter_var_run_t,s0)

[-- Attachment #3: dkimfilter.if --]
[-- Type: text/plain, Size: 449 bytes --]

########################################
## <summary>
##      Connect to dkim-filter over an unix stream socket.
## </summary>
## <param name="domain">
##      <summary>
##      Domain allowed access.
##      </summary>
## </param>
#
interface(`dkimfilter_stream_connect',`
	gen_require(`
		type dkimfilter_t, dkimfilter_var_run_t;
	')

	files_search_pids($1)
	stream_connect_pattern($1, dkimfilter_var_run_t, dkimfilter_var_run_t, dkimfilter_t)
')

[-- Attachment #4: dkimfilter.te --]
[-- Type: text/plain, Size: 954 bytes --]


policy_module(dkimfilter, 1.0.0)

########################################
#
# Declarations
#

type dkimfilter_t;
type dkimfilter_exec_t;
init_daemon_domain(dkimfilter_t, dkimfilter_exec_t)

type dkimfilter_var_run_t;
files_pid_file(dkimfilter_var_run_t)

type dkimfilter_private_key_t;
files_type(dkimfilter_private_key_t)

########################################
#
# Local policy
#

allow dkimfilter_t self:capability { setgid setuid };

read_files_pattern(dkimfilter_t, dkimfilter_private_key_t, dkimfilter_private_key_t)
manage_files_pattern(dkimfilter_t, dkimfilter_var_run_t, dkimfilter_var_run_t)
manage_sock_files_pattern(dkimfilter_t, dkimfilter_var_run_t, dkimfilter_var_run_t)

files_read_etc_files(dkimfilter_t)

libs_read_lib_files(dkimfilter_t)

miscfiles_read_localization(dkimfilter_t)

logging_send_syslog_msg(dkimfilter_t)

dev_read_urand(dkimfilter_t)

kernel_read_kernel_sysctls(dkimfilter_t)

sysnet_dns_name_resolve(dkimfilter_t)

[-- Attachment #5: sendmail.te.diff --]
[-- Type: text/x-patch, Size: 454 bytes --]

diff --git a/policy/modules/services/sendmail.te b/policy/modules/services/sendmail.te
index f3f0d44..c102ecb 100644
--- a/policy/modules/services/sendmail.te
+++ b/policy/modules/services/sendmail.te
@@ -130,6 +130,10 @@ optional_policy(`
 	udev_read_db(sendmail_t)
 ')
 
+optional_policy(`
+	dkimfilter_stream_connect(sendmail_t)
+')
+
 ifdef(`TODO',`
 allow sendmail_t etc_mail_t:dir rw_dir_perms;
 allow sendmail_t etc_mail_t:file manage_file_perms;

Re: [refpolicy] new policy for dkim-filter

[Paul Howarth]

On Thu, 10 Sep 2009 21:40:56 +0200
Stefan Schulze Frielinghaus <stefan@seekline.net> wrote:

> Attached is a new policy for the dkim-filter application.
> 
> Chris, is the policy OK/ready for merge?

I think it would be better to merge it with the milter policy. That
would then need no changes to the sendmail policy and the milter should
work with postfix too.

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] new policy for dkim-filter

[Stefan Schulze Frielinghaus]

On Thu, 2009-09-10 at 21:04 +0100, Paul Howarth wrote:
> On Thu, 10 Sep 2009 21:40:56 +0200
> Stefan Schulze Frielinghaus <stefan@seekline.net> wrote:
> 
> > Attached is a new policy for the dkim-filter application.
> > 
> > Chris, is the policy OK/ready for merge?
> 
> I think it would be better to merge it with the milter policy. That
> would then need no changes to the sendmail policy and the milter should
> work with postfix too.

Oh sure, milter_template() is far better for this. I wasn't aware of
such a template. I will have a look at it and send a corrected version.


--
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] new policy for dkim-filter

[Stefan Schulze Frielinghaus]

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

On Thu, 2009-09-10 at 22:39 +0200, Stefan Schulze Frielinghaus wrote:
> On Thu, 2009-09-10 at 21:04 +0100, Paul Howarth wrote:
> > On Thu, 10 Sep 2009 21:40:56 +0200
> > Stefan Schulze Frielinghaus <stefan@seekline.net> wrote:
> > 
> > > Attached is a new policy for the dkim-filter application.
> > > 
> > > Chris, is the policy OK/ready for merge?
> > 
> > I think it would be better to merge it with the milter policy. That
> > would then need no changes to the sendmail policy and the milter should
> > work with postfix too.
> 
> Oh sure, milter_template() is far better for this. I wasn't aware of
> such a template. I will have a look at it and send a corrected version.

And here we are. Since the milter_template() is pretty straight forward
I guess we are done now. Thanks again for the tip.

DKIM-Filter runs fine for me with the new milter policy.

[-- Attachment #2: milter.diff --]
[-- Type: text/x-patch, Size: 3038 bytes --]

diff --git a/policy/modules/services/milter.fc b/policy/modules/services/milter.fc
index 55a3e2f..d4494bc 100644
--- a/policy/modules/services/milter.fc
+++ b/policy/modules/services/milter.fc
@@ -1,10 +1,14 @@
+/usr/sbin/dkim-filter		--	gen_context(system_u:object_r:dkimfilter_milter_exec_t,s0)
 /usr/sbin/milter-greylist	--	gen_context(system_u:object_r:greylist_milter_exec_t,s0)
-/usr/sbin/milter-regex				--	gen_context(system_u:object_r:regex_milter_exec_t,s0)
+/usr/sbin/milter-regex		--	gen_context(system_u:object_r:regex_milter_exec_t,s0)
 /usr/sbin/spamass-milter	--	gen_context(system_u:object_r:spamass_milter_exec_t,s0)
 
+/var/db/dkim(/.*)?			gen_context(system_u:object_r:dkimfilter_private_key_t,s0)
+
 /var/lib/milter-greylist(/.*)?		gen_context(system_u:object_r:greylist_milter_data_t,s0)
 /var/lib/spamass-milter(/.*)?		gen_context(system_u:object_r:spamass_milter_state_t,s0)
 
+/var/run/dkim-filter(/.*)?		gen_context(system_u:object_r:dkimfilter_milter_data_t,s0)
 /var/run/milter-greylist(/.*)?		gen_context(system_u:object_r:greylist_milter_data_t,s0)
 /var/run/milter-greylist\.pid	--	gen_context(system_u:object_r:greylist_milter_data_t,s0)
 /var/run/spamass-milter(/.*)?		gen_context(system_u:object_r:spamass_milter_data_t,s0)
diff --git a/policy/modules/services/milter.te b/policy/modules/services/milter.te
index ff7cebc..88be485 100644
--- a/policy/modules/services/milter.te
+++ b/policy/modules/services/milter.te
@@ -1,5 +1,5 @@
 
-policy_module(milter, 1.1.0)
+policy_module(milter, 1.2.0)
 
 ########################################
 #
@@ -10,11 +10,16 @@ policy_module(milter, 1.1.0)
 attribute milter_domains;
 attribute milter_data_type;
 
-# currently-supported milters are milter-greylist, milter-regex and spamass-milter
+# currently-supported milters are dkim-filter, milter-greylist, milter-regex and spamass-milter
+milter_template(dkimfilter)
 milter_template(greylist)
 milter_template(regex)
 milter_template(spamass)
 
+# Type for the private key of dkim-filter
+type dkimfilter_private_key_t;
+files_type(dkimfilter_private_key_t)
+
 # Type for the spamass-milter home directory, under which spamassassin will
 # store system-wide preferences, bayes databases etc. if not configured to
 # use per-user configuration
@@ -23,6 +28,25 @@ files_type(spamass_milter_state_t)
 
 ########################################
 #
+# dkimfilter local policy
+#   DomainKeys Identified Mail sender authentication
+#   http://sourceforge.net/projects/dkim-milter/
+#
+
+allow dkimfilter_milter_t self:capability { setgid setuid };
+
+read_files_pattern(dkimfilter_milter_t, dkimfilter_private_key_t, dkimfilter_private_key_t)
+
+files_read_etc_files(dkimfilter_milter_t)
+
+kernel_read_kernel_sysctls(dkimfilter_milter_t)
+
+sysnet_dns_name_resolve(dkimfilter_milter_t)
+
+dev_read_urand(dkimfilter_milter_t)
+
+########################################
+#
 # milter-greylist local policy
 #   ensure smtp clients retry mail like real MTAs and not spamware
 #   http://hcpnet.free.fr/milter-greylist/

Re: [refpolicy] new policy for dkim-filter

[Paul Howarth]

On Thu, 10 Sep 2009 23:50:48 +0200
Stefan Schulze Frielinghaus <stefan@seekline.net> wrote:

> On Thu, 2009-09-10 at 22:39 +0200, Stefan Schulze Frielinghaus wrote:
> > On Thu, 2009-09-10 at 21:04 +0100, Paul Howarth wrote:
> > > On Thu, 10 Sep 2009 21:40:56 +0200
> > > Stefan Schulze Frielinghaus <stefan@seekline.net> wrote:
> > > 
> > > > Attached is a new policy for the dkim-filter application.
> > > > 
> > > > Chris, is the policy OK/ready for merge?
> > > 
> > > I think it would be better to merge it with the milter policy.
> > > That would then need no changes to the sendmail policy and the
> > > milter should work with postfix too.
> > 
> > Oh sure, milter_template() is far better for this. I wasn't aware of
> > such a template. I will have a look at it and send a corrected
> > version.
> 
> And here we are. Since the milter_template() is pretty straight
> forward I guess we are done now. Thanks again for the tip.
> 
> DKIM-Filter runs fine for me with the new milter policy.

Given that the upstream project is called dkim-milter (albeit the
milter part is called dkimfilter), I think the dkimfilter_milter_*
types would be better named as just dkim_milter_*.

Otherwise looks sane to me.

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] new policy for dkim-filter

[Stefan Schulze Frielinghaus]

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

On Thu, 2009-09-10 at 23:27 +0100, Paul Howarth wrote:
> On Thu, 10 Sep 2009 23:50:48 +0200
> Stefan Schulze Frielinghaus <stefan@seekline.net> wrote:
> 
> > On Thu, 2009-09-10 at 22:39 +0200, Stefan Schulze Frielinghaus wrote:
> > > On Thu, 2009-09-10 at 21:04 +0100, Paul Howarth wrote:
> > > > On Thu, 10 Sep 2009 21:40:56 +0200
> > > > Stefan Schulze Frielinghaus <stefan@seekline.net> wrote:
> > > > 
> > > > > Attached is a new policy for the dkim-filter application.
> > > > > 
> > > > > Chris, is the policy OK/ready for merge?
> > > > 
> > > > I think it would be better to merge it with the milter policy.
> > > > That would then need no changes to the sendmail policy and the
> > > > milter should work with postfix too.
> > > 
> > > Oh sure, milter_template() is far better for this. I wasn't aware of
> > > such a template. I will have a look at it and send a corrected
> > > version.
> > 
> > And here we are. Since the milter_template() is pretty straight
> > forward I guess we are done now. Thanks again for the tip.
> > 
> > DKIM-Filter runs fine for me with the new milter policy.
> 
> Given that the upstream project is called dkim-milter (albeit the
> milter part is called dkimfilter), I think the dkimfilter_milter_*
> types would be better named as just dkim_milter_*.

I was unsure about that. The upstream project is called dkim-milter
indeed but they seem to distinguish between the library and the filter.
Here is a quote from the README:

"This package consists of a library that implements the DKIM service and
a milter-based filter application that can plug in to the sendmail
MTA ..."

So in a strict sense they provide a library and a filter. Nevertheless I
changed it.

Attached is a new diff with dkim_milter_* types.

[-- Attachment #2: milter.diff --]
[-- Type: text/x-patch, Size: 2948 bytes --]

diff --git a/policy/modules/services/milter.fc b/policy/modules/services/milter.fc
index 55a3e2f..d4494bc 100644
--- a/policy/modules/services/milter.fc
+++ b/policy/modules/services/milter.fc
@@ -1,10 +1,14 @@
+/usr/sbin/dkim-filter		--	gen_context(system_u:object_r:dkim_milter_exec_t,s0)
 /usr/sbin/milter-greylist	--	gen_context(system_u:object_r:greylist_milter_exec_t,s0)
-/usr/sbin/milter-regex				--	gen_context(system_u:object_r:regex_milter_exec_t,s0)
+/usr/sbin/milter-regex		--	gen_context(system_u:object_r:regex_milter_exec_t,s0)
 /usr/sbin/spamass-milter	--	gen_context(system_u:object_r:spamass_milter_exec_t,s0)
 
+/var/db/dkim(/.*)?			gen_context(system_u:object_r:dkim_private_key_t,s0)
+
 /var/lib/milter-greylist(/.*)?		gen_context(system_u:object_r:greylist_milter_data_t,s0)
 /var/lib/spamass-milter(/.*)?		gen_context(system_u:object_r:spamass_milter_state_t,s0)
 
+/var/run/dkim-filter(/.*)?		gen_context(system_u:object_r:dkim_milter_data_t,s0)
 /var/run/milter-greylist(/.*)?		gen_context(system_u:object_r:greylist_milter_data_t,s0)
 /var/run/milter-greylist\.pid	--	gen_context(system_u:object_r:greylist_milter_data_t,s0)
 /var/run/spamass-milter(/.*)?		gen_context(system_u:object_r:spamass_milter_data_t,s0)
diff --git a/policy/modules/services/milter.te b/policy/modules/services/milter.te
index ff7cebc..88be485 100644
--- a/policy/modules/services/milter.te
+++ b/policy/modules/services/milter.te
@@ -1,5 +1,5 @@
 
-policy_module(milter, 1.1.0)
+policy_module(milter, 1.2.0)
 
 ########################################
 #
@@ -10,11 +10,16 @@ policy_module(milter, 1.1.0)
 attribute milter_domains;
 attribute milter_data_type;
 
-# currently-supported milters are milter-greylist, milter-regex and spamass-milter
+# currently-supported milters are dkim-filter, milter-greylist, milter-regex and spamass-milter
+milter_template(dkim)
 milter_template(greylist)
 milter_template(regex)
 milter_template(spamass)
 
+# Type for the private key of dkim-filter
+type dkim_private_key_t;
+files_type(dkim_private_key_t)
+
 # Type for the spamass-milter home directory, under which spamassassin will
 # store system-wide preferences, bayes databases etc. if not configured to
 # use per-user configuration
@@ -23,6 +28,25 @@ files_type(spamass_milter_state_t)
 
 ########################################
 #
+# dkim local policy
+#   DomainKeys Identified Mail sender authentication
+#   http://sourceforge.net/projects/dkim-milter/
+#
+
+allow dkim_milter_t self:capability { setgid setuid };
+
+read_files_pattern(dkim_milter_t, dkim_private_key_t, dkim_private_key_t)
+
+files_read_etc_files(dkim_milter_t)
+
+kernel_read_kernel_sysctls(dkim_milter_t)
+
+sysnet_dns_name_resolve(dkim_milter_t)
+
+dev_read_urand(dkim_milter_t)
+
+########################################
+#
 # milter-greylist local policy
 #   ensure smtp clients retry mail like real MTAs and not spamware
 #   http://hcpnet.free.fr/milter-greylist/

Re: [refpolicy] new policy for dkim-filter

[Stefan Schulze Frielinghaus]

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

On Fri, 2009-09-11 at 09:53 +0200, Stefan Schulze Frielinghaus wrote:
> On Thu, 2009-09-10 at 23:27 +0100, Paul Howarth wrote:
> > On Thu, 10 Sep 2009 23:50:48 +0200
> > Stefan Schulze Frielinghaus <stefan@seekline.net> wrote:
> > 
> > > On Thu, 2009-09-10 at 22:39 +0200, Stefan Schulze Frielinghaus wrote:
> > > > On Thu, 2009-09-10 at 21:04 +0100, Paul Howarth wrote:
> > > > > On Thu, 10 Sep 2009 21:40:56 +0200
> > > > > Stefan Schulze Frielinghaus <stefan@seekline.net> wrote:
> > > > > 
> > > > > > Attached is a new policy for the dkim-filter application.
> > > > > > 
> > > > > > Chris, is the policy OK/ready for merge?
> > > > > 
> > > > > I think it would be better to merge it with the milter policy.
> > > > > That would then need no changes to the sendmail policy and the
> > > > > milter should work with postfix too.
> > > > 
> > > > Oh sure, milter_template() is far better for this. I wasn't aware of
> > > > such a template. I will have a look at it and send a corrected
> > > > version.
> > > 
> > > And here we are. Since the milter_template() is pretty straight
> > > forward I guess we are done now. Thanks again for the tip.
> > > 
> > > DKIM-Filter runs fine for me with the new milter policy.
> > 
> > Given that the upstream project is called dkim-milter (albeit the
> > milter part is called dkimfilter), I think the dkimfilter_milter_*
> > types would be better named as just dkim_milter_*.
> 
> I was unsure about that. The upstream project is called dkim-milter
> indeed but they seem to distinguish between the library and the filter.
> Here is a quote from the README:
> 
> "This package consists of a library that implements the DKIM service and
> a milter-based filter application that can plug in to the sendmail
> MTA ..."
> 
> So in a strict sense they provide a library and a filter. Nevertheless I
> changed it.
> 
> Attached is a new diff with dkim_milter_* types.

Argl, forgot to change "dkim_private_key_t" to
"dkim_milter_private_key_t". Seriously this should be the last commit :D

Tested attached policy again on CentOS 5.3 with strict policy.

[-- Attachment #2: milter.diff --]
[-- Type: text/x-patch, Size: 2983 bytes --]

diff --git a/policy/modules/services/milter.fc b/policy/modules/services/milter.fc
index 55a3e2f..d4494bc 100644
--- a/policy/modules/services/milter.fc
+++ b/policy/modules/services/milter.fc
@@ -1,10 +1,14 @@
+/usr/sbin/dkim-filter		--	gen_context(system_u:object_r:dkim_milter_exec_t,s0)
 /usr/sbin/milter-greylist	--	gen_context(system_u:object_r:greylist_milter_exec_t,s0)
-/usr/sbin/milter-regex				--	gen_context(system_u:object_r:regex_milter_exec_t,s0)
+/usr/sbin/milter-regex		--	gen_context(system_u:object_r:regex_milter_exec_t,s0)
 /usr/sbin/spamass-milter	--	gen_context(system_u:object_r:spamass_milter_exec_t,s0)
 
+/var/db/dkim(/.*)?			gen_context(system_u:object_r:dkim_milter_private_key_t,s0)
+
 /var/lib/milter-greylist(/.*)?		gen_context(system_u:object_r:greylist_milter_data_t,s0)
 /var/lib/spamass-milter(/.*)?		gen_context(system_u:object_r:spamass_milter_state_t,s0)
 
+/var/run/dkim-filter(/.*)?		gen_context(system_u:object_r:dkim_milter_data_t,s0)
 /var/run/milter-greylist(/.*)?		gen_context(system_u:object_r:greylist_milter_data_t,s0)
 /var/run/milter-greylist\.pid	--	gen_context(system_u:object_r:greylist_milter_data_t,s0)
 /var/run/spamass-milter(/.*)?		gen_context(system_u:object_r:spamass_milter_data_t,s0)
diff --git a/policy/modules/services/milter.te b/policy/modules/services/milter.te
index ff7cebc..88be485 100644
--- a/policy/modules/services/milter.te
+++ b/policy/modules/services/milter.te
@@ -1,5 +1,5 @@
 
-policy_module(milter, 1.1.0)
+policy_module(milter, 1.2.0)
 
 ########################################
 #
@@ -10,11 +10,16 @@ policy_module(milter, 1.1.0)
 attribute milter_domains;
 attribute milter_data_type;
 
-# currently-supported milters are milter-greylist, milter-regex and spamass-milter
+# currently-supported milters are dkim-filter, milter-greylist, milter-regex and spamass-milter
+milter_template(dkim)
 milter_template(greylist)
 milter_template(regex)
 milter_template(spamass)
 
+# Type for the private key of dkim-filter
+type dkim_milter_private_key_t;
+files_type(dkim_milter_private_key_t)
+
 # Type for the spamass-milter home directory, under which spamassassin will
 # store system-wide preferences, bayes databases etc. if not configured to
 # use per-user configuration
@@ -23,6 +28,25 @@ files_type(spamass_milter_state_t)
 
 ########################################
 #
+# dkim local policy
+#   DomainKeys Identified Mail sender authentication
+#   http://sourceforge.net/projects/dkim-milter/
+#
+
+allow dkim_milter_t self:capability { setgid setuid };
+
+read_files_pattern(dkim_milter_t, dkim_milter_private_key_t, dkim_milter_private_key_t)
+
+files_read_etc_files(dkim_milter_t)
+
+kernel_read_kernel_sysctls(dkim_milter_t)
+
+sysnet_dns_name_resolve(dkim_milter_t)
+
+dev_read_urand(dkim_milter_t)
+
+########################################
+#
 # milter-greylist local policy
 #   ensure smtp clients retry mail like real MTAs and not spamware
 #   http://hcpnet.free.fr/milter-greylist/

Re: [refpolicy] new policy for dkim-filter

[Chris PeBenito]

On Fri, 2009-09-11 at 10:20 +0200, Stefan Schulze Frielinghaus wrote:
> > > > > > On Thu, 10 Sep 2009 21:40:56 +0200
> > > > > > Stefan Schulze Frielinghaus <stefan@seekline.net> wrote:
> > > > > > 
> > > > > > > Attached is a new policy for the dkim-filter application.
> > > > > > > 
> > > > > > > Chris, is the policy OK/ready for merge?

> Tested attached policy again on CentOS 5.3 with strict policy.

It looks ok.  However I'm starting to get concerned about the milter
module getting big.  If you want, say the spamassassin milter, you add
the milter module... but then you get rules for a several other milters
too.

> diff --git a/policy/modules/services/milter.fc
> b/policy/modules/services/milter.fc
> index 55a3e2f..d4494bc 100644
> --- a/policy/modules/services/milter.fc
> +++ b/policy/modules/services/milter.fc
> @@ -1,10 +1,14 @@
> +/usr/sbin/dkim-filter          --      gen_context(system_u:object_r:dkim_milter_exec_t,s0)
>  /usr/sbin/milter-greylist      --      gen_context(system_u:object_r:greylist_milter_exec_t,s0)
> -/usr/sbin/milter-regex                         --      gen_context(system_u:object_r:regex_milter_exec_t,s0)
> +/usr/sbin/milter-regex         --      gen_context(system_u:object_r:regex_milter_exec_t,s0)
>  /usr/sbin/spamass-milter       --      gen_context(system_u:object_r:spamass_milter_exec_t,s0)
>  
> +/var/db/dkim(/.*)?                     gen_context(system_u:object_r:dkim_milter_private_key_t,s0)
> +
>  /var/lib/milter-greylist(/.*)?         gen_context(system_u:object_r:greylist_milter_data_t,s0)
>  /var/lib/spamass-milter(/.*)?          gen_context(system_u:object_r:spamass_milter_state_t,s0)
>  
> +/var/run/dkim-filter(/.*)?             gen_context(system_u:object_r:dkim_milter_data_t,s0)
>  /var/run/milter-greylist(/.*)?         gen_context(system_u:object_r:greylist_milter_data_t,s0)
>  /var/run/milter-greylist
> \.pid  --      gen_context(system_u:object_r:greylist_milter_data_t,s0)
>  /var/run/spamass-milter(/.*)?          gen_context(system_u:object_r:spamass_milter_data_t,s0)
> diff --git a/policy/modules/services/milter.te
> b/policy/modules/services/milter.te
> index ff7cebc..88be485 100644
> --- a/policy/modules/services/milter.te
> +++ b/policy/modules/services/milter.te
> @@ -1,5 +1,5 @@
>  
> -policy_module(milter, 1.1.0)
> +policy_module(milter, 1.2.0)
>  
>  ########################################
>  #
> @@ -10,11 +10,16 @@ policy_module(milter, 1.1.0)
>  attribute milter_domains;
>  attribute milter_data_type;
>  
> -# currently-supported milters are milter-greylist, milter-regex and
> spamass-milter
> +# currently-supported milters are dkim-filter, milter-greylist,
> milter-regex and spamass-milter
> +milter_template(dkim)
>  milter_template(greylist)
>  milter_template(regex)
>  milter_template(spamass)
>  
> +# Type for the private key of dkim-filter
> +type dkim_milter_private_key_t;
> +files_type(dkim_milter_private_key_t)
> +
>  # Type for the spamass-milter home directory, under which
> spamassassin will
>  # store system-wide preferences, bayes databases etc. if not
> configured to
>  # use per-user configuration
> @@ -23,6 +28,25 @@ files_type(spamass_milter_state_t)
>  
>  ########################################
>  #
> +# dkim local policy
> +#   DomainKeys Identified Mail sender authentication
> +#   http://sourceforge.net/projects/dkim-milter/
> +#
> +
> +allow dkim_milter_t self:capability { setgid setuid };
> +
> +read_files_pattern(dkim_milter_t, dkim_milter_private_key_t,
> dkim_milter_private_key_t)
> +
> +files_read_etc_files(dkim_milter_t)
> +
> +kernel_read_kernel_sysctls(dkim_milter_t)
> +
> +sysnet_dns_name_resolve(dkim_milter_t)
> +
> +dev_read_urand(dkim_milter_t)
> +
> +########################################
> +#
>  # milter-greylist local policy
>  #   ensure smtp clients retry mail like real MTAs and not spamware
>  #   http://hcpnet.free.fr/milter-greylist/
> 

-- 
Chris PeBenito
<pebenito@gentoo.org>
Developer,
Hardened Gentoo Linux
 
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243
Key fingerprint = B0E6 877A 883F A57A 8E6A  CB00 BC8E E42D E6AF 9243


--
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] new policy for dkim-filter

[Stefan Schulze Frielinghaus]

On Fri, 2009-09-11 at 08:30 -0400, Chris PeBenito wrote:
> On Fri, 2009-09-11 at 10:20 +0200, Stefan Schulze Frielinghaus wrote:
> > > > > > > On Thu, 10 Sep 2009 21:40:56 +0200
> > > > > > > Stefan Schulze Frielinghaus <stefan@seekline.net> wrote:
> > > > > > > 
> > > > > > > > Attached is a new policy for the dkim-filter application.
> > > > > > > > 
> > > > > > > > Chris, is the policy OK/ready for merge?
> 
> > Tested attached policy again on CentOS 5.3 with strict policy.
> 
> It looks ok.  However I'm starting to get concerned about the milter
> module getting big.  If you want, say the spamassassin milter, you add
> the milter module... but then you get rules for a several other milters
> too.

Yeah thought about that too. A quick fix would be to surround the milter
modules with booleans but I don't really like this idea. Another
solution would be to split the milter.te into several sub modules.
Any other thoughts?


--
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] new policy for dkim-filter

[Stefan Schulze Frielinghaus]

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

On Fri, 2009-09-11 at 08:30 -0400, Chris PeBenito wrote:
> On Fri, 2009-09-11 at 10:20 +0200, Stefan Schulze Frielinghaus wrote:
> > > > > > > On Thu, 10 Sep 2009 21:40:56 +0200
> > > > > > > Stefan Schulze Frielinghaus <stefan@seekline.net> wrote:
> > > > > > > 
> > > > > > > > Attached is a new policy for the dkim-filter application.
> > > > > > > > 
> > > > > > > > Chris, is the policy OK/ready for merge?
> 
> > Tested attached policy again on CentOS 5.3 with strict policy.
> 
> It looks ok.  However I'm starting to get concerned about the milter
> module getting big.  If you want, say the spamassassin milter, you add
> the milter module... but then you get rules for a several other milters
> too.

Attached is a milter version which behaves like the apache_template(). I
only took care of the dkim-milter but in general this would only mean
some reorganization of all modules ... nothing more. Any cons about
that?

If this would be the right way then we could also talk about the
milter_template() naming convention:

type $1_milter_t

The apache_template generates slightly different type names:

type httpd_$1_script_t

What about changing $1_milter_t to milter_$1_t?

[-- Attachment #2: dkim-milter.fc --]
[-- Type: text/plain, Size: 243 bytes --]

/usr/sbin/dkim-filter		--	gen_context(system_u:object_r:dkim_milter_exec_t,s0)

/var/db/dkim(/.*)?			gen_context(system_u:object_r:dkim_milter_private_key_t,s0)

/var/run/dkim-filter(/.*)?		gen_context(system_u:object_r:dkim_milter_data_t,s0)

[-- Attachment #3: dkim-milter.te --]
[-- Type: text/plain, Size: 589 bytes --]


policy_module(dkim-milter, 1.0.0)

########################################
#
# Declarations
#

milter_template(dkim)

# Type for the private key of dkim-filter
type dkim_milter_private_key_t;
files_type(dkim_milter_private_key_t)

########################################
#
# Local policy
#

allow dkim_milter_t self:capability { setgid setuid };

read_files_pattern(dkim_milter_t, dkim_milter_private_key_t, dkim_milter_private_key_t)

files_read_etc_files(dkim_milter_t)

kernel_read_kernel_sysctls(dkim_milter_t)

sysnet_dns_name_resolve(dkim_milter_t)

dev_read_urand(dkim_milter_t)

[-- Attachment #4: milter.if --]
[-- Type: text/plain, Size: 2102 bytes --]

## <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 $1_milter_t, milter_domains;
	type $1_milter_exec_t;
	init_daemon_domain($1_milter_t, $1_milter_exec_t)
	role system_r types $1_milter_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 $1_milter_t self:fifo_file rw_fifo_file_perms;

	# 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)

	miscfiles_read_localization($1_milter_t)

	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)
')

[-- Attachment #5: milter.te --]
[-- Type: text/plain, Size: 181 bytes --]


policy_module(milter, 1.2.0)

########################################
#
# Declarations
#

# attributes common to all milters
attribute milter_domains;
attribute milter_data_type;

Re: [refpolicy] new policy for dkim-filter

[Paul Howarth]

On 11/09/09 15:22, Stefan Schulze Frielinghaus wrote:
> On Fri, 2009-09-11 at 08:30 -0400, Chris PeBenito wrote:
>> On Fri, 2009-09-11 at 10:20 +0200, Stefan Schulze Frielinghaus wrote:
>>>>>>>> On Thu, 10 Sep 2009 21:40:56 +0200
>>>>>>>> Stefan Schulze Frielinghaus<stefan@seekline.net>  wrote:
>>>>>>>>
>>>>>>>>> Attached is a new policy for the dkim-filter application.
>>>>>>>>>
>>>>>>>>> Chris, is the policy OK/ready for merge?
>>
>>> Tested attached policy again on CentOS 5.3 with strict policy.
>>
>> It looks ok.  However I'm starting to get concerned about the milter
>> module getting big.  If you want, say the spamassassin milter, you add
>> the milter module... but then you get rules for a several other milters
>> too.

True, but how much of a problem is that, given that any milter user is 
at least going to have also the sendmail/postfix policy and the mta 
policy too?

> Attached is a milter version which behaves like the apache_template(). I
> only took care of the dkim-milter but in general this would only mean
> some reorganization of all modules ... nothing more. Any cons about
> that?

Splitting each milter out into its own module is certainly do-able; 
doesn't that add overhead (from having more modules) as well though?

> If this would be the right way then we could also talk about the
> milter_template() naming convention:
>
> type $1_milter_t
>
> The apache_template generates slightly different type names:
>
> type httpd_$1_script_t
>
> What about changing $1_milter_t to milter_$1_t?

That would make sense given that most types in refpolicy are prefixed 
with the module name. There would need to be typealiases added though 
for the old names for the benefit of existing users, wouldn't there?

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] new policy for dkim-filter

[Stefan Schulze Frielinghaus]

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

On Fri, 2009-09-11 at 16:18 +0100, Paul Howarth wrote:
> On 11/09/09 15:22, Stefan Schulze Frielinghaus wrote:
> > On Fri, 2009-09-11 at 08:30 -0400, Chris PeBenito wrote:
> >> On Fri, 2009-09-11 at 10:20 +0200, Stefan Schulze Frielinghaus wrote:
> >>>>>>>> On Thu, 10 Sep 2009 21:40:56 +0200
> >>>>>>>> Stefan Schulze Frielinghaus<stefan@seekline.net>  wrote:
> >>>>>>>>
> >>>>>>>>> Attached is a new policy for the dkim-filter application.
> >>>>>>>>>
> >>>>>>>>> Chris, is the policy OK/ready for merge?
> >>
> >>> Tested attached policy again on CentOS 5.3 with strict policy.
> >>
> >> It looks ok.  However I'm starting to get concerned about the milter
> >> module getting big.  If you want, say the spamassassin milter, you add
> >> the milter module... but then you get rules for a several other milters
> >> too.
> 
> True, but how much of a problem is that, given that any milter user is 
> at least going to have also the sendmail/postfix policy and the mta 
> policy too?

It's not a huge problem but I prefer only to install policy modules I
really need. Everything else is disabled. Also this approach is more
compliant with the minimal policy:
http://danwalsh.livejournal.com/26759.html

> 
> > Attached is a milter version which behaves like the apache_template(). I
> > only took care of the dkim-milter but in general this would only mean
> > some reorganization of all modules ... nothing more. Any cons about
> > that?
> 
> Splitting each milter out into its own module is certainly do-able; 
> doesn't that add overhead (from having more modules) as well though?

Hmm I don't think this will be a problem. I believe it is even easier to
manage. If they are separated in several files it's easier to handle
them (if there exist really dozens of them).

> 
> > If this would be the right way then we could also talk about the
> > milter_template() naming convention:
> >
> > type $1_milter_t
> >
> > The apache_template generates slightly different type names:
> >
> > type httpd_$1_script_t
> >
> > What about changing $1_milter_t to milter_$1_t?
> 
> That would make sense given that most types in refpolicy are prefixed 
> with the module name. There would need to be typealiases added though 
> for the old names for the benefit of existing users, wouldn't there?

Good point. I created a couple of aliases.

Attached is the milter policy with all four modules. What do you think
about this approach, Paul, Chris?

Tested again on CentOS 5.3 with strict policy.

[-- Attachment #2: milter.if --]
[-- Type: text/plain, Size: 2132 bytes --]

## <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 milter_$1_t alias $1_milter_t, milter_domains;
	type milter_$1_exec_t alias $1_milter_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 alias $1_milter_data_t, milter_data_type;
	files_type(milter_$1_data_t)

	allow milter_$1_t self:fifo_file rw_fifo_file_perms;

	# Allow communication with MTA over a unix-domain socket
	# Note: usage with TCP sockets requires additional policy
	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)

	miscfiles_read_localization(milter_$1_t)

	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)
')

[-- Attachment #3: milter.te --]
[-- Type: text/plain, Size: 181 bytes --]


policy_module(milter, 1.2.0)

########################################
#
# Declarations
#

# attributes common to all milters
attribute milter_domains;
attribute milter_data_type;

[-- Attachment #4: milter_dkim.fc --]
[-- Type: text/plain, Size: 243 bytes --]

/usr/sbin/dkim-filter		--	gen_context(system_u:object_r:milter_dkim_exec_t,s0)

/var/db/dkim(/.*)?			gen_context(system_u:object_r:milter_dkim_private_key_t,s0)

/var/run/dkim-filter(/.*)?		gen_context(system_u:object_r:milter_dkim_data_t,s0)

[-- Attachment #5: milter_dkim.te --]
[-- Type: text/plain, Size: 589 bytes --]


policy_module(milter_dkim, 1.0.0)

########################################
#
# Declarations
#

milter_template(dkim)

# Type for the private key of dkim-filter
type milter_dkim_private_key_t;
files_type(milter_dkim_private_key_t)

########################################
#
# Local policy
#

allow milter_dkim_t self:capability { setgid setuid };

read_files_pattern(milter_dkim_t, milter_dkim_private_key_t, milter_dkim_private_key_t)

files_read_etc_files(milter_dkim_t)

kernel_read_kernel_sysctls(milter_dkim_t)

sysnet_dns_name_resolve(milter_dkim_t)

dev_read_urand(milter_dkim_t)

[-- Attachment #6: milter_greylist.fc --]
[-- Type: text/plain, Size: 356 bytes --]

/usr/sbin/milter-greylist	--	gen_context(system_u:object_r:milter_greylist_exec_t,s0)

/var/lib/milter-greylist(/.*)?		gen_context(system_u:object_r:milter_greylist_data_t,s0)

/var/run/milter-greylist(/.*)?		gen_context(system_u:object_r:milter_greylist_data_t,s0)
/var/run/milter-greylist\.pid	--	gen_context(system_u:object_r:milter_greylist_data_t,s0)

[-- Attachment #7: milter_greylist.te --]
[-- Type: text/plain, Size: 1041 bytes --]


policy_module(milter_greylist, 1.0.0)

########################################
#
# Declarations
#

milter_template(greylist)

########################################
#
# Local policy
#

# It removes any existing socket (not owned by root) whilst running as root,
# fixes permissions, renices itself and then calls setgid() and setuid() to
# drop privileges
allow milter_greylist_t self:capability { chown dac_override setgid setuid sys_nice };
allow milter_greylist_t self:process { setsched getsched };

# It creates a pid file /var/run/milter-greylist.pid
files_pid_filetrans(milter_greylist_t, milter_greylist_data_t, file)

kernel_read_kernel_sysctls(milter_greylist_t)

# Allow the milter to read a GeoIP database in /usr/share
files_read_usr_files(milter_greylist_t)
# The milter runs from /var/lib/milter-greylist and maintains files there
files_search_var_lib(milter_greylist_t)

# Look up username for dropping privs
auth_use_nsswitch(milter_greylist_t)

# Config is in /etc/mail/greylist.conf
mta_read_config(milter_greylist_t)

[-- Attachment #8: milter_regex.fc --]
[-- Type: text/plain, Size: 167 bytes --]

/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)

[-- Attachment #9: milter_regex.te --]
[-- Type: text/plain, Size: 626 bytes --]


policy_module(milter_regex, 1.0.0)

########################################
#
# Declarations
#

milter_template(regex)

########################################
#
# Local policy
#

# 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 };

# The milter's socket directory lives under /var/spool
files_search_spool(milter_regex_t)

# 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)

[-- Attachment #10: milter_spamass.fc --]
[-- Type: text/plain, Size: 261 bytes --]

/usr/sbin/spamass-milter	--	gen_context(system_u:object_r:milter_spamass_exec_t,s0)

/var/lib/spamass-milter(/.*)?		gen_context(system_u:object_r:milter_spamass_state_t,s0)

/var/run/spamass-milter(/.*)?		gen_context(system_u:object_r:milter_spamass_data_t,s0)

[-- Attachment #11: milter_spamass.if --]
[-- Type: text/plain, Size: 586 bytes --]

## <summary>spamassassin milter</summary>

########################################
## <summary>
##	Manage spamassassin milter state
## </summary>
## <param name="domain">
##	<summary>
##	Domain allowed access.
##	</summary>
## </param>
#
interface(`milter_manage_spamass_state',`
	gen_require(`
		type milter_spamass_state_t;
	')

	files_search_var_lib($1)
	manage_files_pattern($1, milter_spamass_state_t, milter_spamass_state_t)
	manage_dirs_pattern($1, milter_spamass_state_t, milter_spamass_state_t)
	manage_lnk_files_pattern($1, milter_spamass_state_t, milter_spamass_state_t)
')

[-- Attachment #12: milter_spamass.te --]
[-- Type: text/plain, Size: 1025 bytes --]


policy_module(milter_spamass, 1.0.0)

########################################
#
# Declarations
#
milter_template(spamass)

# Type for the spamass-milter home directory, under which spamassassin will
# store system-wide preferences, bayes databases etc. if not configured to
# use per-user configuration
type milter_spamass_state_t;
files_type(milter_spamass_state_t)

########################################
#
# Local policy
#

# The milter runs from /var/lib/spamass-milter
allow milter_spamass_t milter_spamass_state_t:dir search_dir_perms;
files_search_var_lib(milter_spamass_t)

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

mta_send_mail(milter_spamass_t)

# The main job of the milter is to pipe spam through spamc and act on the result
spamassassin_domtrans_client(milter_spamass_t)

Re: [refpolicy] new policy for dkim-filter

[Stefan Schulze Frielinghaus]

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

On Sat, 2009-09-12 at 14:49 +0200, Stefan Schulze Frielinghaus wrote:
> On Fri, 2009-09-11 at 16:18 +0100, Paul Howarth wrote:
> > On 11/09/09 15:22, Stefan Schulze Frielinghaus wrote:
> > > On Fri, 2009-09-11 at 08:30 -0400, Chris PeBenito wrote:
> > >> On Fri, 2009-09-11 at 10:20 +0200, Stefan Schulze Frielinghaus wrote:
> > >>>>>>>> On Thu, 10 Sep 2009 21:40:56 +0200
> > >>>>>>>> Stefan Schulze Frielinghaus<stefan@seekline.net>  wrote:
> > >>>>>>>>
> > >>>>>>>>> Attached is a new policy for the dkim-filter application.
> > >>>>>>>>>
> > >>>>>>>>> Chris, is the policy OK/ready for merge?
> > >>
> > >>> Tested attached policy again on CentOS 5.3 with strict policy.
> > >>
> > >> It looks ok.  However I'm starting to get concerned about the milter
> > >> module getting big.  If you want, say the spamassassin milter, you add
> > >> the milter module... but then you get rules for a several other milters
> > >> too.
> > 
> > True, but how much of a problem is that, given that any milter user is 
> > at least going to have also the sendmail/postfix policy and the mta 
> > policy too?
> 
> It's not a huge problem but I prefer only to install policy modules I
> really need. Everything else is disabled. Also this approach is more
> compliant with the minimal policy:
> http://danwalsh.livejournal.com/26759.html
> 
> > 
> > > Attached is a milter version which behaves like the apache_template(). I
> > > only took care of the dkim-milter but in general this would only mean
> > > some reorganization of all modules ... nothing more. Any cons about
> > > that?
> > 
> > Splitting each milter out into its own module is certainly do-able; 
> > doesn't that add overhead (from having more modules) as well though?
> 
> Hmm I don't think this will be a problem. I believe it is even easier to
> manage. If they are separated in several files it's easier to handle
> them (if there exist really dozens of them).
> 
> > 
> > > If this would be the right way then we could also talk about the
> > > milter_template() naming convention:
> > >
> > > type $1_milter_t
> > >
> > > The apache_template generates slightly different type names:
> > >
> > > type httpd_$1_script_t
> > >
> > > What about changing $1_milter_t to milter_$1_t?
> > 
> > That would make sense given that most types in refpolicy are prefixed 
> > with the module name. There would need to be typealiases added though 
> > for the old names for the benefit of existing users, wouldn't there?
> 
> Good point. I created a couple of aliases.
> 
> Attached is the milter policy with all four modules. What do you think
> about this approach, Paul, Chris?
> 
> Tested again on CentOS 5.3 with strict policy.

Argl, never say never ... I've installed the latest dkim-milter package
from EPEL and some file locations changed. Attached policy for
milter_dkim fixes this ;-)

Tested again on CentOS 5.3 with strict policy.

[-- Attachment #2: milter_dkim.fc --]
[-- Type: text/plain, Size: 500 bytes --]

/etc/mail/dkim-milter/keys(/.*)		gen_context(system_u:object_r:milter_dkim_private_key_t,s0)

/usr/sbin/dkim-filter		--	gen_context(system_u:object_r:milter_dkim_exec_t,s0)

/var/db/dkim(/.*)?			gen_context(system_u:object_r:milter_dkim_private_key_t,s0)

/var/run/dkim-filter(/.*)?		gen_context(system_u:object_r:milter_dkim_data_t,s0)
/var/run/dkim-milter(/.*)?		gen_context(system_u:object_r:milter_dkim_data_t,s0)
/var/run/dkim-milter\.pid	--	gen_context(system_u:object_r:milter_dkim_data_t,s0)

[-- Attachment #3: milter_dkim.te --]
[-- Type: text/plain, Size: 621 bytes --]


policy_module(milter_dkim, 1.0.0)

########################################
#
# Declarations
#

milter_template(dkim)

# Type for the private key of dkim-filter
type milter_dkim_private_key_t;
files_type(milter_dkim_private_key_t)

########################################
#
# Local policy
#

allow milter_dkim_t self:capability { setgid setuid };

read_files_pattern(milter_dkim_t, milter_dkim_private_key_t, milter_dkim_private_key_t)

files_read_etc_files(milter_dkim_t)

kernel_read_kernel_sysctls(milter_dkim_t)

sysnet_dns_name_resolve(milter_dkim_t)

dev_read_urand(milter_dkim_t)

mta_read_config(milter_dkim_t)

Re: [refpolicy] new policy for dkim-filter

[Christopher J. PeBenito]

On Fri, 2009-09-11 at 16:18 +0100, Paul Howarth wrote:
> On 11/09/09 15:22, Stefan Schulze Frielinghaus wrote:
> > On Fri, 2009-09-11 at 08:30 -0400, Chris PeBenito wrote:
> >> On Fri, 2009-09-11 at 10:20 +0200, Stefan Schulze Frielinghaus wrote:
> >>>>>>>> On Thu, 10 Sep 2009 21:40:56 +0200
> >>>>>>>> Stefan Schulze Frielinghaus<stefan@seekline.net>  wrote:
> >>>>>>>>
> >>>>>>>>> Attached is a new policy for the dkim-filter application.
> >>>>>>>>>
> >>>>>>>>> Chris, is the policy OK/ready for merge?
> >>
> >>> Tested attached policy again on CentOS 5.3 with strict policy.
> >>
> >> It looks ok.  However I'm starting to get concerned about the milter
> >> module getting big.  If you want, say the spamassassin milter, you add
> >> the milter module... but then you get rules for a several other milters
> >> too.
> 
> True, but how much of a problem is that, given that any milter user is 
> at least going to have also the sendmail/postfix policy and the mta 
> policy too?

Perhaps not.  But how many milters are there?  I don't want to get to
the point where there are 10-20 milters in the same module.

> > Attached is a milter version which behaves like the apache_template(). I
> > only took care of the dkim-milter but in general this would only mean
> > some reorganization of all modules ... nothing more. Any cons about
> > that?
> 
> Splitting each milter out into its own module is certainly do-able; 
> doesn't that add overhead (from having more modules) as well though?

Only a little disk space and some memory during policy linking.  No
overhead for the final policy, which is what I'm concerned about.

> > If this would be the right way then we could also talk about the
> > milter_template() naming convention:
> >
> > type $1_milter_t
> >
> > The apache_template generates slightly different type names:
> >
> > type httpd_$1_script_t
> >
> > What about changing $1_milter_t to milter_$1_t?
> 
> That would make sense given that most types in refpolicy are prefixed 
> with the module name. There would need to be typealiases added though 
> for the old names for the benefit of existing users, wouldn't there?

Yes.  But I'd prefer to keep the current naming convention.  I consider
the apache convention nonstandard.

-- 
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] new policy for dkim-filter

[Paul Howarth]

On 14/09/09 14:01, Christopher J. PeBenito wrote:
> On Fri, 2009-09-11 at 16:18 +0100, Paul Howarth wrote:
>> On 11/09/09 15:22, Stefan Schulze Frielinghaus wrote:
>>> On Fri, 2009-09-11 at 08:30 -0400, Chris PeBenito wrote:
>>>> On Fri, 2009-09-11 at 10:20 +0200, Stefan Schulze Frielinghaus wrote:
>>>>>>>>>> On Thu, 10 Sep 2009 21:40:56 +0200
>>>>>>>>>> Stefan Schulze Frielinghaus<stefan@seekline.net>   wrote:
>>>>>>>>>>
>>>>>>>>>>> Attached is a new policy for the dkim-filter application.
>>>>>>>>>>>
>>>>>>>>>>> Chris, is the policy OK/ready for merge?
>>>>
>>>>> Tested attached policy again on CentOS 5.3 with strict policy.
>>>>
>>>> It looks ok.  However I'm starting to get concerned about the milter
>>>> module getting big.  If you want, say the spamassassin milter, you add
>>>> the milter module... but then you get rules for a several other milters
>>>> too.
>>
>> True, but how much of a problem is that, given that any milter user is
>> at least going to have also the sendmail/postfix policy and the mta
>> policy too?
>
> Perhaps not.  But how many milters are there?  I don't want to get to
> the point where there are 10-20 milters in the same module.

Having that many milters is quite conceivable:

https://www.milter.org/milters

>>> Attached is a milter version which behaves like the apache_template(). I
>>> only took care of the dkim-milter but in general this would only mean
>>> some reorganization of all modules ... nothing more. Any cons about
>>> that?
>>
>> Splitting each milter out into its own module is certainly do-able;
>> doesn't that add overhead (from having more modules) as well though?
>
> Only a little disk space and some memory during policy linking.  No
> overhead for the final policy, which is what I'm concerned about.
>
>>> If this would be the right way then we could also talk about the
>>> milter_template() naming convention:
>>>
>>> type $1_milter_t
>>>
>>> The apache_template generates slightly different type names:
>>>
>>> type httpd_$1_script_t
>>>
>>> What about changing $1_milter_t to milter_$1_t?
>>
>> That would make sense given that most types in refpolicy are prefixed
>> with the module name. There would need to be typealiases added though
>> for the old names for the benefit of existing users, wouldn't there?
>
> Yes.  But I'd prefer to keep the current naming convention.  I consider
> the apache convention nonstandard.

Let's split each milter off into its own module then, leaving the type 
names unchanged.

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] new policy for dkim-filter

[Christopher J. PeBenito]

On Mon, 2009-09-14 at 14:41 +0100, Paul Howarth wrote:
> On 14/09/09 14:01, Christopher J. PeBenito wrote:
> > On Fri, 2009-09-11 at 16:18 +0100, Paul Howarth wrote:
> >> On 11/09/09 15:22, Stefan Schulze Frielinghaus wrote:
> >>> On Fri, 2009-09-11 at 08:30 -0400, Chris PeBenito wrote:
> >>>> On Fri, 2009-09-11 at 10:20 +0200, Stefan Schulze Frielinghaus wrote:
> >>>>>>>>>> On Thu, 10 Sep 2009 21:40:56 +0200
> >>>>>>>>>> Stefan Schulze Frielinghaus<stefan@seekline.net>   wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Attached is a new policy for the dkim-filter application.
> >>>>>>>>>>>
> >>>>>>>>>>> Chris, is the policy OK/ready for merge?
> >>>>
> >>>>> Tested attached policy again on CentOS 5.3 with strict policy.
> >>>>
> >>>> It looks ok.  However I'm starting to get concerned about the milter
> >>>> module getting big.  If you want, say the spamassassin milter, you add
> >>>> the milter module... but then you get rules for a several other milters
> >>>> too.
> >>
> >> True, but how much of a problem is that, given that any milter user is
> >> at least going to have also the sendmail/postfix policy and the mta
> >> policy too?
> >
> > Perhaps not.  But how many milters are there?  I don't want to get to
> > the point where there are 10-20 milters in the same module.
> 
> Having that many milters is quite conceivable:
> 
> https://www.milter.org/milters
> 
> >>> Attached is a milter version which behaves like the apache_template(). I
> >>> only took care of the dkim-milter but in general this would only mean
> >>> some reorganization of all modules ... nothing more. Any cons about
> >>> that?
> >>
> >> Splitting each milter out into its own module is certainly do-able;
> >> doesn't that add overhead (from having more modules) as well though?
> >
> > Only a little disk space and some memory during policy linking.  No
> > overhead for the final policy, which is what I'm concerned about.
> >
> >>> If this would be the right way then we could also talk about the
> >>> milter_template() naming convention:
> >>>
> >>> type $1_milter_t
> >>>
> >>> The apache_template generates slightly different type names:
> >>>
> >>> type httpd_$1_script_t
> >>>
> >>> What about changing $1_milter_t to milter_$1_t?
> >>
> >> That would make sense given that most types in refpolicy are prefixed
> >> with the module name. There would need to be typealiases added though
> >> for the old names for the benefit of existing users, wouldn't there?
> >
> > Yes.  But I'd prefer to keep the current naming convention.  I consider
> > the apache convention nonstandard.
> 
> Let's split each milter off into its own module then, leaving the type 
> names unchanged.

We'll do this for new milters.  The ones that are currently in the
milter module will stay for now, since its problematic moving types
between modules.

-- 
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] new policy for dkim-filter

[Stefan Schulze Frielinghaus]

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

On Tue, 2009-09-15 at 09:39 -0400, Christopher J. PeBenito wrote:
> On Mon, 2009-09-14 at 14:41 +0100, Paul Howarth wrote:
> > On 14/09/09 14:01, Christopher J. PeBenito wrote:
> > > On Fri, 2009-09-11 at 16:18 +0100, Paul Howarth wrote:
> > >> On 11/09/09 15:22, Stefan Schulze Frielinghaus wrote:
> > >>> On Fri, 2009-09-11 at 08:30 -0400, Chris PeBenito wrote:
> > >>>> On Fri, 2009-09-11 at 10:20 +0200, Stefan Schulze Frielinghaus wrote:
> > >>>>>>>>>> On Thu, 10 Sep 2009 21:40:56 +0200
> > >>>>>>>>>> Stefan Schulze Frielinghaus<stefan@seekline.net>   wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> Attached is a new policy for the dkim-filter application.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Chris, is the policy OK/ready for merge?
> > >>>>
> > >>>>> Tested attached policy again on CentOS 5.3 with strict policy.
> > >>>>
> > >>>> It looks ok.  However I'm starting to get concerned about the milter
> > >>>> module getting big.  If you want, say the spamassassin milter, you add
> > >>>> the milter module... but then you get rules for a several other milters
> > >>>> too.
> > >>
> > >> True, but how much of a problem is that, given that any milter user is
> > >> at least going to have also the sendmail/postfix policy and the mta
> > >> policy too?
> > >
> > > Perhaps not.  But how many milters are there?  I don't want to get to
> > > the point where there are 10-20 milters in the same module.
> > 
> > Having that many milters is quite conceivable:
> > 
> > https://www.milter.org/milters
> > 
> > >>> Attached is a milter version which behaves like the apache_template(). I
> > >>> only took care of the dkim-milter but in general this would only mean
> > >>> some reorganization of all modules ... nothing more. Any cons about
> > >>> that?
> > >>
> > >> Splitting each milter out into its own module is certainly do-able;
> > >> doesn't that add overhead (from having more modules) as well though?
> > >
> > > Only a little disk space and some memory during policy linking.  No
> > > overhead for the final policy, which is what I'm concerned about.
> > >
> > >>> If this would be the right way then we could also talk about the
> > >>> milter_template() naming convention:
> > >>>
> > >>> type $1_milter_t
> > >>>
> > >>> The apache_template generates slightly different type names:
> > >>>
> > >>> type httpd_$1_script_t
> > >>>
> > >>> What about changing $1_milter_t to milter_$1_t?
> > >>
> > >> That would make sense given that most types in refpolicy are prefixed
> > >> with the module name. There would need to be typealiases added though
> > >> for the old names for the benefit of existing users, wouldn't there?
> > >
> > > Yes.  But I'd prefer to keep the current naming convention.  I consider
> > > the apache convention nonstandard.
> > 
> > Let's split each milter off into its own module then, leaving the type 
> > names unchanged.
> 
> We'll do this for new milters.  The ones that are currently in the
> milter module will stay for now, since its problematic moving types
> between modules.

Attached is a policy for DKIM-Milter based on the latest changes. Works
fine with the default milter policy.

[-- Attachment #2: dkim_milter.fc --]
[-- Type: text/plain, Size: 500 bytes --]

/etc/mail/dkim-milter/keys(/.*)?	gen_context(system_u:object_r:dkim_milter_private_key_t,s0)

/usr/sbin/dkim-filter		--	gen_context(system_u:object_r:dkim_milter_exec_t,s0)

/var/db/dkim(/.*)?			gen_context(system_u:object_r:dkim_milter_private_key_t,s0)

/var/run/dkim-filter(/.*)?		gen_context(system_u:object_r:dkim_milter_data_t,s0)
/var/run/dkim-milter(/.*)?		gen_context(system_u:object_r:dkim_milter_data_t,s0)
/var/run/dkim-milter\.pid	--	gen_context(system_u:object_r:dkim_milter_data_t,s0)

[-- Attachment #3: dkim_milter.te --]
[-- Type: text/plain, Size: 621 bytes --]


policy_module(dkim_milter, 1.0.0)

########################################
#
# Declarations
#

milter_template(dkim)

# Type for the private key of dkim-filter
type dkim_milter_private_key_t;
files_type(dkim_milter_private_key_t)

########################################
#
# Local policy
#

allow dkim_milter_t self:capability { setgid setuid };

read_files_pattern(dkim_milter_t, dkim_milter_private_key_t, dkim_milter_private_key_t)

files_read_etc_files(dkim_milter_t)

kernel_read_kernel_sysctls(dkim_milter_t)

sysnet_dns_name_resolve(dkim_milter_t)

dev_read_urand(dkim_milter_t)

mta_read_config(dkim_milter_t)

Re: [refpolicy] new policy for dkim-filter

[Christopher J. PeBenito]

On Wed, 2009-09-16 at 17:32 +0200, Stefan Schulze Frielinghaus wrote:
> On Tue, 2009-09-15 at 09:39 -0400, Christopher J. PeBenito wrote:
> > On Mon, 2009-09-14 at 14:41 +0100, Paul Howarth wrote:
> > > On 14/09/09 14:01, Christopher J. PeBenito wrote:
> > > > On Fri, 2009-09-11 at 16:18 +0100, Paul Howarth wrote:
> > > >> On 11/09/09 15:22, Stefan Schulze Frielinghaus wrote:
> > > >>> On Fri, 2009-09-11 at 08:30 -0400, Chris PeBenito wrote:
> > > >>>> On Fri, 2009-09-11 at 10:20 +0200, Stefan Schulze Frielinghaus wrote:
> > > >>>>>>>>>> On Thu, 10 Sep 2009 21:40:56 +0200
> > > >>>>>>>>>> Stefan Schulze Frielinghaus<stefan@seekline.net>   wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>>> Attached is a new policy for the dkim-filter application.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Chris, is the policy OK/ready for merge?
> > > >>>>
> > > >>>>> Tested attached policy again on CentOS 5.3 with strict policy.
> > > >>>>
> > > >>>> It looks ok.  However I'm starting to get concerned about the milter
> > > >>>> module getting big.  If you want, say the spamassassin milter, you add
> > > >>>> the milter module... but then you get rules for a several other milters
> > > >>>> too.
> > > >>
> > > >> True, but how much of a problem is that, given that any milter user is
> > > >> at least going to have also the sendmail/postfix policy and the mta
> > > >> policy too?
> > > >
> > > > Perhaps not.  But how many milters are there?  I don't want to get to
> > > > the point where there are 10-20 milters in the same module.
> > > 
> > > Having that many milters is quite conceivable:
> > > 
> > > https://www.milter.org/milters
> > > 
> > > >>> Attached is a milter version which behaves like the apache_template(). I
> > > >>> only took care of the dkim-milter but in general this would only mean
> > > >>> some reorganization of all modules ... nothing more. Any cons about
> > > >>> that?
> > > >>
> > > >> Splitting each milter out into its own module is certainly do-able;
> > > >> doesn't that add overhead (from having more modules) as well though?
> > > >
> > > > Only a little disk space and some memory during policy linking.  No
> > > > overhead for the final policy, which is what I'm concerned about.
> > > >
> > > >>> If this would be the right way then we could also talk about the
> > > >>> milter_template() naming convention:
> > > >>>
> > > >>> type $1_milter_t
> > > >>>
> > > >>> The apache_template generates slightly different type names:
> > > >>>
> > > >>> type httpd_$1_script_t
> > > >>>
> > > >>> What about changing $1_milter_t to milter_$1_t?
> > > >>
> > > >> That would make sense given that most types in refpolicy are prefixed
> > > >> with the module name. There would need to be typealiases added though
> > > >> for the old names for the benefit of existing users, wouldn't there?
> > > >
> > > > Yes.  But I'd prefer to keep the current naming convention.  I consider
> > > > the apache convention nonstandard.
> > > 
> > > Let's split each milter off into its own module then, leaving the type 
> > > names unchanged.
> > 
> > We'll do this for new milters.  The ones that are currently in the
> > milter module will stay for now, since its problematic moving types
> > between modules.
> 
> Attached is a policy for DKIM-Milter based on the latest changes. Works
> fine with the default milter policy.

Merged as dkim.  In the future please include a .if file, even if its
just the <summary> line.

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