From owner-freebsd-ports@FreeBSD.ORG Sat Jan 13 19:19:52 2007 Return-Path: X-Original-To: ports@freebsd.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8103E16A415 for ; Sat, 13 Jan 2007 19:19:52 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id 146AF13C45A for ; Sat, 13 Jan 2007 19:19:51 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so943013uge for ; Sat, 13 Jan 2007 11:19:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nEBQ1uyhg3UVeUSVcSqCKGg0uO/N+0bPW6zNm+PyvKlDGro/620vmomdAqVhC4DA5meVeOdWoCaMwMpD6oNx7Aln46qObJvyDytVVF/DAR8ap6Tw6ecGKVK/AyDpmLs+9ei1pretSawDH0ZHy+nLNn+xKlH55avE/9OlS0+I5K8= Received: by 10.78.81.20 with SMTP id e20mr1329376hub.1168715990712; Sat, 13 Jan 2007 11:19:50 -0800 (PST) Received: by 10.78.164.20 with HTTP; Sat, 13 Jan 2007 11:19:49 -0800 (PST) Message-ID: Date: Sat, 13 Jan 2007 22:19:49 +0300 From: "Andrew Pantyukhin" To: "Simon L. Nielsen" In-Reply-To: <20060613234027.GC1074@zaphod.nitro.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060613113151.GC8105@heechee.tobez.org> <200606131037.58401.amistry@am-productions.biz> <20060613234027.GC1074@zaphod.nitro.dk> Cc: FreeBSD Ports , Doug Barton , Anish Mistry , UMENO Takashi , Tobias Roth Subject: Re: xlockmore - serious security issue X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: infofarmer@FreeBSD.org List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2007 19:19:52 -0000 On 6/14/06, Simon L. Nielsen wrote: > On 2006.06.13 18:51:48 +0400, Andrew Pantyukhin wrote: > > On 6/13/06, Anish Mistry wrote: > > >On Tuesday 13 June 2006 07:54, Andrew Pantyukhin wrote: > > >> On 6/13/06, Anton Berezin wrote: > > >> > On Tue, Jun 13, 2006 at 03:18:16PM +0400, Andrew Pantyukhin wrote: > > >> > > The problem is that xlockmore exits all by itself when > > >> > > left alone for a couple of days. It works all right overnight, > > >> > > but when left for the weekend, it almost certainly fails. I > > >> > > just come to work and see that my workstation is unlocked, > > >> > > what a surprise. > [...] > > >I just stick with a blank screen and works fine for several weeks at a > > >time. I found some of the GL screensavers to cause problems. > > > > Ask me - we should mark this port forbidden and/or make > > and entry in vuxml until we resolve this issue. Let's make > > blank screen the default behavior or something. To leave > > this as is is unacceptable. > > FORBIDDEN and a VuXML entry seems in a way a bit overkill to me seems > a bit overkill to me, since it's not really a vulnerability, but I'm > open to input. > > As mentioned by others, xlockmore is fundamentally flawed > wrt. guaranteeing that the screen stays locked in that the > screensavers code can kill the lock, which it should not be able to > happen. > > Has anyone contacted the xlockmore author for comment on this issue? > > One thing we could do right now is to add a message at install time > warning that xlockmore might unlock the screen (a bit like the Pine > warning). High time we settled on something. Now that we had this discussion, I only use the swarm mode and never had any problems with it. But what about those who still don't know about the issues? I've been in situations where accidental unlocking was unacceptable. In most cases unlocking implies immediate root access to the local machine (which is also possible, but more complicated, with plain physical access), but more importantly - decrypted auth info in RAM, such as ssh keys. This is a major security breach. IMHO, we can't overestimate it. I'm quite sure an ignorable/overlookable message is not enough. A user must fully understand all the implications of this software being used. If it's fundamentally flawed, let's forbid/remove it _until_ the author has a statement for us, not after that.