Re: Code signing
Re: Code signing
- Subject: Re: Code signing
- From: Wade Tregaskis <email@hidden>
- Date: Wed, 24 Aug 2005 00:51:18 +1000
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.
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.
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.
Wade Tregaskis (AIM/iChat, Yahoo, Gizmo & Skype: wadetregaskis, ICQ:
40056898, MSN: email@hidden, AV iChat & email:
email@hidden, Jabber: email@hidden)
-- Sed quis custodiet ipsos custodes?
_______________________________________________
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