The current policy doesn't allow asterisk with the voicemail module to send mails containing audio messages. After some research, only this rule is needed: allow system_mail_t asterisk_tmp_t:file { getattr read }; There is still some strange AVCs occurring at the same time, but I don't know their impact: avc: denied { use } for pid=29313 comm="sendmail" path="/dev/null" dev="devtmpfs" ino=1572 path="/dev/null" dev="devtmpfs" ino=1572 ipaddr=194.29.25.170 scontext=staff_u:system_r:system_mail_t tcontext=staff_u:system_r:initrc_t tclass=fd avc: denied { use } for pid=29313 comm="sendmail" path="pipe:[3947281]" dev="pipefs" ino=3947281 path="pipe:[3947281]" dev="pipefs" ino=3947281 ipaddr=194.29.25.170 scontext=staff_u:system_r:system_mail_t tcontext=staff_u:system_r:initrc_t tclass=fd
Can you elaborate on the asterisk_tmp_t type here? I guess asterisk creates a temporary file for the voicemail stuff (hence the type); is there any possibility of having a differentiation between its "regular" tmp files, and those that are to be sent by the mailer daemon? If not, you probably only need to add "mta_system_content(asterisk_tmp_t)", which is telling SELinux that the asterisk_tmp_t type is used as input files for system mailings.
Created attachment 329632 [details] Inotify logs of /tmp /var/tmp/ /var/spool/asterisk/voicemail during a voice message After some checks, it appears that asterisk create a temp file /tmp/astmail-XXXXXX (at least) before transmiting it to sendmail. The name of the temp file is hardcoded in the asterisk sources (in app_voicemail.c) and partially random (the XXXXX part), thus, as asterisk is probably using the /tmp/ for other things, using a filetrans_pattern is imposible, isn't it ?
Yes, looks like mta_system_content(asterisk_tmp_t) is the best option here.
Adding mta_system_content(asterisk_tmp_t) works :) It a shame we cannot separate it from other asterisk tmp content :'( As a result, I'm not sure if it is a good idea to add it to the default policy... Perhaps with a boolean asterisk_use_voicemail or something similar ?
I'm not sure it is that bad. What other temporary files does asterisk use and that wouldn't be protected with the regular DAC (user/group ownership) stuff? Anyway, we cannot make this optional, unless we drop the attribute approach and allow it directly (so with the read_files_pattern stuff) as a "typeattribute <type> <attribute>" call isn't allowed in a tunable policy (I know, stupid right?)
Added to policy
r8 in hardened-dev overlay
r8 is now in main tree, ~arch
r8 is now stable