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: Dave Camp <email@hidden>
- Date: Tue, 16 Dec 2003 11:26:49 -0800
On Dec 15, 2003, at 6:33 PM, OL&L Dev 2 wrote:
1) All of the Apple docs and sample code such as MoreAuthSample are
in straight C (to my knowledge there is no Obj-C helper tool
example). MoreSecurity is also written in straight C. You will need
to use its functions to facilitate calling the tool.
One of the new project templates is a Foundation tool. I've written a
number of Cocoa tools and they work just fine. I don't see how calling
C code from Obj-C is an issue here.
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).
Why is this a problem? It should not affect your real memory usage.
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.
You would have this problem with any tool, regardless of the language.
A Carbon tool could be compromised by replacing any of the Carbon
frameworks. A POSIX tool could be compromised by replacing any of the
system libraries. The list goes on...
4) Performance. C and non-OOP code will execute faster than
equivalent OOP code - especially OOP code that uses dynamic binding.
This is mostly a non-issue these days. Obviously if you are doing
something CPU intensive you need to be aware of what you are doing and
code appropriately.
Dave
---
The path of least resistance, it's not just for electricity any more.
_______________________________________________
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.