Bugzilla – Bug 156998
apparmor prevents pine from sending out mail
Last modified: 2006-03-14 09:59:53 UTC
After updating to Beta7 I got some strange behaviour when trying to send out mail from pine. It turned out that pine executes /usr/sbin/sendmail -bs -odb -oem which in turn tries to execute /usr/lib/postfix/smtpd -S but gets an -EPERM, because of apparmor. I think the /usr/sbin/sendmail executable that comes with postfix doesn't even need to be restricted by apparmor, because unlike the sendmail binary from the sendmail package it never listens on a network socket and processes data that comes from outside and it has no SUID or SGID bit set.
Adding the postfix maintainer and aj to cc.
Seth. What do you think? We can update the sendmail profile or just remove it. We ship a profile for /usr/lib/postfix/smtp and the fix to add a px for it corrects this problem - sendmail works fine with pine.
Reinhard, could you please include the /var/log/audit/audit.log REJECT lines that say which specific permissions aren't included in our profiles? It'd be nice to get them all at once than chip away at them one at a time. /usr/sbin/sendmail is still useful to profile, despite not running setugid or listening -- as the entry point for outgoing mail (and, I believe the sendmail.org sendmail even initiates communication with remote MX hosts), it has the potential to affect a system's overall security, and especially the invoking user's security. Thanks
I'm only aware of: Mar 10 15:48:38 K6 kernel: audit(1142002118.256:3): REJECTING x access to /usr/lib/postfix/smtpd (sendmail(27264) profile /usr/sbin/sendmail active /usr/sbin/sendmail) But there might be more, so leave it as NEEDINFO.
Fixed. Profile updated to allow smtpd to executed. Tested with the pine client and the smptd profile.Checked in for beta8.
To Comment #3: By looking at the code of sendmail, I found that "sendmail -bd" tries tp execute /usr/sbin/postfix, which is currently also being rejected. Yes, the sendmail.org version of /usr/sbin/sendmail is useful to profile, because it might listen on port 25, open connections to remote hosts, and has a long history of security holes. But I think the Postfix version of /usr/sbin/sendmail isn't any more dangerous for the invoking user's security than any other end-user application that we ship. (Or is the plan to profile them all sooner or later?)
Reinhard, thanks for finding /usr/sbin/postfix in the /usr/sbin/sendmail code. Fixed in our internal svn, hopefully I'll get it checked into autobuild in time for Beta 8. Unfortunately, there's no good way for us to 'know' which version of /usr/sbin/sendmail is being used. On Debian and Red Hat systems, we were lucky enough to have /usr/sbin/sendmail.{sendmail,postfix,exim,etc..} executables to profile, but the downside was that each confined application that sent email needed to be ready to work with each of the different servers. Now, each application only needs to work with /usr/sbin/sendmail, but our /usr/sbin/sendmail profile is fairly large -- and, as you point out, not always the highest priority. Our long term vision for AppArmor is to have most of the common daemons confined by default, and make it trivial for users to to select from and extend hundreds of profiles, depending on their own assessment of reasonable risks. Our current system doesn't make this goal as easy as it could, especially since postfix and apache are (a) the most common daemons on the system (b) quite configurable.
Would it be against the principles and policies of AppArmor if the RPMs for the to be monitored services contained their respective profiles, either in the main RPM or in a subpackage? The packages containing the various implementations of /usr/sbin/sendmail are mutually exclusive anyways, because of that file name conflict, and that way AppArmor would always have the right profile at hand for the variant of /usr/sbin/sendmail that is installed.
This is an enhancement request that we should discuss for 10.2.