Seahorse issues

[Joe Marcus Clarke]

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 at localhost>
> >             Coleman Kane <cokane at 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 causing 
> > : > > > > gnome_keyring_memory_try_alloc(size) to act in a manner that violates 
> > : > > > > its documentation, as well as causing the above bug. I then added the 
> > : > > > > three patches to security/seahorse which I posted into 
> > : > > > > http://bugzilla.gnome.org/show_bug.cgi?id=527193 today:
> > : > > > >   * http://bugzilla.gnome.org/attachment.cgi?id=109055
> > : > > > >   * http://bugzilla.gnome.org/attachment.cgi?id=109056
> > : > > > >   * http://bugzilla.gnome.org/attachment.cgi?id=109057
> > : > > > > 
> > : > > > > These three alter the behavior of Seahorse in the manner I described 
> > : > > > > above, and don't touch gnome-keyring. For all purposes, I *think* 
> > : > > > > gnome-keyring is acting properly here. The consumer of gnome-keyring 
> > : > > > 
> > : > > > 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 approach was
> > : > > > very wrong.
> > : > > > 
> > : > > > > (seahorse) should first be testing if the features that it wants to use 
> > : > > > > are actually provided by the library before it blindingly attempts to 
> > : > > > > use them. This is, IMHO, why gnome-keyring provides the *_try(...) 
> > : > > > > versions of its securemem alloc functions.
> > : > > > 
> > : > > > 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 back.
> > : > > > 
> > : > > > > 
> > : > > > > Additionally, you'll get a seahorse g_warning about unavailable secure 
> > : > > > > memory now too.
> > : > > > 
> > : > > > Thanks for your work here.  Feel free to commit these patches to our
> > : > > > seahorse port.
> > : > > > 
> > : > > > Joe
> > : > > > 
> > : > > 
> > : > > Joe,
> > : > > 
> > : > > 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-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 they
> > : > > don't have mlock() privileges.
> > : > 
> > : > I like this approach.  It's much more central.
> > : > 
> > : > > 
> > : > > 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 that we
> > : > > don't incur the wrath of cross-post-thulu).
> > : > > 
> > : > > 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.
> > : > > 
> > : > > As for the mlock() privilege issue, I am not sure what we'll do about
> > : > > 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... and
> > : > > access to my workstation, I'm *pretty* secure. Things like common-use
> > : > > lab computers, etc... are probably more appropriate for this feature.
> > : > 
> > : > Yes, Linux allows this, but Solaris does not (Solaris and FreeBSD share
> > : > 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 allow
> > : > normal users to make use of the feature.
> > : > 
> > : > Joe
> > : > 
> > : 
> > : 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.
> > 
> > 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.
> > 
> > Warner
> > 
> 
> 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 at .

I saw that.  Thanks!

> 
> 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

-- 
PGP Key : http://www.marcuscom.com/pgp.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-gnome/attachments/20080413/0a0d7a01/attachment.pgp