From owner-freebsd-gnome@FreeBSD.ORG Sun Apr 13 23:34:02 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 BE990106566B; Sun, 13 Apr 2008 23:34:02 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from creme-brulee.marcuscom.com (penna-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 879C98FC18; Sun, 13 Apr 2008 23:34:02 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.2/8.14.2) with ESMTP id m3DNYdG0008687; Sun, 13 Apr 2008 19:34:39 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Coleman Kane In-Reply-To: <1208129416.1279.7.camel@localhost> References: <1208018626.10093.7.camel@localhost> <1208019652.82222.13.camel@shumai.marcuscom.com> <1208020460.10093.20.camel@localhost> <20080412.123845.-216597985.imp@bsdimp.com> <1208129416.1279.7.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-TukdlmtDMkfkSfHBnieZ" Organization: MarcusCom, Inc. Date: Sun, 13 Apr 2008 19:34:01 -0400 Message-Id: <1208129641.46561.9.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on creme-brulee.marcuscom.com 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:34:02 -0000 --=-TukdlmtDMkfkSfHBnieZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2008-04-13 at 19:30 -0400, Coleman Kane wrote: > 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 ca= using=20 > > : > > > > gnome_keyring_memory_try_alloc(size) to act in a manner that = violates=20 > > : > > > > its documentation, as well as causing the above bug. I then a= dded 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 de= scribed=20 > > : > > > > above, and don't touch gnome-keyring. For all purposes, I *th= ink*=20 > > : > > > > gnome-keyring is acting properly here. The consumer of gnome-= keyring=20 > > : > > >=20 > > : > > > You're right. I was hoping to hack g-k in such a way to avoid = having to > > : > > > fix other broken consumers in the future. Of course, my approa= ch was > > : > > > very wrong. > > : > > >=20 > > : > > > > (seahorse) should first be testing if the features that it wa= nts to use=20 > > : > > > > are actually provided by the library before it blindingly att= empts 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 mov= ed into > > : > > > gnome-keyring's court, so you way want to get them to move it b= ack. > > : > > >=20 > > : > > > >=20 > > : > > > > Additionally, you'll get a seahorse g_warning about unavailab= le secure=20 > > : > > > > memory now too. > > : > > >=20 > > : > > > Thanks for your work here. Feel free to commit these patches t= o our > > : > > > seahorse port. > > : > > >=20 > > : > > > Joe > > : > > >=20 > > : > >=20 > > : > > Joe, > > : > >=20 > > : > > I've got a revised version of the patch that allows the seahorse = panel > > : > > applet to work properly, as well as all of the other seahorse-bas= ed > > : > > 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 t= hey > > : > > 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= look > > : > > over. I'll submit a forward of this email to ports@ as well (so t= hat we > > : > > don't incur the wrath of cross-post-thulu). > > : > >=20 > > : > > If it doesn't break anything, and seems to make this thing work f= or > > : > > everyone, then I'll commit it later on (probably tomorrow or Mond= ay). > > : > > 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 a= bout > > : > > that. It would be nice, at some point, to support that feature fo= r > > : > > normal users. As long as I'm diligent about my swap-space, etc...= and > > : > > access to my workstation, I'm *pretty* secure. Things like common= -use > > : > > lab computers, etc... are probably more appropriate for this feat= ure. > > : >=20 > > : > Yes, Linux allows this, but Solaris does not (Solaris and FreeBSD s= hare > > : > the same behavior). Perhaps it's something FreeBSD could allow via= a > > : > sysctl. The default would be to restrict mlock(2) to processes wit= h an > > : > effective UID of 0, but the sysctl could change that behavior to al= low > > : > normal users to make use of the feature. > > : >=20 > > : > Joe > > : >=20 > > :=20 > > : My understanding of the Linux implementation is that there's an rlimi= t > > : for mlock that restricts the maximum usage for unprivileged, and allo= ws > > : unlimited usage for privileged users. This behavior is new as of kern= el > > : 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 >=20 > Joe, >=20 > 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@. I saw that. Thanks! >=20 > Hopefully this will make the newfangled GNOME security apps more usable > on FreeBSD. I hope so, too. I appreciate all the work you put in to tracking this problem down. Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-TukdlmtDMkfkSfHBnieZ 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) iEYEABECAAYFAkgCmGkACgkQb2iPiv4Uz4ccMQCeOL6cifdOFFwmzWShgj1BL1uF 9zAAoKlHLCzZ0twFbfMbWU007i72gfxx =aZOx -----END PGP SIGNATURE----- --=-TukdlmtDMkfkSfHBnieZ--