[gamin] Re: gamin library

[y9toi7y02 sneakemail com]

Here's a conversation between Daniel and me about the gamin library.

Note that I am not on this list. The 'from' address really does lead back
to me though. I'll read the list through the archives too.

Martijn Vernooij

-snip-

On Tue, 27 Jul 2004, Daniel Veillard wrote:

> On Tue, Jul 27, 2004 at 04:17:52PM +0200, Martijn Vernooij wrote:
> > On Tue, 27 Jul 2004, Daniel Veillard wrote:
> >
> > >   Please use the mailing list,
> > Ummm.. some people don't like mail about vulnerabilities being sent to
> > public mailinglists before the author had a chance to look at them.
> >
> > Feel free to forward this to the mailing list though, but /please/ do mask
> > my email address.
>
>   I won't. I want discussion to be processed publicly. Sorry, if you want
> to give feedback I want it public at this point. Hiding your email makes
> no sense to me.
>
> > > On Tue, Jul 27, 2004 at 03:16:50PM +0200, Martijn Vernooij
> > wrote:
> > > > Isn't there a temp file vulnerability in gamin_connect_unix_socket if
> > > > 'HAVE_ABSTRACT_SOCKETS' isn't defined?
> > >
> > >   Well the process should run under the same account as both the server
> > > and the client check - using the first null byte exchanged - that the
> > > other side uid is the same. There is no vulnerability in the sense
> > > that you can be fooled only by a process running at the same priviledge.
> > > This can also be worked around by defining GAM_CLIENT_ID environment to
> > > be a unique ID.
> >
> > It's not about the server trusting clients when it should not, it's about
> > what would happen if someone placed a symbolic link pointing to one of the
> > user's files in /tmp/fam-<username>- before the library is started. It's
> > not unreasonable to believe the user's file would be truncated or
> > replaced.
> >
> > Creating temporary files without unpredictable names is very hard to do
> > securely and is the source of many security holes. I don't know the
> > semantics of the unix socket system in this regard but I think it is
> > not defined what will happen.
> > >
> > > > For all it's worth, other programs create a directory for themselves in
> > > > /tmp with appropriate umask and then create files in that directory,
> > > > avoiding the vulnerability (they are still vulnerable to tmpwatch though).
> > >
> > >   yeah but for all intend I expect to have abstract sockets available
> > > anyway plus the other side uid check, those together provide a secure
> > > library.
> > >
> > > Daniel
> > No offence intented, but IMHO one should not allow a library to work if it
> > cannot work in a secure way, and if you would, it would have to come with
> > strong warnings.
>
>   Public feedback and patches appreciated. Sorry I do not believe in an
> unarchived out of band process to fix potential problems at this point since
> the code isn't even deployed widely.
>
>   thanks,
>
> Daniel
>
> --
> Daniel Veillard      | Red Hat Desktop team http://redhat.com/
> veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
> http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
>