Subject: Pine lockfile

From: Michael Abbott <[email-masked]>
Date: Mon, 17 Feb 2003 08:47:14 +0000 (GMT)

I've just upgraded pine to 4.53 (on FreeBSD, using ports) and have been
reminded of a problem that required some investigation last time I
installed pine.  I don't really understand why this problem *still*
arises.

When installed, pine complains on startup thus:

	Folder vulnerable - directory /var/mail must have 1777 protection

This is telling me that my mail folder should be wide open.  I understand
that this is because pine wishes to place a lock file in this directory.
Leaving this folder wide open does not seem a good idea, and after some
investigation I came up with the following approach:

	# chmod +t /var/mail
	# chown :mail /usr/local/bin/pine
	# chown g+s /usr/local/bin/pine

The mail user only seems to own the mail folder, so it seems to make a lot
of sense to give pine exclusive write access to this folder.

Can anyone comment on:
1.  What's wrong with this approach;
2.  If there's nothing wrong with it, why isn't it done?
-- 
-----------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/pine/pine-info/
-----------------------------------------------------------------

---

From: Mats Dufberg <[email-masked]>
Date: Mon, 17 Feb 2003 22:46:03 +0100 (CET)

> that this is because pine wishes to place a lock file in this directory.

Well, it is not wide open. You have the sticy bit set, just like with
/tmp.

If I am correct you must set 1777 protection only if lock files is the
only availble locking method. As far as I understand most UNIX flavors,
like FreeBSD, have other locking methods that don't requir locking with
files, and then it is not needed.

> 	# chown g+s /usr/local/bin/pine

(I guess you mean "chmod g+s".)

> 2.  If there's nothing wrong with it, why isn't it done?

As far as I can see you open up a huge sucurity hole with your approach.
You say that pine should be run as group mail for any user running pine.
That means that any user can read any other user's spool file.

Both setuid and setgid should be avoided, and it should defintely not be
added to program not designed to be setuid/setgid.

Mats

-----------------------------------------------------------------
Mats Dufberg                                 [email-masked]
Blaoarvsgraend 42                                  +46-8-38 48 59
SE-162 45 Vaellingby, Sweden                      +46-70-258 2588

---

From: Michael Abbott <[email-masked]>
Date: Mon, 17 Feb 2003 22:10:57 +0000 (GMT)

> Well, it is not wide open. You have the sticky bit set, just like with
> /tmp.
True.  But it seems more open than it should be.  In particular, this
means that anyone can use /var/mail as a temporary working folder!  This
doesn't seem right...

> files, and then it is not needed.
This kind of makes sense, but then why does pine complain like it does?
If pine doesn't need 1777 access to /var/mail, it shouldn't ask for it!
If it does, then something feels wrong.

> (I guess you mean "chmod g+s".)
Sorry; quite right!

> That means that any user can read any other user's spool file.

Oooooops.  >checks<

No, I think it's ok.  The *only* file/directory in the entire system that
is owned by mail is /var/mail (and now pine).  In particular, this means
that pine can't read the files *in* this directory without already owning
them (by being the right user).

 >phew<  I *thought* I'd checked that!

	# find / -group mail
	/usr/local/bin/pine
	/var/mail
	#

> added to program not designed to be setuid/setgid.

Well, I take your point, and your suggestion that I'd opened a hole made
me worry.

However, I think it's quite safe.  All the mail group does is give pine
access to the mail group, ie the ability to write to /var/mail.  To be
honest, this looks to me like quite a *sensible* application of setgid,
and I can't see a way to misuse it.

Unless I'm missing something?

---

From: Mats Dufberg <[email-masked]>
Date: Mon, 17 Feb 2003 23:43:23 +0100 (CET)

> means that anyone can use /var/mail as a temporary working folder!  This

I agree with you.

> If it does, then something feels wrong.

I think they do it to be on the safe side... I know that they (UW) have
information on their web site.

>  >phew<  I *thought* I'd checked that!

I thought that the spool files were group writeable, but they are not on
my system either. (But I remember having seen that.)

But new files created by pine will be owned by group mail, and if they are
group writable you have opened a hole.

> and I can't see a way to misuse it.

I agree that my warning was maybe to harsh, but I still would not add
setgid to an application not designed to be setgid.

Could anyone from UW make a statement on the need of world writable spool
directory?

Mats

---

From: "Mike A. Harris" <[email-masked]>
Date: Mon, 17 Feb 2003 18:03:43 -0500 (EST)

>If it does, then something feels wrong.

It doesn't.  In Red Hat Linux, our mail spool directory is mode 
0775 and owned by root, group "mail".  User's mail spool files 
are owned by the user, group "mail".

This setup is what all of the mail applications we ship use, or 
are modified to use if they don't use it by default.  It works 
well in Linux systems.

>Unless I'm missing something?

Making pine SUID is a rather large security hole.  I'd put $10000 
bet that Al Viro locked in a room with pine could find a shell to 
root vuln in less than an hour if it were SUID root.  Then again, 
he could find similar holes in hello-world.c so.....

<grin>

-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat

---

From: Mats Dufberg <[email-masked]>
Date: Tue, 18 Feb 2003 00:05:46 +0100 (CET)

> are modified to use if they don't use it by default.  It works

And you have verified that locking is working correctly with pine?

> he could find similar holes in hello-world.c so.....

Well, in this case it was SGID mail rather than SUID root. But still I
would hesitate. UW has choosen not to do it SGID.

Mats

---

From: "Mike A. Harris" <[email-masked]>
Date: Mon, 17 Feb 2003 18:18:33 -0500 (EST)

>And you have verified that locking is working correctly with pine?

Well, we've been shipping like this for years, and yes it does 
work, although our pine is patched.  Open 2 pine sessions at once 
and you're told the mailbox is in use by another pine session.

>would hesitate. UW has choosen not to do it SGID.

I wouldn't SUID or SGID any software of sufficient complexity of 
something like pine.  It's just too large of a security risk and 
is non-essential.  There are other ways to accomplish locking 
safely and securely, at least on Linux systems.

---

From: Mats Dufberg <[email-masked]>
Date: Tue, 18 Feb 2003 00:23:24 +0100 (CET)

> and you're told the mailbox is in use by another pine session.

Yes, that should be a sufficient test, and I knew that I came to the same
conclusion but you reminded me how. The same thing is true on FreeBSD.

The conclusion is, don't make the spool directory sticky and turn pines
warnings off. BUT test locking by opening two pine sessions against the
same spool file.

> safely and securely, at least on Linux systems.

And that's a good conclusion. -- Maybe there is a Unix where locking must
be done with files, but raise a warning on them instead.

Mats

---

From: Michael Abbott <[email-masked]>
Date: Tue, 18 Feb 2003 07:25:14 +0000 (GMT)

> be done with files, but raise a warning on them instead.

There seems to be an assumption here that SGID is automatically bad.  I'm
not convinced.

In particular, in this particular case, I cannot think of any security
risks.  Obviously this may just be a failure of imagination, but I think
this is worth investigating further.

I think there are two issues here:

1. Does pine *really* need write access to /var/mail in order to implement
its locking on FreeBSD?  If not, is this a problem with pine or with the
FreeBSD port?

2. Is there *really* any security issue in my proposed solution?  So far a
number of interesting hazards have been mentioned, but none of them
mentioned so far actually apply in this case (for example, the files
created by pine are *not* owned by group mail: recall my `find / -group
mail` search).

My impression is a slight confusion between the deadly hazards of SUID
root and the obscure hazards(?) of SGID mail.