Re: Remove GSAppKitUserBundles

[David Chisnall]

It's a potential security risk because it's possible to use it to inject code 
into other apps.  The code can be in the user's home directory, and so are the 
user defaults, so you don't need root access to be able to modify executables.

I would support a flag in Info.plist that is checked by NSApplication to 
disable loading user appkit bundles.  This could be bypassed by either copying 
the application to the user's home directory (losing any setuid flags), or by 
the root user explicitly removing it, but completely removing the ability to 
inject code into applications - even with the user's permission, seems contrary 
to the spirit for Free Software.  We are meant to have the freedom to change 
[the program] to make it do what we wish, and one of the nice things about 
GNUstep is that we often have that freedom even when we don't have the source 
code.

On the idea of sandboxing, I've been playing for a while with the idea of an 
openapp-style wrapper that would use something like nullfs to create a 
directory containing the app bundle, any linked frameworks, and a temporary 
directory, and the socket used for DO, chroot() itself there and then exec the 
app.  This would also need replacements to the standard open panel that would 
(like Sugar) run in a separate process and just pass file handles in to the 
sandboxed app.  

David

On 16 Mar 2011, at 23:55, Matt Campbell wrote:

> I don't understand why such a bundle-loading mechanism is considered a 
> security hole.  IMO, the proper response to security concerns is to sandbox 
> untrusted code; of course, that's outside the scope of GNUstep.
> 
> More generally, a generic mechanism for loading additional modules at 
> runtime, such as this one, allows developers to extend a platform in ways 
> that the platform's creators or maintainers didn't foresee.  It's worth 
> noting that GTK+ has the GTK_MODULES variable for loading extra modules at 
> startup.  Back in the GTK 1.x days, that mechanism was used to develop a 
> prototype screen reader for GTK, before there was a proper accessibility API. 
>  More recently, I've seen that the Openmoko project has a module called 
> libgtkstylus that's loaded through that same variable.  Anyway, I would 
> strongly discourage removing a simple feature that increases the 
> extensibility of GNUstep.  But maybe I just don't understand the security 
> risk.
> 
> Matt
> 


-- Sent from my PDP-11