[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Use of GSAppKitUserBundles/Camaelon issues with Gorm

From: Gregory John Casamento
Subject: Re: Use of GSAppKitUserBundles/Camaelon issues with Gorm
Date: Thu, 1 Jan 2004 13:50:48 -0800 (PST)

See below...

--- Alexander Malmberg <address@hidden> wrote:
> Gregory John Casamento wrote:
> > All,
> > 
> > I am writing this email to caution anyone using Camaelon that, since
> Camaelon
> > uses    poseAs: on some classes that it may cause problems with Gorm
> encoding
> > since it, in using poseAs:, replaces some of the classes in the Objective-C
> > runtime.   There is nothing that Gorm can do to detect this, so far as I
> know.
> > 
> > The above is just one example of the kinds of problems that can be caused. 
> I
> > also concerned about malicious use of this default to insert code into an
> > application.
> In order to do that, an attacker would have to be able to read and write
> your defaults. If that's the case, you've lost already.

The point is that it is a wide open door for security compromise.  If an
attacker manages to root the machine, he can then collect even more passwords
by doing this.  It's a security hole plain and simple.

> > I propose a simplistic solution:
> > 
> > A call-back, or a notification, or something that tells the application
> that
> > it's about to load a bunch of bundles and allows that application to make a
> > decision, at that point, to either allow or disallow the loading of the
> > bundles.
> The GSAppKitUserBundles mechanism (I assume this is the one you're
> talking about) is there specifically to give users an easy, standard way
> of loading arbitrary bundles into arbitrary apps. Giving apps a way of
> overriding it defeats its purpose, and would be the wrong thing to do.

The application should be given the option to refuse to load bundles that might
be incompatible.   Allowing users to load bundles which utilize poseAs: and
might, in effect, replace a number of classes that

> Apps have no business trying to prevent a user from adding bundles to
> it. OTOH, users have no business expecting support when they do
> non-supported things, and you're free to only support standard
> configurations (or none at all). :)

Yes, but as you said, adding bundles is "supported".   The problem with your
assertion is that you're expecting the user to know when applications are
compatible with certain user bundles and when they are not.   That's putting
the responsibility on the wrong shoulders.   The application developer should
be the one to determine if he/she wants the application to load user bundles or

> Is there a Camaelon page? 


> It'd be probably be a good idea to mention
> that it shouldn't be used with Gorm on that page, and give instructions
> for disabling it in Gorm; I think a simple "defaults write Gorm
> GSAppKitUserBundles ''" would be enough.

Yes, that is very simple.

This could also be done programmatically within the application itself.   It
would be a simple matter of moving the default to another name and moving it
back when applicationDidFinishLauching: is called.   So, you see, there is
already a way to do this, but it's a little obscure and a bit of a hack.  This
is why I wanted to do it using a callback.  That way it's clean and doesn't
risk corrupting the user's defaults.

> - Alexander Malmberg

Later, GJC

Gregory John Casamento -- CEO/President Open Logic Corp.
-- bheron on #gnustep, #linuxstep, & #gormtalk ---------------- 
Please sign the petition against software patents at: 
-- Main Developer of Gorm (featured in April Linux Journal) ---

Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003

reply via email to

[Prev in Thread] Current Thread [Next in Thread]