|
Bugzilla – Full Text Bug Listing |
| Summary: | apparmor prevents pine from sending out mail | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Reinhard Max <max> |
| Component: | AppArmor | Assignee: | Dominic W Reynolds <dreynolds> |
| Status: | RESOLVED FIXED | QA Contact: | Dominic W Reynolds <dreynolds> |
| Severity: | Blocker | ||
| Priority: | P5 - None | CC: | aj, suse-beta, varkoly |
| Version: | Beta 7 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Reinhard Max
2006-03-10 11:35:52 UTC
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. |