Re: Using Authorization Services with a Factored Application
Re: Using Authorization Services with a Factored Application
- Subject: Re: Using Authorization Services with a Factored Application
- From: Jonathan Wight <email@hidden>
- Date: Mon, 15 Dec 2003 21:24:40 -0600
Some great information in your post.
On Dec 15, 2003, at 20:33, OL&L Dev 2 wrote:
>
As for Obj-C vs. C, I heartily recommend a C-only helper tool and a
>
Obj-C app for the following reasons:
>
>
2) By writing it in all C, you don't have to suck in all the Cocoa
>
frameworks. You also avoid other problems such as the ones you
>
mentioned (like with self).
Generally you'd just need to suck in Foundation.framework and not all
of Cocoa. Also - there really aren't any problems with 'self' - I think
the original poster was just unsure how to instantiate and call a
Objective-C object from a tool.
>
3) Using an Apple framework in a helper tool is in itself a security
>
risk: the most likely vector that hackers will use in OS X is to
>
replace parts or all of the frameworks, such as Cocoa.framework, with
>
their own malicious code. Then any app that runs will unknowingly
>
suck in the hacked version of the framework. Any code that links to
>
that compromised framework will then be wide open to the hacks. Since
>
your helper tool is running as root and is performing a privileged
>
operation, if a compromised framework is linked to it, it opens the
>
entire system up to the hack - the hack now has root access to the
>
whole machine. Which is the whole point of helper tools to begin
>
with: to concentrate a minimal amount of privileged code running in a
>
single process and to minimize the times at which that code can
>
execute - this providing the secure environment to execute the
>
privileged operation in. Compromising the security of the helper tool
>
essentially defeats its purpose of running separately from the app
>
that is calling it.
This argument is just as valid against a C based tool as against an
ObjC tool. A C based tool will link to libSystem.dylib and if it uses
property lists then to CFFoundation and probably other libraries too.
If you have a compromised system library (be it libSystem.dylib,
CFFoundation.framework or whaterver) then you already have other
troubles and NO binary running privileged is safe.
OTOH The main reason I can see you not wanting to use Objective C is
that it _may_ be possible to trick a program into running 'alien' code.
For example if your tool uses NSUnarchiver to read in data you could in
theory trick it into loading arbitrary objects.
>
4) Performance. C and non-OOP code will execute faster than
>
equivalent OOP code - especially OOP code that uses dynamic binding.
Objective-C is generally fast enough for most purposes. And besides
Helper tools generally interact with the file system or the network and
language efficiency is rarely going to be a factor.
Regards.
Jon.
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.