On Mon, 2008-10-20 at 16:28 +0100, Paul Cocker wrote:
> > On Mon, 2008-10-20 at 09:56 +0100, Paul Cocker wrote:
> > > I'm attaching a footer to e-mail in postfix using
> > altermime. SELinux
> > > is preventing this from happening.
> > >
> > > I did some reading and have thus been using the method of switching
> > > SELinux into permissible mode, sending an e-mail through
> > the system,
> > > then using audit2allow to generate a policy from the audit log
> > > generated by the e-mail.
> > >
> > > grep AVC /var/log/audit/audit.log | audit2allow -m altermime >
> > > altermime.te checkmodule -mM -o altermime.mod altermime.te
> > > semodule_package -o altermime.pp -m altermime.mod semodule -i
> > > altermime.pp
> > >
> > > I use semodule -l to verify the policy was loaded.
> > >
> > > Once I enable SELinux and send another e-mail I find the e-mail is
> > > still stopped, so I run audit2allow again and it picks up a
> > type that
> > > wasn't in the previous policy (I remove the > altermime.te bit and
> > > manually move over the missing bits), so I update the
> > module and add
> > > it to SELinux. I repeat this process a couple of times as
> > the e-mail
> > > is blocked by new things.
> > >
> > > However, the e-mail is still blocked and running audit2allow on the
> > > log shows no changes over the existing policy.
> > >
> > > Postfix is sending the following error to the sender:
> > >
> > > user@xxxxxxxxxxx: service unavailable.
> > > Command output: mime_alter.c:2192:AM_insert_Xheader:NOTICE:
> > Adjusting
> > > temp file name for header insert sendmail: fatal: execvp
> > > /usr/sbin/postdrop: Permission denied
> > > sendmail: warning: premature end-of-input on /usr/sbin/postdrop -r
> > > while reading input attribute name sendmail: warning: command
> > > "/usr/sbin/postdrop -r" exited with status 1 sendmail: fatal:
> > > user@xxxxxxxxxx(100): unable to execute /usr/sbin/postdrop
> > -r: Success
> > >
> > > Contents of the maillog for this message:
> > >
> > > Oct 20 09:26:21 merlin postfix/smtpd[16322]: C95801F80042:
> > > client=computer.domain.com[10.100.100.100]
> > > Oct 20 09:26:21 merlin postfix/cleanup[16324]: C95801F80042:
> > >
> > message-id=<01c9328d$Blat.v2.6.2$88778715$6f8d393e538@xxxxxxxxxxxxxx>
> > > Oct 20 09:26:21 merlin postfix/qmgr[16156]: C95801F80042:
> > > from=<user@xxxxxxxxxxx>, size=562, nrcpt=1 (queue active) Oct 20
> > > 09:26:21 merlin postfix/smtpd[16322]: disconnect from
> > > computer.domain.com[10.100.100.100]
> > > Oct 20 09:26:21 merlin sendmail[16330]: fatal: execvp
> > > /usr/sbin/postdrop: Permission denied
> > > Oct 20 09:26:22 merlin postfix/sendmail[16329]: warning: premature
> > > end-of-input on /usr/sbin/postdrop -r while reading input attribute
> > > name Oct 20 09:26:22 merlin postfix/sendmail[16329]:
> > warning: command
> > > "/usr/sbin/postdrop -r" exited with status 1 Oct 20 09:26:22 merlin
> > > postfix/sendmail[16329]: fatal:
> > > user@xxxxxxxxxxx(100): unable to execute /usr/sbin/postdrop -r:
> > > Success Oct 20 09:26:23 merlin postfix/pipe[16325]: C95801F80042:
> > > to=<user@xxxxxxxxxx>, relay=dfilt, delay=2, delays=0.01/0/0/2,
> > > dsn=5.3.0, status=bounced (service unavailable. Command output:
> > > mime_alter.c:2192:AM_insert_Xheader:NOTICE: Adjusting temp
> > file name
> > > for header insert sendmail: fatal: execvp /usr/sbin/postdrop:
> > > Permission denied sendmail: warning: premature end-of-input on
> > > /usr/sbin/postdrop -r while reading input attribute name sendmail:
> > > warning: command "/usr/sbin/postdrop -r" exited with status
> > 1 sendmail: fatal:
> > > user@xxxxxxxxxxx(100): unable to execute /usr/sbin/postdrop -r:
> > > Success
> > > )
> > > Oct 20 09:26:23 merlin postfix/cleanup[16324]: D027D1F8007B:
> > > message-id=<20081020082623.D027D1F8007B@xxxxxxxxxxxxxxxxxxxxx>
> > > Oct 20 09:26:23 merlin postfix/bounce[16332]: C95801F80042: sender
> > > non-delivery notification: D027D1F8007B Oct 20 09:26:23 merlin
> > > postfix/qmgr[16156]: D027D1F8007B: from=<>, size=3216,
> > nrcpt=1 (queue
> > > active) Oct 20 09:26:23 merlin postfix/qmgr[16156]: C95801F80042:
> > > removed Oct 20 09:26:23 merlin postfix/smtp[16333]: D027D1F8007B:
> > > to=<user@xxxxxxxxxxx>, relay=relay.domain.com[10.100.100.1]:25,
> > > delay=0.11, delays=0/0/0/0.1, dsn=2.6.0, status=sent (250 2.6.0
> > > <20081020082623.D027D1F8007B@xxxxxxxxxxxxxxxxxxxxx> Queued mail for
> > > delivery)
> > > Oct 20 09:26:23 merlin postfix/qmgr[16156]: D027D1F8007B: removed
> > >
> > > The policy generated looks as follows:
> > >
> > > module altermime 1.0;
> > >
> > > require {
> > > type postfix_etc_t;
> > > type postfix_public_t;
> > > type postfix_spool_t;
> > > type sendmail_exec_t;
> > > type postfix_pipe_t;
> > > type postfix_spool_maildrop_t;
> > > class sock_file write;
> > > class dir { write search remove_name add_name };
> > > class file { rename execute read create execute_no_trans
> > > unlink };
> > > class process setrlimit;
> > > }
> > >
> > > #============= postfix_pipe_t ============== allow postfix_pipe_t
> > > postfix_etc_t:file { execute execute_no_trans }; allow
> > postfix_pipe_t
> > > postfix_public_t:sock_file write; allow postfix_pipe_t
> > > postfix_spool_maildrop_t:dir { write remove_name search add_name };
> > > allow postfix_pipe_t postfix_spool_t:dir { write
> > remove_name add_name
> > > }; allow postfix_pipe_t postfix_spool_t:file { create
> > rename unlink };
> > > allow postfix_pipe_t sendmail_exec_t:file { read execute
> > > execute_no_trans }; allow postfix_pipe_t self:process setrlimit;
> > >
> > > Being new to SELinux I'm stumbling around in the dark
> > somewhat (and if
> > > someone can tell me what the self:process line is I'd be grateful).
> > > I'm guessing that the following line is the problem:
> >
> > It means that postfix_pipe_t is changing the hard resource
> > limits on either itself or another process in the same
> > domain. Likely fine - it is probably lowering them to avoid
> > a DOS attack.
> >
>
> Thanks.
>
> > > fatal: execvp /usr/sbin/postdrop: Permission denied
> >
> > Looks that way, and that message was prefixed with sendmail:,
> > which suggests that it was an attempt by sendmail to exec
> > postdrop that failed. If sendmail were running in
> > system_mail_t, it should have transitioned to postfix_drop_t
> > upon executing /usr/sbin/postdrop.
> >
>
> Can you explain that for me?
>
> Where it says sendmail, I assume it's a reference to /usr/sbin/sendmail,
> which is a symlink to /etc/alternatives/mta, which is a symlink to
> /usr/sbin/sendmail.postfix.
Yes, I believe that is correct.
> Would that mean sendmail (assuming I am
> correct about what this is referring to) would be running under
> sendmail_exec_t, the context of the third item in the chain?
Not precisely; the executable program file is labeled with that type,
but the domain type in which the process runs depends on the calling
domain and whether or not any domain transition is defined in the policy
from that calling domain on that file type.
In your case, postfix_pipe_t was invoking sendmail, but no domain
transition was defined for it, and thus it remained in postfix_pipe_t
(which is what generated the execute_no_trans denial that you saw and
addressed in your policy module). Then sendmail, still running in
postfix_pipe_t, was invoking postdrop, and this was denied.
> > > The security context of this file is
> > > system_u:object_r:postfix_postdrop_exec_t
> > >
> > > I'm thinking that perhaps I need to add:
> > >
> > > type postfix_postdrop_exec_t
> > > allow postfix_pipe_t postfix_postdrop_exec_t:file execute
> >
> > If you actually want postfix_pipe_t to run postdrop, then
> > you'd want a domain transition there. Looks like there is a
> > postfix_user_domtrans attribute defined in the postfix policy
> > for all domains that transition into the postfix domains. So
> > something like:
> >
> > require {
> > attribute postfix_user_domtrans;
> > }
> > typeattribute postfix_pipe_t postfix_user_domtrans;
> >
> > might help there.
> >
>
> And indeed it did! Adding that gave it a kick up the backside and it
> generated some new errors, and voila! I have working e-mail with
> footers.
On second thought, it occurs to me that the above may not be the best
route. If you instead set up a domain transition from postfix_pipe_t to
system_mail_t upon invoking sendmail, then there is already a domain
transition from system_mail_t to postfix_postdrop_t defined in the
existing policy. This might avoid the need for some of your other rules
and keep sendmail distinct from the other pipe processes. This would
look like:
mta_send_mail(postfix_pipe_t)
That uses a refpolicy interface. To use refpolicy interfaces in your
policy module, you need to have selinux-policy-devel installed and you
need to build your module via:
make -f /usr/share/selinux/devel/Makefile <modulename>.pp
> Many, many thanks for your help. I'm going to run through the policy and
> see if there are any extraneous references which I can drop.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
