Date: Mon, 24 Aug 1998 23:07:28 -0600 (MDT)
From: "J. Paul Reed" <[email protected]>
To: [email protected]Subject: [linux-security] SUMMARY: Pine 4.02 and directory perms
The Question
============
Pine 4.02 needs to create a lockfile in /var/spool/mail; how does it want
us to allow it to do that? `chmod 1777 /var/spool/mail` is the answer in
the docs. This is "bad" (tm), right? Well...
The Answer
==========
The general consensus seems to be that this is the "wrong thing" (tm) to
do, and pine shouldn't implement locking this way. Their proposed solution
is bad because it does create an environment that could suffer from /tmp
race exploits; examples including creating lockfiles "for" people, and if
other people do not use pine (i.e. some versions of standard-boring mail
delete the mailspool file for a user when they're done if it's empty), one
could create a mailbox "for" them, and make it world readable. According
to one respondant, the documentation also says apllying a mode 1777 would
allow users to break quota restrictions; their solution to that is to make
a cron job that goes through everyday and deletes files. I don't think so.
;-)
According to the documentation, Pine implements locking through many
different mechanisms; one person said dotlocking is mainly for NFS, where
locking can be a flake-o-rama and the standard flock() isn't easily
implemented.
Proposed Solutions
Force mail to be delivered in a user's home directory (like qmail does
it); pine supposedly supports this, and this seemed the most popular for
numerous reasons (quotas for that user are then enforced, no problems
with this "feature," etc.).
If you're not pulling the mailspool over NFS, one solution is to leave
/var/spool/mail 755, and select the "quell-lock-failure-warnings" in the
pine setup; theoretically, nothing bad should happen, since a flock() does
exist on a local machine. Step two to this solution: ignore it. ;-)
Stay at 3.95(/6/7), which (at least for me) didn't have this problem.
Note that sgid-ing pine is NOT a secure/suitable option, as the program
doesn't seem to be disigned for it, and doing so would make the hole even
worse.
Another suggestion was to apply the 4.02A patch, which has nothing to do
with this problem (it fixes MIME buffer overflows), but that's just good
security advice anyway. ;-)
To all who answered, thanks for the help!
Later,
Paul
-------------------------------------------------------------------------
J. Paul Reed [email protected] || [email protected]
It's the best money I've spent since I bought my horse.
--Anonymous WebTV junky, WebTV Infomercial
--
----------------------------------------------------------------------
Please refer to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe:
mail -s unsubscribe [email protected] < /dev/null
