qmail policy files made by Russel. only a few modifications were made (especially in the file_contexts)
Created attachment 21454 [details] file_contexts
Created attachment 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 attachment 21927 [details] type enforcement latest policy from Russell
Created attachment 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.
