From owner-freebsd-ports Mon Aug 7 23:28:54 2000 Delivered-To: freebsd-ports@freebsd.org Received: from wind.imbris.com (wind.imbris.com [216.18.130.7]) by hub.freebsd.org (Postfix) with ESMTP id 7DEF037BCFF; Mon, 7 Aug 2000 23:28:47 -0700 (PDT) (envelope-from rickm@imbris.com) Received: from wind.imbris.com (wind.imbris.com [216.18.130.7]) by wind.imbris.com (8.9.3/8.9.3) with ESMTP id XAA33788; Mon, 7 Aug 2000 23:29:16 -0700 (PDT) Date: Mon, 7 Aug 2000 23:29:16 -0700 (PDT) From: Rick McGee To: Matt Heckaman Cc: FreeBSD-PORTS , FreeBSD-SECURITY Subject: Re: pine 4.21 port issues? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matt, I've been using pine since 1995. I've never had a problem. Remember not everyone runs pine. In fact I run imap and ipop3d instead of the traditional popper. If you look at it in the right contents, the settings by FreeBSD is for general user and in their opinion security. I agree but why not set the /etc 751? or chflags schng to the kernel? This would be more secure. The problem is the average new user or in some cases us old ones, would have a tough time. It would mean we might have to read the manual (man page) and heaven forbid if we had to do that! It must be secure but operate under the KISS priciple. Ok, long winded but you get my point. Now for the answer straight from Washington.edu. To protect against conflicts with mail delivery by sendmail, which could cause INBOX corruption, Pine creates lockfiles in the directory /var/spool/mail [1]. The permission setting for that directory should be 1777 (world writable with the sticky bit set). The alternative would be to make all mail programs setgid to some special group -- an unacceptable security risk in the opinion of the Pine developers. By contrast, lockfiles created in the /tmp directory serve interlocking of different Pine sessions with each other, not of Pine with the Mail Delivery Agent. Lockfiles in the /tmp directory are mode 666 because of the case of shared folders (e.g., tenex format) and "kiss of death" functionality (UNIX mbox format and MMDF format). The lock needs to be accessible by processes which may be logged in as another user name; this is a tradeoff between security and functionality. [1] Versions of Pine prior to 3.92 did not warn users when locking in /var/spool/mail failed. Hope it helps. Rick On Tue, 8 Aug 2000, Matt Heckaman wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, 8 Aug 2000, Rick McGee wrote: > : > : Hi Matt, no it's ok and it works rather well. If you look up chmod the > : sticky bit this what you get. 1000 (the sticky bit) When set on a > : directory, unprivileged users can delete and rename only those files > : in the directory that are owned by them, regardless of the permissions > : on the directory. Under FreeBSD, the sticky bit is ignored for > : executable files and may only be set for directories > : > : Rick > > Yes, I know what the sticky bit does :) The point is, that is NOT set on > the directory by default in FreeBSD, nor is the directory world writable, > so why is pine reporting this as a vulnerability? I know that it is not, > but it's causing panic in my users. > > The point is, I strictly control world writable directories on my system, > making /var/mail world writable to satisfy pine seems a silly thing to do > in my opinion. I run qmail on the system through procmail, and all mail > files are owned to the user name and group, ie the files themselves are > not group owned to mail. > > Either way, my point is that since FreeBSD by default does not make > /var/mail sticky or world writable, should not the port include a patch > that modifies this to check based on the proper FreeBSD permissions? > > pine 4.21 on the 4.0-RELEASE port tree worked fine, and did not display > this message, (date: March 19) however 4.1-RELEASE ports pine 4.21 does > give this warning message. I'm going to look into it a tad more on the > code side, and I'll most likely fix it to check the right permissions for > my machines. Is it appropriate for a patch like that to be implimented > into the ports patches? > > I think it's bad that a port reports default FreeBSD permissions as > vulnerable :) > > Regards, > Matt Heckaman > > * Matt Heckaman - mailto:matt@lucida.qc.ca http://www.lucida.qc.ca/ * > * GPG fingerprint - A9BC F3A8 278E 22F2 9BDA BFCF 74C3 2D31 C035 5390 * > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.2 (FreeBSD) > Comment: http://www.lucida.qc.ca/pgp > > iD8DBQE5j5vFdMMtMcA1U5ARAhvoAKCKNhNflkcFOsHTdlYF8zQAcbjSuwCdEsRq > FQ+icogPRkZUHl82q0jDzfI= > =hHcc > -----END PGP SIGNATURE----- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message