This is a new strict policy for the DCC spam filter. It is based on the selinux-policy-strict-sources-1.23.2-1 fedora RPM. This policy requires the definition of dcc reserved ports that were in the net_contexts diff I sent last Wednesday. Please let me know if there are any problems with or changes needed to this policy.
David
Merged into the SELinux policy CVS tree at sourceforge.
On Mon, 2005-03-21 at 20:23 -0500, David Hampton wrote:
This is a new strict policy for the DCC spam filter. It is based on the selinux-policy-strict-sources-1.23.2-1 fedora RPM. This policy requires the definition of dcc reserved ports that were in the net_contexts diff I sent last Wednesday. Please let me know if there are any problems with or changes needed to this policy.
David
On Tuesday 22 March 2005 12:23, David Hampton hampton-rh@rainbolthampton.net wrote:
This is a new strict policy for the DCC spam filter. It is based on the selinux-policy-strict-sources-1.23.2-1 fedora RPM. This policy requires the definition of dcc reserved ports that were in the net_contexts diff I sent last Wednesday. Please let me know if there are any problems with or changes needed to this policy.
Firstly daemons should not be started with su. For correct handling of terminal file handles you should use /sbin/runuser to change the UID, it also requires less policy which makes things easier.
Why do you use init_service_domain() and domain_auto_trans(initrc_t, dcc_script_exec_t, dcc_script_t)?
Surely the daemon is to be started either from inittab or from an /etc/init.d script but not both.
Putting a unix domain socket in /etc is wrong. Among other things it will probably break things for anyone who wants to run with a read-only root file system.
Types used under the /var/run directory generally should have the pidfile attribute so that they can be cleaned up by boot scripts if necessary.
There is a type dccm_sock_t defined which is not in the .fc file.
Allowing access to sshd_t:fd is not what you want, you want to use privfd:fd to allow the administrator to use a console login. Also you want to use admin_tty_type:chr_file instead of sysadm_devpts_t:chr_file for the same reason.
I have attached some patches, but I think that more will need to be done.
For starters I don't think that there is a good cause for seven domains. Postfix has the current record with 13 domains and I believe that Postfix has too many, one of the reasons why I asked Tresys to add a feature to apol to compare the access granted to domains was to determine which domains of Postfix are not needed.
Without even knowing what DCC does I feel confident in guessing that it's not nearly half as complex as Postfix and doesn't need so many domains. Excessive domains makes the policy difficult to analyse. For starters dccifd_t and dccm_t can be merged.
On Fri, 2005-04-22 at 00:54 +1000, Russell Coker wrote:
Firstly daemons should not be started with su.
Agreed, but thats how the designer of DCC implemented it.
Why do you use init_service_domain() and domain_auto_trans(initrc_t, dcc_script_exec_t, dcc_script_t)?
Surely the daemon is to be started either from inittab or from an /etc/init.d script but not both.
Its started from /etc/init.d or by hand. I'll correct the policy to remove init_service_domain.
Putting a unix domain socket in /etc is wrong. Among other things it will probably break things for anyone who wants to run with a read-only root file system.
Agreed. This was moved from /var/dcc to /etc by the packager. I've submitted a patch to restore it to the /var/dcc directory. In the mean time I wrote the policy to work with either location.
Types used under the /var/run directory generally should have the pidfile attribute so that they can be cleaned up by boot scripts if necessary.
Thanks, will do.
There is a type dccm_sock_t defined which is not in the .fc file.
I missed this in my initial submission.
Allowing access to sshd_t:fd is not what you want, you want to use privfd:fd to allow the administrator to use a console login. Also you want to use admin_tty_type:chr_file instead of sysadm_devpts_t:chr_file for the same reason.
Will do. I'll update this in all my policies.
Without even knowing what DCC does
Spam filtering based upon message checksums.
I feel confident in guessing that it's not nearly half as complex as Postfix and doesn't need so many domains. Excessive domains makes the policy difficult to analyse. For starters dccifd_t and dccm_t can be merged.
I have no problem reducing the number of domains. I got the impression somewhere that each executable should be its own domain. Would three domains be reasonable (the server, clients that connect to the server, everything else), or just two (executables that access the network and the utility programs)?
David
On Monday 25 April 2005 21:14, David Hampton hampton-rh@rainbolthampton.net wrote:
On Fri, 2005-04-22 at 00:54 +1000, Russell Coker wrote:
Firstly daemons should not be started with su.
Agreed, but thats how the designer of DCC implemented it.
So it's up to the distribution maintainers (people such as us) to correct this mistake.
Why do you use init_service_domain() and domain_auto_trans(initrc_t, dcc_script_exec_t, dcc_script_t)?
Surely the daemon is to be started either from inittab or from an /etc/init.d script but not both.
Its started from /etc/init.d or by hand. I'll correct the policy to remove init_service_domain.
OK, then daemon_base_domain() or daemon_domain() is what you want.
Putting a unix domain socket in /etc is wrong. Among other things it will probably break things for anyone who wants to run with a read-only root file system.
Agreed. This was moved from /var/dcc to /etc by the packager. I've submitted a patch to restore it to the /var/dcc directory. In the mean time I wrote the policy to work with either location.
OK, but when you publish policy please publish it to work with the fixed package.
I feel confident in guessing that it's not nearly half as complex as Postfix and doesn't need so many domains. Excessive domains makes the policy difficult to analyse. For starters dccifd_t and dccm_t can be merged.
I have no problem reducing the number of domains. I got the impression somewhere that each executable should be its own domain. Would three domains be reasonable (the server, clients that connect to the server, everything else), or just two (executables that access the network and the utility programs)?
Try it with three. Once I see working policy for three domains I can make a better judgement as to whether it would be best expressed as two domains.
selinux@lists.fedoraproject.org