Bug 12495

Summary: Potential exploit -- /var/spool/mail g+w is proper, but causing errors
Product: [Retired] Red Hat Linux Reporter: R P Herrold <herrold>
Component: sendmailAssignee: Florian La Roche <laroche>
Status: CLOSED WORKSFORME QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.2Keywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-07-13 00:41:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description R P Herrold 2000-06-19 01:08:06 UTC
/var/spool/mail is properly g+w --- actually it should be 1777 

'user' "mail" should probably have a 'home' directory below
/var/spool/mail, to prevent these messages:

Jun 18 20:11:01 localhost sendmail[3060]: alias database /etc/aliases
autorebuilt by root
Jun 18 20:11:01 localhost sendmail[3060]: /etc/aliases: 14 aliases, longest
10
bytes, 152 bytes total
Jun 18 20:11:02 localhost sendmail[3060]: e5J0AxB03060: forward
/var/spool/mail/.forward.build: Group writable directory
Jun 18 20:11:02 localhost sendmail[3060]: e5J0AxB03060: forward
/var/spool/mail/.forward: Group writable directory              

-------------------

[root@localhost /etc]# grep mail passwd
mail:x:8:12:mail:/var/spool/mail:
mailnull:x:47:47::/var/spool/mqueue:/dev/null
[root@localhost /etc]# 

-------------------

I'd suggest that mail be given "/var/spool/mail/home" with ownership
mail.mail and permissions 700, so that it may safely rebuild the aliases
file without the exposure to a race exploit.

This may more properly affect 'filesystem' as well -- If so, perhaps we
should open a cross-reference bug there, too.

Another approach would be to all a blanket forward in /etc/aliases so that
all mail to 'mail' is sent to root.

But then, too, root's mail should also be sent to an end user account for
security's sake.  I'll submit that as an enhancement request.

Comment 1 Henri Schlereth 2000-07-13 00:40:58 UTC
sendmail-8.10.1-9 doesnt generate the permissions error anymore. The rest may still stand as feature requests.

Henri J. Schlereth


Comment 2 R P Herrold 2001-01-21 17:40:19 UTC
Alan Cox has dedclined the 1777 on testers list -- the rest are not active --
close by initial requester