| |||
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
On Mar 3, 2008, at 2:22 PM, Jean-Daniel Dupas wrote:
Le 3 mars 08 à 20:20, Perry The Cynic a écrit :
On Mar 2, 2008, at 5:08 PM, Jens Alfke wrote:
On 2 Mar '08, at 2:56 PM, Rainer Brockerhoff wrote:
Well, if your main binary is tamper-resistant with -kill,hard and you implement some sort of checking for the other resources inside that, producing a modified (but still signed) app becomes, at the very least, extremely hard.
Sure. But how is the user supposed to tell whether the app is still signed? A hacker could just strip the signature after meddling with the binary, and the user wouldn't know the difference.
In order to achieve the nirvana of only running valid code, the system must completely refuse to run unsigned code. Since that would really have ruined third party developers' Leopard experience, we don't do that in Leopard (except for the Parental Controls and firewall cases, where we surreptitiously sign unsigned programs when they are "enabled" to run).
Eventually you will all have signed your recent releases, and we'll have fixed all the (important) bugs and closed all the (important) holes, and a switch will materialize to this effect - to refuse (at the kernel level) to run any code that isn't valid. But not in Leopard. You can all thank me later. :-)
I do not really understand. Even if you implement a "do not run unsigned code" what will prevent an "hacker" to resign the application with his own certificat and rules?
Of course it's not just going to be "run any signed code no matter who signed it." It's going to be "run validly signed code that satisfies this Code Requirement." Where "this" can be anything the administrator and/or user likes - "just Apple code," or "anything made by this list of manufacturers", or "just the programs on this list", or any combination thereof.
The point of running no unsigned code is to deny the attacker the ability to just strip the signature off an inconveniently signed program. Anything based on code identity must be opt-in (white-list) rather than opt-out (black-list).
I know the Code Requirement part of Code Signing isn't very exposed in Leopard, but it's got the ability to do any of those and much more. And it's in the end the same problem (and the same solution) as "only load those input managers," or "only allow those plug-ins," or perhaps even "only use those haxies." Once the system has a way to specify code identity, these all become possible.
_______________________________________________ Do not post admin requests to the list. They will be ignored. Apple-cdsa mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/apple-cdsa/email@hidden
| References: | |
| >Re: Application code signing confusion (From: Rainer Brockerhoff <email@hidden>) | |
| >Re: Application code signing confusion (From: Jens Alfke <email@hidden>) | |
| >Re: Application code signing confusion (From: Perry The Cynic <email@hidden>) | |
| >Re: Application code signing confusion (From: Jean-Daniel Dupas <email@hidden>) | |
| >Re: Application code signing confusion (From: Perry The Cynic <email@hidden>) |
| Home | Archives | FAQ | Terms/Conditions | Contact | RSS | Lists | About |
Visit the Apple Store online or at retail locations.
1-800-MY-APPLE
Contact Apple | Terms of Use | Privacy Policy
Copyright © 2007 Apple Inc. All rights reserved.