The recent update to the rsyncd in -targeted seems to me to be ill conceived.
I'm filing this as a security bug because the effect of the new policy is to get
people to disable it in whole or in part.

Our server configuration is fairly typical of those that use rsyncd: we have
trees that are available via rsyncd that are ALSO available via the webserver.

There are two problems with using the ftpd_anon_t context for rsync:

  1. The name makes no bloody sense, which is a security flaw in its
     own right
  2. In our case, the files in question also need to be httpd_sys_content_t,
     and they cannot be both.

I'm struck that perhaps we need a label that says "this file can be shown to the
world and I really don't care whether it is through apache, ftpd, tftpd, rsyncd,
or tin can and string." Perhaps "public_content_t". Alternatively, we may want a
boolean saying that rsync should accept httpd_sys_content_t as an alternative to
ftpd_anon_t.

More generally, I'm struck that the selinux "one context per file" policy is
creating great difficulty in fashioning any sort of reasonable theory of
operation for how various overlapping programs like this should behave. What is
happening here is that the context selected is two narrow to cover the usage
pattern, with the consequence that selinux is getting in the way of successful
operation.

Is there a complete list of contexts somewhere, along with an explanation of
usage? Shouldn't there be one as part of the policy documentation?

Best regards