Bugzilla Bug 34674

qmail policy files made by Russel. only a few modifications were made
(especially in the file_contexts)

Created an attachment (id=21454) [details]
file_contexts

Created an attachment (id=21455) [details]
type_enforcement

Does this and your other DJB policies have the updates that I see discussed on
the
SELinux discussion list?

I forsee these needing changes, esp once the EXTTODO patch is applied. Be aware
that we use a _lot_ of patches on our qmail builds, and things setup for a
stock qmail I personally wouldn't expect to work with our builds of it.

pebenito:
i have updated ucspi-tcp as Russel requested.
for the qmail policy, there are 2 remaining issues:
the file_context of ~alias and of /var/qmail/bin/sendmail

robbat2:
very true,

from all those patches I'm only actively using the STARTTLS which did not need any special rule. if you want i can investigate what rules are needed for any other patch.

bye,
peter

Created an attachment (id=21927) [details]
type enforcement

latest policy from Russell

Created an attachment (id=21928) [details]
file contexts

latest policy from Russell (with a few additions)

I'm skeptical of the last two file contexts.  I'm pretty sure mta.fc takes care
of /usr/sbin/sendmail.  And why is /var/qmail/alias(/.*)?   staff_home_t?

> I'm skeptical of the last two file contexts.  I'm pretty sure mta.fc takes care of /usr/sbin/sendmail.  And why is /var/qmail/alias(/.*)?   staff_home_t?

/usr/sbin/sendmail is a symlink on my system (as on any gentoo with qmail):
# ls -al --context /usr/sbin/sendmail
lrwxrwxrwx  root     root     system_u:object_r:sbin_t        
/usr/sbin/sendmail -> /var/qmail/bin/sendmail
(this is how it ends up if I don't use the qmail.fc file context, and I do have
mta.fc enabled. maybe that '--' from the mta.fc definition labels only normal
files? )

after I declare the type in qmail.fc, things go back to normal.

/var/qmail/alias(/.*)? is a place where undelivered mails (and mails to virtual
mailboxes) have to be received (as per
http://www.lifewithqmail.org/lwq.html#aliases). 

It's also used as a place where mails to mailinglists are received by ezmlm
(www.ezmlm.org).

Using staff_home_t makes sure that qmail_local_t will be able to deliver the
mail there without other modifications in qmail.te. Also members of the staff_t
group will be able to control subscriber list moderation and a zilion other
things in ezmlm.

If you feel like sysadm_t should be the one to make these things, use
sysadm_staff_t instead of staff_home_t, but I feel like sysadm_t should be used
only by the main administrator of a server and not by the person that is in
charge with postmaster mails and such (which is staff_t).

I suggest running the /var/qmail/alias(/.*)? stuff by Russell.  My opinion is
that it get its own type, and then its more obvious who can access stuff in
there, and access to it is explicit.

I told Russell twice about the ~alias issue but to no avail.

I would also like to modify qmail.te to include serialmail and qmail-pop3 support, I will send the final version tomorrow.

did you forget to attach your policy with serialmail and qmail-pop3 updates?

I kinda did courier-imap instead.
pmail-pop3 needed some extra password cheking software not covered in portage to authenticate users from other source different from /etc/passwd and /etc/shadow

qmail.te will have to be changed more in order to support .qmail files.

momentarily I'm quitting RAV and relocating to another company so I won't have time to do this in the near future :(

I've committed it to portage as is.  When you or someone else gets a chance, a
new bug can be opened with further enhancements.