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@xxxxxxxxxxxx> 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.
/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)
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)
