Subject: external *.lock creation/deletion program

From: Paul Raines <[email-masked]>
Date: Mon, 28 Oct 1996 11:00:26 -0500

I have begun to look at c-client for use in my mail reader.
A couple of questions/observations so far:

(1) in order for *.lock creation for the mail spool file to
    work, either the spool directory must be writable (ususally
    01777) by all or the program based on c-client must be 
    setuid/setgid. As a sysadmin, I find neither of these options
    very acceptable.  For my reader, I have created a small, 
    simple setgid program to create/delete *.lock files in the spool
    directory. It is small and simple enough to (hopefully) see
    any security holes. It would be nice if c-client could be
    configured to use such an external program. 

(2) any plans for adding Content-Disposition support to the
	BODY structure?

(3) I am confused about the following text from Internal.DOC

>>  GET_FROMWIDGET / SET_FROMWIDGET
>> 	 If non-NIL, APPEND in the Unix mbox format will insert a
>> 	">" character in front of all lines which begin with the
>> 	string "From ".  If NIL, it will only do so if the entire
>> 	line looks like a message delimiter (that is, the date is
>> 	also in correct format).  Defaults to T.

    Shouldn't the last be 'only do so if the entire line does NOT
    lool like a message delimiter'?  I have seen some formats that
    do put a '>' in front of the mesg delimiter lines but this seems
    a crazy standard since many use '>' as a mesg inclusion prefix.

pr

--
_________________________________________________________________________
Paul Raines               [email-masked]           804-221-1876
Stanford Linear Accelerator    End Station A           E143 Collaboration
http://www.slac.stanford.edu/~raines/index.html  <======== PGP public key

---

From: Mark Crispin <[email-masked]>
Date: Mon, 28 Oct 1996 09:19:15 -0800 (PST)

On Mon, 28 Oct 1996 11:00:26 -0500, Paul Raines wrote:
>     very acceptable.

We, too, don't find setuid/setgid to be acceptable.

However, it is possible to set the spool directory 01777 without encountering
any serious problems.  Make sure that everybody has a mail file, fix any MUA
that deletes mail files, and check for links/bad ownership when delivering.

>  For my reader, I have created a small,
>     any security holes.

That's what they said about GNU movemail.  Of course, movemail was setuid root
instead of just setgid, but the point is still valid.  Privileged programs are
a security hole.  Each user-invokable program that runs with privileges is a
potential weakness in the system, one that may get you down months or years
later.

That's why one of the first things done with secure versions of UNIX is remove
the setgid/setuid file bits.

> It would be nice if c-client could be

There are no plans to do so.

> (2) any plans for adding Content-Disposition support to the

This has already happened in the imap-4.1 version.  Internal.DOC hasn't been
updated yet.

>     a crazy standard since many use '>' as a mesg inclusion prefix.

The text is correct as is.  The entire purpose of writing the ">" is to
prevent a message text line from being seen as a message delimiter.  c-client
has some very specific tests to prevent false matches (a line that merely
begins with the word "From " will not confuse c-client).

You should leave SET_FROMWIDGET set to T, since other mail programs are not as
smart as c-client and match on any line that happens to begin with "From ".

[To forstall any helpful comments about "Content-Length", let's just say that
I have a multi-hour lecture prepared on why Content-Length is a terrible idea
and should never be used.]

---

From: David L Miller <[email-masked]>
Date: Mon, 28 Oct 1996 09:45:39 -0800 (PST)

>     a crazy standard since many use '>' as a mesg inclusion prefix.

No, the '>' widget is inserted so that a line in the body of a message
that looks like a delimiter will not be mistaken for one.  Since the
only way to distinguish message boundaries in mbox format is the "From
" line, some escape mechanism is necessary.  Indeed, the '>' widget
does not seem like a very good choice, but it is what is used by older
systems.  I think some mailers have hacks to suppress them on display
too... 

--DLM

-- 
|\ |  |\/|  David L. Miller    [email-masked]  (206) 685-6240
|/ |_ |  |  Software Engineer, Pine Development Team   (206) 685-4045 (FAX)
University of Washington, Networks & Distributed Computing, Box 354841
4545 15th Ave NE, Seattle WA 98105, USA     Stardate: [-31]8338.70

---

From: Paul Raines <[email-masked]>
Date: Mon, 28 Oct 1996 13:10:56 -0500

>> that deletes mail files, and check for links/bad ownership when delivering.

I guess it is a matter of opinion, but I find setting the spool directory
to 01777 more insecure than having a small, simple setgid program.  There
is nothing preventing users from *.lock'ing other users mailboxes, for
example.  Also, fixing MUA's is often impossible.

Now that I have read the APPEND command, I understand the wording of
the GET_FROMWIDGET / SET_FROMWIDGET setting better now.  By "all", I
thought it would but the '>' in front of the mesg deliminator too.
But I see the mesg deliminator "From " line is never passed in an APPEND.

BTW, when I tried an APPEND from a 'telnet host 143' to an IMAP server,
even after reaching the number of bytes in the literal, it kept reading
for ever. I expect to be able to keep typing letters till the limit
was reached. Does it have to end exactly at an end-of-line? Or does
the nature of using telnet screw up everything for literals?

---

From: Mark Crispin <[email-masked]>
Date: Mon, 28 Oct 1996 12:14:25 -0800 (PST)

On Mon, 28 Oct 1996 13:10:56 -0500, Paul Raines wrote:
> to 01777 more insecure than having a small, simple setgid program.

We'll have to agree to disagree.

By the way, are you aware that a setgid program isn't going to work over NFS
unless you mount to enable setuid?  If you do that, you have much worse
security problems than an 01777 spool directory!

> There
> example.

This isn't as much of a problem as you seem think it is.

In order for this attack to be effective, the lock file must be created within
5 minutes of now, otherwise the lock is declared stale and removed.  So, the
worst that a bad guy can do is cause (very) short-term denial of service.

The bad guy also has to use a hard link to hide his identify.  If your mail
spool is on a different partition (routinely done on most sites), that greatly
limits what the bad guy can use as a links.  If you know that nothing will
ever put data into a lcok file, then you can make the locking routines ignore
locks that are of non-zero size.  Then the bad guy has to make hard links to
zero length files that constantly have their date updated.

If you are really concerned about mail spool security, you would not want to
use a mail spool at all.  Instead, you would deliver directly to home
directories or use IMAP.

> But I see the mesg deliminator "From " line is never passed in an APPEND.

If you think about it, the "From " line is an artifact of one mail file format
on one operating system.  Some OS/360 people in the 1960s may have thought
that file data includes the "//GO.SYSIN DD *" card.... ;-)

> the nature of using telnet screw up everything for literals?

From section 4.3 in the IMAP4rev1 base specification:

   A literal is a sequence of zero or more octets (including CR and LF),
   prefix-quoted with an octet count in the form of an open brace ("{"),
   the number of octets, close brace ("}"), and CRLF.

In other words, there must be a CRLF after the literal size count.  Therefore,
	{3}foo
is invalid.

A literal doesn't end a command.  Only a CRLF (and not the one after the
literal size count) ends a command.  Some commands (e.g. LOGIN) may have
multiple literals in their arguments.