From owner-freebsd-gnome@FreeBSD.ORG Sun Apr 13 23:30:45 2008 Return-Path: Delivered-To: gnome@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2B1C1065672 for ; Sun, 13 Apr 2008 23:30:45 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id 7BA1C8FC25 for ; Sun, 13 Apr 2008 23:30:45 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id DBHf1Z0180lTkoCAA00V00; Sun, 13 Apr 2008 23:30:07 +0000 Received: from discordia ([24.60.135.75]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id DBWj1Z0011dmTCQ8Q00000; Sun, 13 Apr 2008 23:30:44 +0000 X-Authority-Analysis: v=1.0 c=1 a=aiIX5UjjAAAA:8 a=_B3IQjdZjSaGYv6OidsA:9 a=jqhR0l1m6IxWIaUranEA:7 a=Q80meTBSn_zkFIVynFgvbQJAIt8A:4 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 a=dlxDt7Kv6fM8iOZFkVIA:9 a=4jcgBzoVemsQVbNSYuhJy6xglAwA:4 a=rPt6xJ-oxjAA:10 Received: by discordia (Postfix, from userid 103) id E0A051636F8; Sun, 13 Apr 2008 19:30:42 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.1.8-gr1 (2007-02-13) on discordia X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8-gr1 Received: from [172.20.1.3] (erwin.int.cokane.org [172.20.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by discordia (Postfix) with ESMTP id BC8F31636F9; Sun, 13 Apr 2008 19:30:30 -0400 (EDT) From: Coleman Kane To: marcus@marcuscom.com In-Reply-To: <20080412.123845.-216597985.imp@bsdimp.com> References: <1208018626.10093.7.camel@localhost> <1208019652.82222.13.camel@shumai.marcuscom.com> <1208020460.10093.20.camel@localhost> <20080412.123845.-216597985.imp@bsdimp.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-27awAKqlRj+5+jO8aXF0" Organization: FreeBSD Project Date: Sun, 13 Apr 2008 19:30:16 -0400 Message-Id: <1208129416.1279.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 FreeBSD GNOME Team Port Cc: gnome@freebsd.org, "M. Warner Losh" Subject: Re: Seahorse issues X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2008 23:30:45 -0000 --=-27awAKqlRj+5+jO8aXF0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2008-04-12 at 12:38 -0600, M. Warner Losh wrote: > In message: <1208020460.10093.20.camel@localhost> > Coleman Kane writes: > : On Sat, 2008-04-12 at 13:00 -0400, Joe Marcus Clarke wrote: > : > On Sat, 2008-04-12 at 12:43 -0400, Coleman Kane wrote: > : > > On Fri, 2008-04-11 at 11:54 -0400, Joe Marcus Clarke wrote: > : > > > On Fri, 2008-04-11 at 10:14 -0400, Coleman Kane wrote: > : > > > > I removed your earleir patch, which has the side effect of caus= ing=20 > : > > > > gnome_keyring_memory_try_alloc(size) to act in a manner that vi= olates=20 > : > > > > its documentation, as well as causing the above bug. I then add= ed the=20 > : > > > > three patches to security/seahorse which I posted into=20 > : > > > > http://bugzilla.gnome.org/show_bug.cgi?id=3D527193 today: > : > > > > * http://bugzilla.gnome.org/attachment.cgi?id=3D109055 > : > > > > * http://bugzilla.gnome.org/attachment.cgi?id=3D109056 > : > > > > * http://bugzilla.gnome.org/attachment.cgi?id=3D109057 > : > > > >=20 > : > > > > These three alter the behavior of Seahorse in the manner I desc= ribed=20 > : > > > > above, and don't touch gnome-keyring. For all purposes, I *thin= k*=20 > : > > > > gnome-keyring is acting properly here. The consumer of gnome-ke= yring=20 > : > > >=20 > : > > > You're right. I was hoping to hack g-k in such a way to avoid ha= ving to > : > > > fix other broken consumers in the future. Of course, my approach= was > : > > > very wrong. > : > > >=20 > : > > > > (seahorse) should first be testing if the features that it want= s to use=20 > : > > > > are actually provided by the library before it blindingly attem= pts to=20 > : > > > > use them. This is, IMHO, why gnome-keyring provides the *_try(.= ..)=20 > : > > > > versions of its securemem alloc functions. > : > > >=20 > : > > > Fixing seahorse is the right thing to do. The bug has been moved= into > : > > > gnome-keyring's court, so you way want to get them to move it bac= k. > : > > >=20 > : > > > >=20 > : > > > > Additionally, you'll get a seahorse g_warning about unavailable= secure=20 > : > > > > memory now too. > : > > >=20 > : > > > Thanks for your work here. Feel free to commit these patches to = our > : > > > seahorse port. > : > > >=20 > : > > > Joe > : > > >=20 > : > >=20 > : > > Joe, > : > >=20 > : > > I've got a revised version of the patch that allows the seahorse pa= nel > : > > applet to work properly, as well as all of the other seahorse-based > : > > gadgetry that is installed with the security/seahorse port. This > : > > performs the conditional alloc remappings inside of > : > > seahorse-secure-memory.c, and warns the user appropriately when the= y > : > > don't have mlock() privileges. > : >=20 > : > I like this approach. It's much more central. > : >=20 > : > >=20 > : > > I'm attaching the full patch to security/seahorse here for you to l= ook > : > > over. I'll submit a forward of this email to ports@ as well (so tha= t we > : > > don't incur the wrath of cross-post-thulu). > : > >=20 > : > > If it doesn't break anything, and seems to make this thing work for > : > > everyone, then I'll commit it later on (probably tomorrow or Monday= ). > : > > I'd like to give it time to simmer, in case there are more things > : > > touched by this problem that might come up. > : > >=20 > : > > As for the mlock() privilege issue, I am not sure what we'll do abo= ut > : > > that. It would be nice, at some point, to support that feature for > : > > normal users. As long as I'm diligent about my swap-space, etc... a= nd > : > > access to my workstation, I'm *pretty* secure. Things like common-u= se > : > > lab computers, etc... are probably more appropriate for this featur= e. > : >=20 > : > Yes, Linux allows this, but Solaris does not (Solaris and FreeBSD sha= re > : > the same behavior). Perhaps it's something FreeBSD could allow via a > : > sysctl. The default would be to restrict mlock(2) to processes with = an > : > effective UID of 0, but the sysctl could change that behavior to allo= w > : > normal users to make use of the feature. > : >=20 > : > Joe > : >=20 > :=20 > : My understanding of the Linux implementation is that there's an rlimit > : for mlock that restricts the maximum usage for unprivileged, and allows > : unlimited usage for privileged users. This behavior is new as of kernel > : 2.6.9, and kernels 2.6.8 and earlier use similar semantics to what > : FreeBSD and Solaris do now. >=20 > That's actually not a bad idea... But we need to be careful to make > sure that fork can't be used to multiply the rlimit and make a DoS > possible. >=20 > Warner >=20 Joe, I've gone ahead and committed the ports/security/seahorse patch (to allow it to fall-back to using insecure memory, with a warning) after not getting any bad reports from gnome@ and ports@. Hopefully this will make the newfangled GNOME security apps more usable on FreeBSD. -- Coleman Kane --=-27awAKqlRj+5+jO8aXF0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEABECAAYFAkgCl4EACgkQcMSxQcXat5effgCfbHp24R17TBG7U1FfVVTjTrZT o78An3byqGCsDThHM2+qx59Wy/Pp00tk =i1NX -----END PGP SIGNATURE----- --=-27awAKqlRj+5+jO8aXF0--