Date: Sun, 13 Apr 2008 19:30:16 -0400 From: Coleman Kane <cokane@FreeBSD.org> To: marcus@marcuscom.com Cc: gnome@freebsd.org, "M. Warner Losh" <imp@bsdimp.com> Subject: Re: Seahorse issues Message-ID: <1208129416.1279.7.camel@localhost> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-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 <cokane@freebsd.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1208129416.1279.7.camel>