Re: Code signing
Re: Code signing
- Subject: Re: Code signing
- From: glenn andreas <email@hidden>
- Date: Tue, 23 Aug 2005 10:40:36 -0500
On Aug 23, 2005, at 9:51 AM, Wade Tregaskis wrote:
In theory, this would certainly be useful (I know I'd probably
find some way to use this, if it was a system provided service).
But from a security perspective, it's much weaker than it seems.
If the goal is to prevent unauthorized plugins from be run (for
example), the attack vector of the original hosting app is still
wide open, so one can hack the original app to ignore the plugin
signing (since the is no signing of the hosting application - it
would have to be the kernel that checks that, which, of course
brings us back to it having to be a system level service for real
security).
So basically, it would be as effective as a form of copy
protection would be, but that doesn't make it secure.
Well, yes and no. I could just as easily say the Unix permissions
model is useless because I could just get the root password and
then do what I want. Obviously there's a way to break any
mechanism, but each one - if implemented intelligently and
appropriate - can add significant security.
Yes and no. From a security policy model, a system is only as secure
as it's weakest attack vector. So adding stronger (more difficult to
break) attack vectors does not alter the security of the system,
though adding weaker (easier to break) attack vectors does reduce
security. However, encapsulating a weak vector inside a strong one
does add to security. For example, knowing that the root password to
my computer is "shazzam" doesn't change the security of the system
since a firewall prevents you from accessing the system (i.e., the
firewall is the stronger component).
In the example I previously provided, you could have a root app
which (for whatever reason) allows users to provide their own
plugins (as in, without an admin installing them) - you'd need some
way to prevent unauthorised plugins from being executed. Sure, you
*could* rig a userland plugin driver, and have some kind of IPC
linking it to your root core (or conversely, abstract the root
requirements into a separate executable), but then you open up
additional attack fronts.
And security is ugly - there are all sorts of attack vectors you'll
never think of. If security is your concern, you've got to think it
through from before the first line of code is written, and it's not
easy (go ahead, read the "Rainbow" books at <http://
www.radium.ncsc.mil/tpep/library/rainbow/> for some formal
definitions of what a "secure system" has to address).
FWIW though, the scheme I just mentioned - abstracting root stuff
into a separate, minimalistic core - is nonetheless the preferred
way for handling such an issue, I would think. But then, it could
still be complemented by (or, if your plugin architecture truly
demands it, require) signed plugins.
It definitely depends on what the original poster is trying to
accomplish. Adding plug-ins certainly opens up another attack
vector. Making them signed would certainly make that specific vector
more secure, but you can't say that your app is _more_ secure because
it has signed plugins (vs the pre-plugin version), so you aren't
increasing the security of the "system" (system in the abstract
sense). You just aren't making it worse (unless the signing is
"weaker" than the existing security of the system of course).
Now if the intent is to prevent malicious plug-ins from being
accidently downloaded/installed, signing them can be a great solution
to that. If it is to prevent the user from subverting the
application (say, cheating on a multi-player game), then there are
other easier attack vectors (such as the input manager and fun with
the Objective-C runtime), so signing them doesn't add anything to the
security of the "system" (i.e., the multi-player game integrity).
Glenn Andreas email@hidden
<http://www.gandreas.com/> wicked fun!
Widgetarium | the quickest path to widgets
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden