|
From: | Chris Beaham |
Subject: | Re: New method to load user bundles |
Date: | Thu, 5 Jun 2003 09:13:34 +0200 |
Hello EveryoneI'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 oneshared 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 sinceCamaelon isn't expecting to be loaded this way), and there's nothing theapp can do about it.GSAppKitUserBundles is more powerful than LD_*, because it lets you modifythe 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 trustYOUR code.Normally, neither shared libraries nor bundles modify code inside yourapp, although both could. You may be thinking of categories and changingthe 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
[Prev in Thread] | Current Thread | [Next in Thread] |