Subject: sgid mail

From: [email-masked] (Bernd Eckenfels)
Date: Mon, 29 Jul 1996 02:45:42 +0200 (MET DST)

Hi,

with movemail, there is a new interface to a users mailbox, without the need
for SGID mail on every MUA. I think we should provide a movemail and rewrite
all the Debian tools to use movemail (like netscape does already). This will
alos help to include qmail into a system, since movemail could do the
Maildir2Mailbox Converting for Applications which are not Maildir aware.

Any Comments? movemail is a small program which is used to
lock/unlock/access a users mailbox. Only this program need t be run as SGID
mail, and not every MUA like elm, mh...

Greetings
Bernd
-- 
  (OO)      -- [email-masked] --
 ( .. )  ecki@lina.{inka.de,ka.sub.org}  http://home.pages.de/~eckes/
  o--o     *plush*  2048/A2C51749  eckes@irc  +4972573817  *plush*
(O____O)       If privacy is outlawed only Outlaws have privacy

---

From: Richard Kettlewell <[email-masked]>
Date: Mon, 29 Jul 96 09:57:19 +0100 (BST)

Bernd Eckenfels writes:

>with movemail, there is a new interface to a users mailbox, without
>the need for SGID mail on every MUA. I think we should provide a
>movemail and rewrite all the Debian tools to use movemail (like
>netscape does already). This will alos help to include qmail into a
>system, since movemail could do the Maildir2Mailbox Converting for
>Applications which are not Maildir aware.
>
>lock/unlock/access a users mailbox. Only this program need t be run
>as SGID mail, and not every MUA like elm, mh...

This won't work; there are mail user agents (such as Pine, for
example) which keep the mail in the the user's mailbox rather than
moving it to a separate folder in their home directory.

-- 
Richard Kettlewell  [email-masked]  [email-masked]
                           http://www.elmail.co.uk/staff/richard/

---

From: Michael Alan Dorman <[email-masked]>
Date: Mon, 29 Jul 1996 08:45:37 -0400

In message <m0ukgSs-0004jWC@lina>, Bernd Eckenfels writes:
>all the Debian tools to use movemail (like netscape does already).

This is a sensible idea, and I'll gladly support it if you'll take on
the task of rewriting MH.

Otherwise, I can tell you that at least one MUA isn't going to get
rewritten anytime soon, and since xmh (definitely) and exmh (probably)
use those underlying tools, that makes three.

The point of Debian, it seems to me, is not to create a system that
differs gratuitously from all others, as this would, to little easily
discernable benefit, but to do only such work as is necessary to make
sure all tools work well together.

Mike.
--
"Don't let me make you unhappy by failing to be contrary enough...."

---

From: [email-masked] (Bernd Eckenfels)
Date: Mon, 29 Jul 1996 18:50:14 +0200 (MET DST)

Hi,

> moving it to a separate folder in their home directory.

yes. But we already have a lockprogram for ths purpose. (In the proc
package).

Greetings
Bernd

---

From: Richard Kettlewell <[email-masked]>
Date: Tue, 30 Jul 96 10:41:33 +0100 (BST)

>yes. But we already have a lockprogram for ths purpose. (In the proc

Fair enough.

This is still a solution without a problem, however - what is the
objection to MUAs being setgid mail?

---

From: Michael Alan Dorman <[email-masked]>
Date: Tue, 30 Jul 1996 20:02:05 -0400

I hope Dan doesn't mind me redirecting this back to the list.

In message <[email-masked]>, Dan Stromberg writes:
>Why would it not suffice to rewrite inc alone?

If someone really wanted to achieve the originally stated end (having
all mailbox access go through a single program), here's what's
involved for MH:

 chown root. /usr/bin/mh/inc
 chmod 0755 /usr/bin/mh/inc
 movemail mdorman mbox
 inc -file mbox
	
In pine one has the option of redifining one's inbox, so I suspect
that would be easy to manage.  Ditto, I suspect, for elm, or mush or
mailx or whatever fool thing one might choose to read one's mail with.

If someone is so paranoid or so in love with rigid rules or just
feeling like a change that week, such that he or she wants to have all
MUAs on their system behave in this way, _the capabilities are already
there_, lacking only configuration and may a couple lines of shell
script for glue.

But I have yet to here a single bit of evidence that this has benefits
that warrant the expenditure of a single iota of a maintainers time,
especially since what's being discussed consists of ripping out
integral parts of a number of packages in order to replace said parts
with calls to a program whose adequacy to the task of interfacing with
said programs has not been proven.

So, would someone like to prove that the gains would be worth the
maintainer's time?

Mike.

---

From: [email-masked] (Bernd Eckenfels)
Date: Wed, 31 Jul 1996 01:46:08 +0200 (MET DST)

Hi,

> objection to MUAs being setgid mail?

The minimum privileges principle. It is easy to veryvy lockmail or movemail.
But it is nearly impossible for every MUA. Additionally providing a
lockmail/movemail enables users without root privileges to install their own
MUA...

Greetings
Bernd

---

From: Mr Stuart Lamble <[email-masked]>
Date: Wed, 31 Jul 1996 08:37:09 +1000 (EST)

> objection to MUAs being setgid mail?

Mainly, that making sure the MUA is secure when it's sgid. Most programs
aren't - and it is not easy making them so. Some background first: there
is a machine here at Monash Uni, called Yoyo. Yoyo provides Unix access
(and complete internet access) to over three thousand students; to support
all of this, there are a large number of groups. I'm involved in three
groups, one of which is the "local" group - responsible for software
installations.

Recently, there was an explosion in the use of tintin on yoyo (tintin is
a MUD client). The problem is that, whilst mudding _within_ Monash is OK,
mudding to machines outside Monash (especially overseas) is very much
frowned upon. Telnet is logged, but tintin doesn't use telnet (it makes
its own connections), so this was one way people could mud and get away
with it.

As a result, I patched tintin so it would create a log file. So that it
wouldn't be "security through obscurity", I wanted to make the program
sgid to the security group, and the log read/writeable only by members
of that group. Removing all the possible security holes seemed
straightforward, but the problem was that the setgid() call apparently
can have subtle differences between different Unixes - it worked the way
I wanted it to under Linux, but I couldn't be certain that it would do
so under Digital Unix.

We ended up making the log world-writeable, and hoping that nobody would
figure out how to do Evil Things(tm) with it.

The point is that making programs sgid when they aren't intended to be can
open up a real can of worms in terms of security. I would prefer that they
not be sgid, and the mail directory be 1777 - yes, anybody can create any
files in there if they want to, but an alert sysadmin should be able to
pick up on this. The other issue is that maintainers of mail programs may
say, "Oh, they're meant to be sgid mail - fine, I'll do that", without
considering the security implications, let alone patching the code to
rectify the more blatent security problems.

Maybe I'm just being picky, though. :-) Just my $0.05 (it seems a bit too
long to be $0.02 :)

-- 
I'm on a low-fat, high stress diet: coffee and fingernails.