Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#36687 - [filesystem] /var/spool/mail directory is set to world writable by default

Attached to Project: Arch Linux
Opened by Aaron Lancaster (martian67) - Tuesday, 27 August 2013, 07:41 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 25 October 2014, 16:59 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tom Gundersen (tomegun)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No

Details

Description: the /var/spool/mail directory is set to world writable by default, it should be set to the permissions of the mailer/root by default. This is a security issue because you could create an mbox for a user and then intercept mail if it does not already exist.

Additional info:
* package version filesystem 2013.05-2

Steps to reproduce: n/a
This task depends upon

Closed by  Dave Reisner (falconindy)
Saturday, 25 October 2014, 16:59 GMT
Reason for closing:  Not a bug
Additional comments about closing:  mode 1777 is intentional, and not insecure for this directory.
Comment by Aaron Lancaster (martian67) - Tuesday, 27 August 2013, 08:09 GMT
to expose the security problem of this bug do the following:

create a new regular user
as a second unprivileged user execute: touch /var/spool/mail/newusername
chmod 666 /var/spool/mail/newusername
send mail to the new user
the second unprivileged user can now read the mail of the newuser

this is a problem with at least opensmtpd, have not tested other mailers.

issue can be resolved by setting permissions on the /var/spool/mail to 755, MTAs will have the correct permissions to properly create mbox files.

referenced filesystem PKGBUILD code:
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/filesystem#n63

attached a fix
   patch.diff (0.4 KiB)
Comment by Aaron Lancaster (martian67) - Tuesday, 27 August 2013, 08:31 GMT
I am unsure if some MTAs rely on this behaviour, if they do they are badly broken, and need to be fixed. If they don't have a privileged forked process like opensmtpd to write mbox files, the directory may need to be a part of their group or something, in any case, the filesystem default is pretty busted.
Comment by Leonid Isaev (lisaev) - Sunday, 08 June 2014, 19:51 GMT
What's the status of this? FWIW, on RHEL systems /var/spool/mail is 0775 root:mail.
Comment by Leonid Isaev (lisaev) - Sunday, 08 June 2014, 23:32 GMT
Actually, I spoke too soon. Having /var/spool/mail 1777 root:root is OK. In fact, this is what exim expects by default, see http://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_default_configuration_file.html .

There is no security issue (the above attack will not work) because in this case all local mailboxes are forced to have permissions 600, otherwise delivery does not occur. And yes, by default exim relies on the sticky bit because it runs with local (target) unprivileged user permissions and needs to put a lockfile in /var/spool/mail.

I don't know about postfix, but it should be similar, or at least configurable. Unless I missing something, I suggest closing this...

Loading...