linux security - Aug 1998 - Pine 4.02 and directory perms

Hey linux-security-ers:

I just compiled/installed Pine 4.02 for my RH 5.0 machine today (didn't
see an RPM last time I checked ftp.redhat.com:/pub/contrib), and after I
got it installed, it kept giving me errors about not being able to create
a lockfile when dinking with my mailspool in /var/spool/mail.

After doing some digging on DejaNews and the Pine website, I find a
document who says the solution is to 'chmod 1777 /var/spool/mail' (you
can
read the doc at http://www.washington.edu/pine/QandA/sysadmins.html).

Now, here's the question: isn't this inherently bad? Doesn't this
allow
all sorts of exploits and such, as I can just go into /var/spool/mail and
start dumping things all over the place? Doesn't this open us up to a
bunch of problems /tmp shares as well?

The other suggestion they give is making pine sgid, and owned by a special
group (i.e. probably mail), but they find this solution insecure; I find
their solution insecure.

So, am I paranoid, or is the implementation wrong?

[mod: Please reply in personal mail to Paul. Paul, please summarize
the replies in about a week..... -- REW]


Later,
Paul
  -------------------------------------------------------------------------
  J. Paul Reed                 Among other things, just another perl hacker
  #!/usr/bin/perl       unless ($you =~ /spammer/) { print "Email
me!\n"; }
  @MyEmailAddresses =
("preed@verinet.com","paul@619pro.com");
  $MyWebPage = "http://www.verinet.com/~preed";

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                         preed@verinet.com || paul@619pro.com
  It's the best money I've spent since I bought my horse.
                                 --Anonymous WebTV junky, WebTV Infomercial