Moving to refpolicy list.
On Wed, 2008-10-08 at 14:05 +0100, Paul Howarth wrote:
> Christopher J. PeBenito wrote:
> > On Mon, 2008-09-22 at 13:27 +0100, Paul Howarth wrote:
> >> Updated patch: sendmail, when run as "newaliases", tries to getattr()
> >> milter sockets as well as the directories they live in, so I changed
> >> the
> >> milter_getattr_all_data_dirs interface to milter_getattr_all_sockets.
> >>
> >> I also moved the call to this interface in mta.te out from the middle
> >> of
> >> a bunch of postfix-related lines.
> >>
> >> Paul.
> >
> > I think my last two comments are
> >
> > * you can't require milter_port_t. It doesn't seem like a generic port
> > type would be useful anyway, otherwise there would be a port defined.
>
> So I should change "allow milter_$1_t milter_port_t:tcp_socket
> name_bind;" to "corenet_tcp_bind_generic_port($1_milter_t)"?
No. I don't see how it makes sense to have a port type common to all
milters.
> I can do that but I don't understand why milter_port_t should be any
> different than say stunnel_port_t, which also doesn't have a default
> port defined, and would be used in a similar way, i.e. an admin would
> set up an application to use a specific port (a milter running over tcp
> needs to have a port specified, just a tunnel set up using stunnel does
> - they don't just bind to random generic ports).
This is not comparable, as there is only one stunnel domain, whereas
there are several milter domains.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
On Wed, 8 Oct 2008 15:22:25 -0400
"Christopher J. PeBenito" <[email protected]> wrote:
> Moving to refpolicy list.
>
> On Wed, 2008-10-08 at 14:05 +0100, Paul Howarth wrote:
> > Christopher J. PeBenito wrote:
> > > On Mon, 2008-09-22 at 13:27 +0100, Paul Howarth wrote:
> > >> Updated patch: sendmail, when run as "newaliases", tries to
> > >> getattr() milter sockets as well as the directories they live
> > >> in, so I changed the
> > >> milter_getattr_all_data_dirs interface to
> > >> milter_getattr_all_sockets.
> > >>
> > >> I also moved the call to this interface in mta.te out from the
> > >> middle of
> > >> a bunch of postfix-related lines.
> > >>
> > >> Paul.
> > >
> > > I think my last two comments are
> > >
> > > * you can't require milter_port_t. It doesn't seem like a
> > > generic port type would be useful anyway, otherwise there would
> > > be a port defined.
> >
> > So I should change "allow milter_$1_t milter_port_t:tcp_socket
> > name_bind;" to "corenet_tcp_bind_generic_port($1_milter_t)"?
>
> No. I don't see how it makes sense to have a port type common to all
> milters.
>
> > I can do that but I don't understand why milter_port_t should be
> > any different than say stunnel_port_t, which also doesn't have a
> > default port defined, and would be used in a similar way, i.e. an
> > admin would set up an application to use a specific port (a milter
> > running over tcp needs to have a port specified, just a tunnel set
> > up using stunnel does
> > - they don't just bind to random generic ports).
>
> This is not comparable, as there is only one stunnel domain, whereas
> there are several milter domains.
OK, I get that now, I'll use $1_milter_port_t instead then. But the
question then arises: how to interface to it? You say I can't require
milter_port_t and I guess that applies to $1_milter_port_t too.
However, as there are no defined ports for these types, there's no
expansion of network_port() for these types from corenetwork.te.in and
hence no corenet_tcp_bind_$1_milter_port interface for me to call. I
got the "require milter_port_t" idea from a similar structure in the
stunnel policy.
How to proceed with this?
Paul.
On Fri, 2008-10-10 at 19:24 +0100, Paul Howarth wrote:
> On Wed, 8 Oct 2008 15:22:25 -0400
> "Christopher J. PeBenito" <[email protected]> wrote:
>
> > Moving to refpolicy list.
> >
> > On Wed, 2008-10-08 at 14:05 +0100, Paul Howarth wrote:
> > > Christopher J. PeBenito wrote:
> > > > On Mon, 2008-09-22 at 13:27 +0100, Paul Howarth wrote:
> > > >> Updated patch: sendmail, when run as "newaliases", tries to
> > > >> getattr() milter sockets as well as the directories they live
> > > >> in, so I changed the
> > > >> milter_getattr_all_data_dirs interface to
> > > >> milter_getattr_all_sockets.
> > > >>
> > > >> I also moved the call to this interface in mta.te out from the
> > > >> middle of
> > > >> a bunch of postfix-related lines.
> > > >>
> > > >> Paul.
> > > >
> > > > I think my last two comments are
> > > >
> > > > * you can't require milter_port_t. It doesn't seem like a
> > > > generic port type would be useful anyway, otherwise there would
> > > > be a port defined.
> > >
> > > So I should change "allow milter_$1_t milter_port_t:tcp_socket
> > > name_bind;" to "corenet_tcp_bind_generic_port($1_milter_t)"?
> >
> > No. I don't see how it makes sense to have a port type common to all
> > milters.
> >
> > > I can do that but I don't understand why milter_port_t should be
> > > any different than say stunnel_port_t, which also doesn't have a
> > > default port defined, and would be used in a similar way, i.e. an
> > > admin would set up an application to use a specific port (a milter
> > > running over tcp needs to have a port specified, just a tunnel set
> > > up using stunnel does
> > > - they don't just bind to random generic ports).
> >
> > This is not comparable, as there is only one stunnel domain, whereas
> > there are several milter domains.
>
> OK, I get that now, I'll use $1_milter_port_t instead then. But the
> question then arises: how to interface to it? You say I can't require
> milter_port_t and I guess that applies to $1_milter_port_t too.
> However, as there are no defined ports for these types, there's no
> expansion of network_port() for these types from corenetwork.te.in and
> hence no corenet_tcp_bind_$1_milter_port interface for me to call. I
> got the "require milter_port_t" idea from a similar structure in the
> stunnel policy.
>
> How to proceed with this?
Sorry for the slow response; I've been consumed with the UBAC stuff.
I'd say don't declare the port in the template and we'll add ports as
milters require them.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
Christopher J. PeBenito wrote:
> On Fri, 2008-10-10 at 19:24 +0100, Paul Howarth wrote:
>> On Wed, 8 Oct 2008 15:22:25 -0400
>> "Christopher J. PeBenito" <[email protected]> wrote:
>>
>>> Moving to refpolicy list.
>>>
>>> On Wed, 2008-10-08 at 14:05 +0100, Paul Howarth wrote:
>>>> Christopher J. PeBenito wrote:
>>>>> On Mon, 2008-09-22 at 13:27 +0100, Paul Howarth wrote:
>>>>>> Updated patch: sendmail, when run as "newaliases", tries to
>>>>>> getattr() milter sockets as well as the directories they live
>>>>>> in, so I changed the
>>>>>> milter_getattr_all_data_dirs interface to
>>>>>> milter_getattr_all_sockets.
>>>>>>
>>>>>> I also moved the call to this interface in mta.te out from the
>>>>>> middle of
>>>>>> a bunch of postfix-related lines.
>>>>>>
>>>>>> Paul.
>>>>> I think my last two comments are
>>>>>
>>>>> * you can't require milter_port_t. It doesn't seem like a
>>>>> generic port type would be useful anyway, otherwise there would
>>>>> be a port defined.
>>>> So I should change "allow milter_$1_t milter_port_t:tcp_socket
>>>> name_bind;" to "corenet_tcp_bind_generic_port($1_milter_t)"?
>>> No. I don't see how it makes sense to have a port type common to all
>>> milters.
>>>
>>>> I can do that but I don't understand why milter_port_t should be
>>>> any different than say stunnel_port_t, which also doesn't have a
>>>> default port defined, and would be used in a similar way, i.e. an
>>>> admin would set up an application to use a specific port (a milter
>>>> running over tcp needs to have a port specified, just a tunnel set
>>>> up using stunnel does
>>>> - they don't just bind to random generic ports).
>>> This is not comparable, as there is only one stunnel domain, whereas
>>> there are several milter domains.
>> OK, I get that now, I'll use $1_milter_port_t instead then. But the
>> question then arises: how to interface to it? You say I can't require
>> milter_port_t and I guess that applies to $1_milter_port_t too.
>> However, as there are no defined ports for these types, there's no
>> expansion of network_port() for these types from corenetwork.te.in and
>> hence no corenet_tcp_bind_$1_milter_port interface for me to call. I
>> got the "require milter_port_t" idea from a similar structure in the
>> stunnel policy.
>>
>> How to proceed with this?
>
> Sorry for the slow response; I've been consumed with the UBAC stuff.
>
> I'd say don't declare the port in the template and we'll add ports as
> milters require them.
It's not a case of one milter needing it and another not needing it;
potentially any milter can be used in conjunction with TCP ports. The
usual convention is to use a unix domain socket for communication
between a milter and the MTA but the milter library supports both
approaches, and some sysadmins may wish to configure their milters to
use TCP sockets, so that for instance they can run the milters on
separate hosts from the MTA in order to spread load. When they do this,
each milter will need support in policy, which is why I included it in
the template.
Paul.
On Thu, 2008-11-06 at 15:24 +0000, Paul Howarth wrote:
> Christopher J. PeBenito wrote:
> > On Fri, 2008-10-10 at 19:24 +0100, Paul Howarth wrote:
> >> On Wed, 8 Oct 2008 15:22:25 -0400
> >> "Christopher J. PeBenito" <[email protected]> wrote:
> >>
> >>> Moving to refpolicy list.
> >>>
> >>> On Wed, 2008-10-08 at 14:05 +0100, Paul Howarth wrote:
> >>>> Christopher J. PeBenito wrote:
> >>>>> On Mon, 2008-09-22 at 13:27 +0100, Paul Howarth wrote:
> >>>>>> Updated patch: sendmail, when run as "newaliases", tries to
> >>>>>> getattr() milter sockets as well as the directories they live
> >>>>>> in, so I changed the
> >>>>>> milter_getattr_all_data_dirs interface to
> >>>>>> milter_getattr_all_sockets.
> >>>>>>
> >>>>>> I also moved the call to this interface in mta.te out from the
> >>>>>> middle of
> >>>>>> a bunch of postfix-related lines.
> >>>>>>
> >>>>>> Paul.
> >>>>> I think my last two comments are
> >>>>>
> >>>>> * you can't require milter_port_t. It doesn't seem like a
> >>>>> generic port type would be useful anyway, otherwise there would
> >>>>> be a port defined.
> >>>> So I should change "allow milter_$1_t milter_port_t:tcp_socket
> >>>> name_bind;" to "corenet_tcp_bind_generic_port($1_milter_t)"?
> >>> No. I don't see how it makes sense to have a port type common to all
> >>> milters.
> >>>
> >>>> I can do that but I don't understand why milter_port_t should be
> >>>> any different than say stunnel_port_t, which also doesn't have a
> >>>> default port defined, and would be used in a similar way, i.e. an
> >>>> admin would set up an application to use a specific port (a milter
> >>>> running over tcp needs to have a port specified, just a tunnel set
> >>>> up using stunnel does
> >>>> - they don't just bind to random generic ports).
> >>> This is not comparable, as there is only one stunnel domain, whereas
> >>> there are several milter domains.
> >> OK, I get that now, I'll use $1_milter_port_t instead then. But the
> >> question then arises: how to interface to it? You say I can't require
> >> milter_port_t and I guess that applies to $1_milter_port_t too.
> >> However, as there are no defined ports for these types, there's no
> >> expansion of network_port() for these types from corenetwork.te.in and
> >> hence no corenet_tcp_bind_$1_milter_port interface for me to call. I
> >> got the "require milter_port_t" idea from a similar structure in the
> >> stunnel policy.
> >>
> >> How to proceed with this?
> >
> > Sorry for the slow response; I've been consumed with the UBAC stuff.
> >
> > I'd say don't declare the port in the template and we'll add ports as
> > milters require them.
>
> It's not a case of one milter needing it and another not needing it;
> potentially any milter can be used in conjunction with TCP ports. The
> usual convention is to use a unix domain socket for communication
> between a milter and the MTA but the milter library supports both
> approaches, and some sysadmins may wish to configure their milters to
> use TCP sockets, so that for instance they can run the milters on
> separate hosts from the MTA in order to spread load. When they do this,
> each milter will need support in policy, which is why I included it in
> the template.
We can't realistically support all possible configurations. At some
point we have to draw the line on trying. I think the standard
configuration that covers 80%+ of the users is a reasonable starting
point.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
Christopher J. PeBenito wrote:
> On Thu, 2008-11-06 at 15:24 +0000, Paul Howarth wrote:
>> Christopher J. PeBenito wrote:
>>> On Fri, 2008-10-10 at 19:24 +0100, Paul Howarth wrote:
>>>> On Wed, 8 Oct 2008 15:22:25 -0400
>>>> "Christopher J. PeBenito" <[email protected]> wrote:
>>>>
>>>>> Moving to refpolicy list.
>>>>>
>>>>> On Wed, 2008-10-08 at 14:05 +0100, Paul Howarth wrote:
>>>>>> Christopher J. PeBenito wrote:
>>>>>>> On Mon, 2008-09-22 at 13:27 +0100, Paul Howarth wrote:
>>>>>>>> Updated patch: sendmail, when run as "newaliases", tries to
>>>>>>>> getattr() milter sockets as well as the directories they live
>>>>>>>> in, so I changed the
>>>>>>>> milter_getattr_all_data_dirs interface to
>>>>>>>> milter_getattr_all_sockets.
>>>>>>>>
>>>>>>>> I also moved the call to this interface in mta.te out from the
>>>>>>>> middle of
>>>>>>>> a bunch of postfix-related lines.
>>>>>>>>
>>>>>>>> Paul.
>>>>>>> I think my last two comments are
>>>>>>>
>>>>>>> * you can't require milter_port_t. It doesn't seem like a
>>>>>>> generic port type would be useful anyway, otherwise there would
>>>>>>> be a port defined.
>>>>>> So I should change "allow milter_$1_t milter_port_t:tcp_socket
>>>>>> name_bind;" to "corenet_tcp_bind_generic_port($1_milter_t)"?
>>>>> No. I don't see how it makes sense to have a port type common to all
>>>>> milters.
>>>>>
>>>>>> I can do that but I don't understand why milter_port_t should be
>>>>>> any different than say stunnel_port_t, which also doesn't have a
>>>>>> default port defined, and would be used in a similar way, i.e. an
>>>>>> admin would set up an application to use a specific port (a milter
>>>>>> running over tcp needs to have a port specified, just a tunnel set
>>>>>> up using stunnel does
>>>>>> - they don't just bind to random generic ports).
>>>>> This is not comparable, as there is only one stunnel domain, whereas
>>>>> there are several milter domains.
>>>> OK, I get that now, I'll use $1_milter_port_t instead then. But the
>>>> question then arises: how to interface to it? You say I can't require
>>>> milter_port_t and I guess that applies to $1_milter_port_t too.
>>>> However, as there are no defined ports for these types, there's no
>>>> expansion of network_port() for these types from corenetwork.te.in and
>>>> hence no corenet_tcp_bind_$1_milter_port interface for me to call. I
>>>> got the "require milter_port_t" idea from a similar structure in the
>>>> stunnel policy.
>>>>
>>>> How to proceed with this?
>>> Sorry for the slow response; I've been consumed with the UBAC stuff.
>>>
>>> I'd say don't declare the port in the template and we'll add ports as
>>> milters require them.
>> It's not a case of one milter needing it and another not needing it;
>> potentially any milter can be used in conjunction with TCP ports. The
>> usual convention is to use a unix domain socket for communication
>> between a milter and the MTA but the milter library supports both
>> approaches, and some sysadmins may wish to configure their milters to
>> use TCP sockets, so that for instance they can run the milters on
>> separate hosts from the MTA in order to spread load. When they do this,
>> each milter will need support in policy, which is why I included it in
>> the template.
>
> We can't realistically support all possible configurations. At some
> point we have to draw the line on trying. I think the standard
> configuration that covers 80%+ of the users is a reasonable starting
> point.
Updated patch attached with TCP socket support removed.
Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: milters.patch
Type: text/x-patch
Size: 7099 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20081117/a83e17e2/attachment.bin
On Mon, 2008-11-17 at 10:05 -0500, Paul Howarth wrote:
> Updated patch attached with TCP socket support removed.
Last question
> Index: policy/modules/services/mta.te
> ===================================================================
> --- policy/modules/services/mta.te (revision 2878)
> +++ policy/modules/services/mta.te (working copy)
> @@ -116,6 +116,9 @@
>
> domain_use_interactive_fds(system_mail_t)
>
> + # newaliases runs as system_mail_t when the sendmail initscript does a restart
> + milter_getattr_all_sockets(system_mail_t)
> +
> # postfix needs this for newaliases
> files_getattr_tmp_dirs(system_mail_t)
Why is this bit in the optional_policy for postfix instead of its own
optional_policy at the top level?
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
Christopher J. PeBenito wrote:
> On Mon, 2008-11-17 at 10:05 -0500, Paul Howarth wrote:
>> Updated patch attached with TCP socket support removed.
>
> Last question
>
>> Index: policy/modules/services/mta.te
>> ===================================================================
>> --- policy/modules/services/mta.te (revision 2878)
>> +++ policy/modules/services/mta.te (working copy)
>> @@ -116,6 +116,9 @@
>>
>> domain_use_interactive_fds(system_mail_t)
>>
>> + # newaliases runs as system_mail_t when the sendmail initscript does a restart
>> + milter_getattr_all_sockets(system_mail_t)
>> +
>> # postfix needs this for newaliases
>> files_getattr_tmp_dirs(system_mail_t)
>
> Why is this bit in the optional_policy for postfix instead of its own
> optional_policy at the top level?
Not intentional. I saw the similar entry for postfix and put the extra
line near it, not realizing the significance of the multiple
optional_policy blocks.
Revised patch attached.
Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: milters.patch
Type: text/x-patch
Size: 7065 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20081124/1f16af29/attachment.bin
On Mon, 2008-11-24 at 14:34 +0000, Paul Howarth wrote:
> Christopher J. PeBenito wrote:
> > On Mon, 2008-11-17 at 10:05 -0500, Paul Howarth wrote:
> >> Updated patch attached with TCP socket support removed.
> >
> > Last question
> >
> >> Index: policy/modules/services/mta.te
> >> ===================================================================
> >> --- policy/modules/services/mta.te (revision 2878)
> >> +++ policy/modules/services/mta.te (working copy)
> >> @@ -116,6 +116,9 @@
> >>
> >> domain_use_interactive_fds(system_mail_t)
> >>
> >> + # newaliases runs as system_mail_t when the sendmail
> initscript does a restart
> >> + milter_getattr_all_sockets(system_mail_t)
> >> +
> >> # postfix needs this for newaliases
> >> files_getattr_tmp_dirs(system_mail_t)
> >
> > Why is this bit in the optional_policy for postfix instead of its
> own
> > optional_policy at the top level?
>
> Not intentional. I saw the similar entry for postfix and put the
> extra
> line near it, not realizing the significance of the multiple
> optional_policy blocks.
>
> Revised patch attached.
Merged, with a couple tweaks.
>
>
>
>
>
>
> differences
> between files
> attachment
> (milters.patch)
>
> Index: policy/modules/services/sendmail.te
> ===================================================================
> --- policy/modules/services/sendmail.te (revision 2882)
> +++ policy/modules/services/sendmail.te (working copy)
> @@ -109,6 +109,10 @@
> ')
>
> optional_policy(`
> + milter_stream_connect_all(sendmail_t)
> +')
> +
> +optional_policy(`
> postfix_exec_master(sendmail_t)
> postfix_read_config(sendmail_t)
> postfix_search_spool(sendmail_t)
> Index: policy/modules/services/mta.te
> ===================================================================
> --- policy/modules/services/mta.te (revision 2882)
> +++ policy/modules/services/mta.te (working copy)
> @@ -103,6 +103,11 @@
> ')
>
> optional_policy(`
> + # newaliases runs as system_mail_t when the sendmail
> initscript does a restart
> + milter_getattr_all_sockets(system_mail_t)
> +')
> +
> +optional_policy(`
> nagios_read_tmp_files(system_mail_t)
> ')
>
> Index: policy/modules/services/milter.te
> ===================================================================
> --- policy/modules/services/milter.te (revision 0)
> +++ policy/modules/services/milter.te (revision 0)
> @@ -0,0 +1,54 @@
> +policy_module(milter,0.3.1)
> +
> +########################################
> +#
> +# Declarations
> +#
> +
> +# attributes common to all milters
> +attribute milter_domains;
> +attribute milter_data_type;
> +
> +# currently-supported milters are milter-regex and spamass-milter
> +milter_template(regex)
> +milter_template(spamass)
> +
> +########################################
> +#
> +# milter-regex local policy
> +# filter emails using regular expressions
> +# http://www.benzedrine.cx/milter-regex.html
> +#
> +
> +# Look up username for dropping privs
> +auth_use_nsswitch(regex_milter_t)
> +
> +# Config is in /etc/mail/milter-regex.conf
> +mta_read_config(regex_milter_t)
> +
> +# The milter's socket directory lives under /var/spool
> +files_search_spool(regex_milter_t)
> +
> +# It removes any existing socket (not owned by root) whilst running
> as root
> +# and then calls setgid() and setuid() to drop privileges
> +allow regex_milter_t self:capability { setuid setgid dac_override };
> +
> +
> +########################################
> +#
> +# spamass-milter local policy
> +# pipe emails through SpamAssassin
> +# http://savannah.nongnu.org/projects/spamass-milt/
> +#
> +
> +# The main job of the milter is to pipe spam through spamc and act on
> the result
> +spamassassin_domtrans_spamc(spamass_milter_t)
> +
> +# When used with -b or -B options, the milter invokes sendmail to
> send mail
> +# to a spamtrap address, using popen()
> +corecmd_exec_shell(spamass_milter_t)
> +corecmd_read_bin_symlinks(spamass_milter_t)
> +corecmd_search_bin(spamass_milter_t)
> +kernel_read_system_state(spamass_milter_t)
> +mta_send_mail(spamass_milter_t)
> +
> Index: policy/modules/services/spamassassin.fc
> ===================================================================
> --- policy/modules/services/spamassassin.fc (revision 2882)
> +++ policy/modules/services/spamassassin.fc (working copy)
> @@ -10,7 +10,6 @@
> /var/lib/spamassassin(/.*)? gen_context(system_u:object_r:spamd_var_lib_t,s0)
>
> /var/run/spamassassin(/.*)? gen_context(system_u:object_r:spamd_var_run_t,s0)
> -/var/run/spamass-milter(/.*)? gen_context(system_u:object_r:spamd_var_run_t,s0)
>
> /var/spool/spamassassin(/.*)? gen_context(system_u:object_r:spamd_spool_t,s0)
> /var/spool/spamd(/.*)? gen_context(system_u:object_r:spamd_spool_t,s0)
> Index: policy/modules/services/milter.fc
> ===================================================================
> --- policy/modules/services/milter.fc (revision 0)
> +++ policy/modules/services/milter.fc (revision 0)
> @@ -0,0 +1,7 @@
> +/usr/sbin/milter-regex -- gen_context(system_u:object_r:regex_milter_exec_t,s0)
> +/var/spool/milter-regex(/.*)? gen_context(system_u:object_r:regex_milter_data_t,s0)
> +
> +/usr/sbin/spamass-milter -- gen_context(system_u:object_r:spamass_milter_exec_t,s0)
> +/var/run/spamass-milter(/.*)? gen_context(system_u:object_r:spamass_milter_data_t,s0)
> +/var/run/spamass-milter
> \.pid -- gen_context(system_u:object_r:spamass_milter_data_t,s0)
> +
> Index: policy/modules/services/milter.if
> ===================================================================
> --- policy/modules/services/milter.if (revision 0)
> +++ policy/modules/services/milter.if (revision 0)
> @@ -0,0 +1,86 @@
> +## <summary>Milter mail filters</summary>
> +
> +########################################
> +## <summary>
> +## Create a set of derived types for various
> +## mail filter applications using the milter interface.
> +## </summary>
> +## <param name="milter_name">
> +## <summary>
> +## The name to be used for deriving type names.
> +## </summary>
> +## </param>
> +#
> +template(`milter_template',`
> +
> + # attributes common to all milters
> + gen_require(`
> + attribute milter_data_type, milter_domains;
> + ')
> +
> + # Type that the milter application runs as
> + type $1_milter_t, milter_domains;
> + domain_type($1_milter_t)
> + role system_r types $1_milter_t;
> +
> + # Type for the executable file
> + type $1_milter_exec_t;
> + init_daemon_domain($1_milter_t, $1_milter_exec_t)
> +
> + # Type for the milter data (e.g. the socket used to
> communicate with the MTA)
> + type $1_milter_data_t, milter_data_type;
> + files_type($1_milter_data_t);
> +
> + # Allow communication with MTA over a unix-domain socket
> + # Note: usage with TCP sockets requires additional policy
> + manage_sock_files_pattern($1_milter_t,$1_milter_data_t,
> $1_milter_data_t)
> +
> + # Create other data files and directories in the data
> directory
> + manage_files_pattern($1_milter_t,$1_milter_data_t,
> $1_milter_data_t)
> +
> + # Things that all(?) milters will need to do
> + libs_use_ld_so($1_milter_t)
> + libs_use_shared_libs($1_milter_t)
> + miscfiles_read_localization($1_milter_t)
> + init_use_fds($1_milter_t)
> + allow $1_milter_t self:fifo_file rw_fifo_file_perms;
> + logging_send_syslog_msg($1_milter_t)
> +
> +')
> +
> +########################################
> +## <summary>
> +## MTA communication with milter sockets
> +## </summary>
> +## <param name="domain">
> +## <summary>
> +## Domain allowed access.
> +## </summary>
> +## </param>
> +#
> +interface(`milter_stream_connect_all',`
> + gen_require(`
> + attribute milter_data_type, milter_domains;
> + ')
> + getattr_dirs_pattern($1,milter_data_type,milter_data_type)
> + stream_connect_pattern($1,milter_data_type,milter_data_type,milter_domains)
> +')
> +
> +########################################
> +## <summary>
> +## Allow getattr of milter sockets
> +## </summary>
> +## <param name="domain">
> +## <summary>
> +## Domain allowed access.
> +## </summary>
> +## </param>
> +#
> +interface(`milter_getattr_all_sockets',`
> + gen_require(`
> + attribute milter_data_type;
> + ')
> + getattr_dirs_pattern($1,milter_data_type,milter_data_type)
> + getattr_sock_files_pattern($1,milter_data_type,milter_data_type)
> +')
> +
> Index: policy/modules/services/postfix.te
> ===================================================================
> --- policy/modules/services/postfix.te (revision 2882)
> +++ policy/modules/services/postfix.te (working copy)
> @@ -519,6 +519,10 @@
> cyrus_stream_connect(postfix_smtp_t)
> ')
>
> +optional_policy(`
> + milter_stream_connect_all(postfix_smtp_t)
> +')
> +
> ########################################
> #
> # Postfix smtpd local policy
>
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
Christopher J. PeBenito wrote:
> On Mon, 2008-11-24 at 14:34 +0000, Paul Howarth wrote:
>> Christopher J. PeBenito wrote:
>>> On Mon, 2008-11-17 at 10:05 -0500, Paul Howarth wrote:
>>>> Updated patch attached with TCP socket support removed.
>>> Last question
>>>
>>>> Index: policy/modules/services/mta.te
>>>> ===================================================================
>>>> --- policy/modules/services/mta.te (revision 2878)
>>>> +++ policy/modules/services/mta.te (working copy)
>>>> @@ -116,6 +116,9 @@
>>>>
>>>> domain_use_interactive_fds(system_mail_t)
>>>>
>>>> + # newaliases runs as system_mail_t when the sendmail
>> initscript does a restart
>>>> + milter_getattr_all_sockets(system_mail_t)
>>>> +
>>>> # postfix needs this for newaliases
>>>> files_getattr_tmp_dirs(system_mail_t)
>>> Why is this bit in the optional_policy for postfix instead of its
>> own
>>> optional_policy at the top level?
>> Not intentional. I saw the similar entry for postfix and put the
>> extra
>> line near it, not realizing the significance of the multiple
>> optional_policy blocks.
>>
>> Revised patch attached.
>
> Merged, with a couple tweaks.
The tweaks seem quite significant:
$ diff milter.if.pgh milter.if
21d20
< domain_type($1_milter_t)
39,41d37
< # Things that all(?) milters will need to do
< libs_use_ld_so($1_milter_t)
< libs_use_shared_libs($1_milter_t)
43d38
< init_use_fds($1_milter_t)
Are these four interface calls omitted deliberately?
Paul.
On Mon, 2008-11-24 at 16:07 +0000, Paul Howarth wrote:
> Christopher J. PeBenito wrote:
> > On Mon, 2008-11-24 at 14:34 +0000, Paul Howarth wrote:
> >> Revised patch attached.
> >
> > Merged, with a couple tweaks.
>
> The tweaks seem quite significant:
>
> $ diff milter.if.pgh milter.if
> 21d20
> < domain_type($1_milter_t)
redundant due to init_daemon_domain()
> 39,41d37
> < # Things that all(?) milters will need to do
> < libs_use_ld_so($1_milter_t)
> < libs_use_shared_libs($1_milter_t)
All domains now have these rules (see line 109 of domain.te).
> 43d38
> < init_use_fds($1_milter_t)
Its actually the fd for the console, which isn't necessary to be
inherited, nor would we want used by services. Its dontaudited by
init_daemon_domain().
> Are these four interface calls omitted deliberately?
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150