Re: New method to load user bundles

[Chris Beaham]

Hello Everyone

I've been following the discussion (a small part can be found below)  
regarding GNUstep security with regards to bundles and shared  
libraries, etc..  and IMHO we are possibly missing the obvious:

Security begins with access control to the computer itself!  We are  
talking about malicous bundles and shared libraries and modified  
environment variables, but how is this BAD code suppose to get on the  
system in the first place?!  There are two possibilities: either your  
system is wide open to the public so that anyone can modify ANY part of  
your file system, or you yourself have installed some third-party  
contributed software from some dubious source.  Those people who love  
to download and try every piece of code they find on the net, without  
knowing who produced it or thinking about the consequences, well, they  
are flirting with disaster and they are in themselves THE security hole.

This is IMHO not an Objective-C problem!

Any hacker can write a task in C, or a shell script for that matter,  
that forks itself a hundred times and does massive disk, memory or  
network I/O to the point that the system is virtually unusable.  And if  
he manages to get this code onto your system, by any means, including  
you downloading it yourself, then you're in big trouble.

If it is so important to use contributed software, or commercial  
software for that matter, then it should be equally important to know  
who produced it, who supports it, and finally, who is responsible for  
it and can be held accountable for it!  And IMO this is not just with  
regards to security, this is also related to quality!!!

I understand all of the concerns, but IMO it is a question of  
education; the user must understand and take the precautions necessary  
to prevent unathorized access to his/her system at all levels.  If he  
is not willing to do this, then all of the security hooks and gadgets  
in your application will do nothing to save him from the inevitable  
crash, it will just happen somewhere else in the system.  IMO it would  
be better to spend time writing system specific security FAQ's and Tips  
and include this information in the GNUstep documentation, rather than  
inventing mechanisms to safely load shared libraries, bundles, etc....

It is important to know which end of the gun to hold before you pull  
the trigger!  Education == Security

Cheers!

Chris
not-loud-enough@gmx.net
development@pcs-ag.com



On Dienstag, Juni 3, 2003, at 04:30  Uhr, Alexander Malmberg wrote:

> Jeff Teunissen wrote:
> > LD_PRELOAD can't replace code inside a program, it can only replace  
> > one
> > shared library with another.
>
> This is wrong. LD_PRELOAD tells the dynamic linker to load some shared
> objects, and is equivalent to the code loading part of NSBundle. Eg.:
>
> LD_PRELOAD=/opt/gstep/apps/Camaelon/Camaelon.themeEngine/ix86/linux- 
> gnu/gnu-gnu-gnu/Camaelon
> ~/gstep/Terminal/Terminal.app/ix86/linux-gnu/gnu-gnu-gnu/Terminal
>
> will run Terminal with the Camaelon theme (with a few glitches since
> Camaelon isn't expecting to be loaded this way), and there's nothing  
> the
> app can do about it.
>
> > GSAppKitUserBundles is more powerful than LD_*, because it lets you  
> > modify
> > the app itself, not just the libraries it is linked with.
> >
> > It's well-known that if you use shared libraries, you can't trust  
> > their
> > code. It is also well-known that if you use bundles, you can't even  
> > trust
> > YOUR code.
>
> Normally, neither shared libraries nor bundles modify code inside your
> app, although both could. You may be thinking of categories and  
> changing
> the dispatch tables to not point to your implementations, but this is
> done automatically by all shared objects that contain objective-c
> classes or categories. There is no magic in bundle loading that gives
> their code more capabilities than the code in any other shared object.
>
> - Alexander Malmberg
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep