* [refpolicy] new policy for dkim-filter
@ 2009-09-10 19:40 Stefan Schulze Frielinghaus
2009-09-10 20:04 ` Paul Howarth
0 siblings, 1 reply; 18+ messages in thread
From: Stefan Schulze Frielinghaus @ 2009-09-10 19:40 UTC (permalink / raw)
To: selinux; +Cc: Christopher J. PeBenito
[-- 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;
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [refpolicy] new policy for dkim-filter 2009-09-10 19:40 [refpolicy] new policy for dkim-filter Stefan Schulze Frielinghaus @ 2009-09-10 20:04 ` Paul Howarth 2009-09-10 20:39 ` Stefan Schulze Frielinghaus 0 siblings, 1 reply; 18+ messages in thread From: Paul Howarth @ 2009-09-10 20:04 UTC (permalink / raw) To: Stefan Schulze Frielinghaus; +Cc: selinux, Christopher J. PeBenito 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [refpolicy] new policy for dkim-filter 2009-09-10 20:04 ` Paul Howarth @ 2009-09-10 20:39 ` Stefan Schulze Frielinghaus 2009-09-10 21:50 ` Stefan Schulze Frielinghaus 0 siblings, 1 reply; 18+ messages in thread From: Stefan Schulze Frielinghaus @ 2009-09-10 20:39 UTC (permalink / raw) To: Paul Howarth; +Cc: selinux, Christopher J. PeBenito 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [refpolicy] new policy for dkim-filter 2009-09-10 20:39 ` Stefan Schulze Frielinghaus @ 2009-09-10 21:50 ` Stefan Schulze Frielinghaus 2009-09-10 22:27 ` Paul Howarth 0 siblings, 1 reply; 18+ messages in thread From: Stefan Schulze Frielinghaus @ 2009-09-10 21:50 UTC (permalink / raw) To: Paul Howarth; +Cc: selinux, Christopher J. PeBenito [-- 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/ ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [refpolicy] new policy for dkim-filter 2009-09-10 21:50 ` Stefan Schulze Frielinghaus @ 2009-09-10 22:27 ` Paul Howarth 2009-09-11 7:53 ` Stefan Schulze Frielinghaus 0 siblings, 1 reply; 18+ messages in thread From: Paul Howarth @ 2009-09-10 22:27 UTC (permalink / raw) To: Stefan Schulze Frielinghaus; +Cc: selinux, Christopher J. PeBenito 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [refpolicy] new policy for dkim-filter 2009-09-10 22:27 ` Paul Howarth @ 2009-09-11 7:53 ` Stefan Schulze Frielinghaus 2009-09-11 8:20 ` Stefan Schulze Frielinghaus 0 siblings, 1 reply; 18+ messages in thread From: Stefan Schulze Frielinghaus @ 2009-09-11 7:53 UTC (permalink / raw) To: Paul Howarth; +Cc: selinux, Christopher J. PeBenito [-- 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/ ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [refpolicy] new policy for dkim-filter 2009-09-11 7:53 ` Stefan Schulze Frielinghaus @ 2009-09-11 8:20 ` Stefan Schulze Frielinghaus 2009-09-11 12:30 ` Chris PeBenito 0 siblings, 1 reply; 18+ messages in thread From: Stefan Schulze Frielinghaus @ 2009-09-11 8:20 UTC (permalink / raw) To: Paul Howarth; +Cc: selinux, Christopher J. PeBenito [-- 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/ ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [refpolicy] new policy for dkim-filter 2009-09-11 8:20 ` Stefan Schulze Frielinghaus @ 2009-09-11 12:30 ` Chris PeBenito 2009-09-11 12:46 ` Stefan Schulze Frielinghaus 2009-09-11 14:22 ` Stefan Schulze Frielinghaus 0 siblings, 2 replies; 18+ messages in thread From: Chris PeBenito @ 2009-09-11 12:30 UTC (permalink / raw) To: Stefan Schulze Frielinghaus; +Cc: Paul Howarth, selinux 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [refpolicy] new policy for dkim-filter 2009-09-11 12:30 ` Chris PeBenito @ 2009-09-11 12:46 ` Stefan Schulze Frielinghaus 2009-09-11 14:22 ` Stefan Schulze Frielinghaus 1 sibling, 0 replies; 18+ messages in thread From: Stefan Schulze Frielinghaus @ 2009-09-11 12:46 UTC (permalink / raw) To: Chris PeBenito; +Cc: Paul Howarth, selinux 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [refpolicy] new policy for dkim-filter 2009-09-11 12:30 ` Chris PeBenito 2009-09-11 12:46 ` Stefan Schulze Frielinghaus @ 2009-09-11 14:22 ` Stefan Schulze Frielinghaus 2009-09-11 15:18 ` Paul Howarth 1 sibling, 1 reply; 18+ messages in thread From: Stefan Schulze Frielinghaus @ 2009-09-11 14:22 UTC (permalink / raw) To: Chris PeBenito; +Cc: Paul Howarth, selinux [-- 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; ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [refpolicy] new policy for dkim-filter 2009-09-11 14:22 ` Stefan Schulze Frielinghaus @ 2009-09-11 15:18 ` Paul Howarth 2009-09-12 12:49 ` Stefan Schulze Frielinghaus 2009-09-14 13:01 ` Christopher J. PeBenito 0 siblings, 2 replies; 18+ messages in thread From: Paul Howarth @ 2009-09-11 15:18 UTC (permalink / raw) To: Stefan Schulze Frielinghaus; +Cc: Chris PeBenito, selinux 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [refpolicy] new policy for dkim-filter 2009-09-11 15:18 ` Paul Howarth @ 2009-09-12 12:49 ` Stefan Schulze Frielinghaus 2009-09-12 14:58 ` Stefan Schulze Frielinghaus 2009-09-14 13:01 ` Christopher J. PeBenito 1 sibling, 1 reply; 18+ messages in thread From: Stefan Schulze Frielinghaus @ 2009-09-12 12:49 UTC (permalink / raw) To: Paul Howarth; +Cc: Chris PeBenito, selinux [-- 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) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [refpolicy] new policy for dkim-filter 2009-09-12 12:49 ` Stefan Schulze Frielinghaus @ 2009-09-12 14:58 ` Stefan Schulze Frielinghaus 0 siblings, 0 replies; 18+ messages in thread From: Stefan Schulze Frielinghaus @ 2009-09-12 14:58 UTC (permalink / raw) To: Paul Howarth; +Cc: Chris PeBenito, selinux [-- 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) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [refpolicy] new policy for dkim-filter 2009-09-11 15:18 ` Paul Howarth 2009-09-12 12:49 ` Stefan Schulze Frielinghaus @ 2009-09-14 13:01 ` Christopher J. PeBenito 2009-09-14 13:41 ` Paul Howarth 1 sibling, 1 reply; 18+ messages in thread From: Christopher J. PeBenito @ 2009-09-14 13:01 UTC (permalink / raw) To: Paul Howarth; +Cc: Stefan Schulze Frielinghaus, selinux 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [refpolicy] new policy for dkim-filter 2009-09-14 13:01 ` Christopher J. PeBenito @ 2009-09-14 13:41 ` Paul Howarth 2009-09-15 13:39 ` Christopher J. PeBenito 0 siblings, 1 reply; 18+ messages in thread From: Paul Howarth @ 2009-09-14 13:41 UTC (permalink / raw) To: Christopher J. PeBenito; +Cc: Stefan Schulze Frielinghaus, selinux 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [refpolicy] new policy for dkim-filter 2009-09-14 13:41 ` Paul Howarth @ 2009-09-15 13:39 ` Christopher J. PeBenito 2009-09-16 15:32 ` Stefan Schulze Frielinghaus 0 siblings, 1 reply; 18+ messages in thread From: Christopher J. PeBenito @ 2009-09-15 13:39 UTC (permalink / raw) To: Paul Howarth; +Cc: Stefan Schulze Frielinghaus, selinux 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [refpolicy] new policy for dkim-filter 2009-09-15 13:39 ` Christopher J. PeBenito @ 2009-09-16 15:32 ` Stefan Schulze Frielinghaus 2009-09-17 13:12 ` Christopher J. PeBenito 0 siblings, 1 reply; 18+ messages in thread From: Stefan Schulze Frielinghaus @ 2009-09-16 15:32 UTC (permalink / raw) To: Christopher J. PeBenito; +Cc: Paul Howarth, selinux [-- 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) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [refpolicy] new policy for dkim-filter 2009-09-16 15:32 ` Stefan Schulze Frielinghaus @ 2009-09-17 13:12 ` Christopher J. PeBenito 0 siblings, 0 replies; 18+ messages in thread From: Christopher J. PeBenito @ 2009-09-17 13:12 UTC (permalink / raw) To: Stefan Schulze Frielinghaus; +Cc: Paul Howarth, selinux 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2009-09-17 13:14 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-09-10 19:40 [refpolicy] new policy for dkim-filter Stefan Schulze Frielinghaus 2009-09-10 20:04 ` Paul Howarth 2009-09-10 20:39 ` Stefan Schulze Frielinghaus 2009-09-10 21:50 ` Stefan Schulze Frielinghaus 2009-09-10 22:27 ` Paul Howarth 2009-09-11 7:53 ` Stefan Schulze Frielinghaus 2009-09-11 8:20 ` Stefan Schulze Frielinghaus 2009-09-11 12:30 ` Chris PeBenito 2009-09-11 12:46 ` Stefan Schulze Frielinghaus 2009-09-11 14:22 ` Stefan Schulze Frielinghaus 2009-09-11 15:18 ` Paul Howarth 2009-09-12 12:49 ` Stefan Schulze Frielinghaus 2009-09-12 14:58 ` Stefan Schulze Frielinghaus 2009-09-14 13:01 ` Christopher J. PeBenito 2009-09-14 13:41 ` Paul Howarth 2009-09-15 13:39 ` Christopher J. PeBenito 2009-09-16 15:32 ` Stefan Schulze Frielinghaus 2009-09-17 13:12 ` Christopher J. PeBenito
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.