Mail delivery privileges (was: Solaris /usr/bin/mailx exploit)

From: Wietse Venema (wietseat_private)
Date: Fri May 18 2001 - 08:18:51 PDT

  • Next message: Caldera Support Information: "Security Update: [CSSA-2001-018.0] samba /tmp problems"

    Greg A. Woods:
    > The actual delivery need only run as "nobody:mail".  Period.  End of story.
    [...]
    > In any case there's no need to lose any features whatsoever.  Secure
    > local mail delivery is entirely practical and very achievable.
    
    Local mail delivery crosses the mail-to-user boundary in several
    places. Assuming traditional UNIX user/group/other permissions and
    uid/gid-based privileges, and the traditional /var/mail, aliases
    and .forward interface with user-specified shell commands:
    
    1 - Appending mail to mailbox. This can be done securely by
    nobody:mail provided that the mailbox has group write permission.
    But that is only the easy part.
    
    2 - Lock file management. If mail is delivered as nobody:mail, then
    /var/mail/username.lock files are owned by user nobody.  This means
    you can't use mode 1777 /var/mail permissions (a user would not be
    able to remove a stale username.lock file left behind by the mail
    system and vice versa).  Instead, /var/mail must be mode 770 group
    mail, and mail user agents need SET-GID mail privileges in order
    to remove stale username.lock files.  The privileges are needed
    either by the MUA itself or by an MUA helper program.  The alternative,
    unrestricted /var/mail directory write permission, is not secure.
    
    3 - User-specified shell commands. Traditionally, a user can specify
    any shell command in ~user/.forward, and that command will execute
    with the privileges of that user. This requires SUPER-USER privileges
    in the mail delivery software itself or in mail helper software.
    
    I agree with Mr. Woods on the challenge of implementing functionality
    securely without loss of features.  However, nobody:mail delivery
    privileges alone are not sufficient to implement a widely-used
    mail-to-user interface on systems with traditional user/group/other
    permissions and uid/gid-based privileges. One needs to apply
    additional privileges or accept the loss of functionality.
    
    All the more reason to use a different mail-to-user interface.
    
    	Wietse
    



    This archive was generated by hypermail 2b30 : Fri May 18 2001 - 11:43:31 PDT