Re: New policy for DCC
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