Welcome to the MacNN Forums.

Chuckit · Nov 9, 2007, 04:40 AM

Originally Posted by CharlesS

It also allows things like haxies to rewrite an app in memory while leaving the on-disk representation intact, thus allowing a way to get in and stick your nose where it doesn't belong without setting off any alarms.

Whew, I'm glad we narrowly avoided giving users any freedom with their computers.

Kevin · Nov 9, 2007, 04:42 AM

Not everyone wants to use haxies Chuck.

CharlesS · Nov 9, 2007, 05:09 AM

Originally Posted by Kevin

Because OS X was having SO MUCH trouble with security before this.

Again, an ounce of prevention is worth a pound of cure. Apple is becoming almost omnipresent on college campuses, which are a huge breeding ground for malware. If Apple is not careful, they are going to get bit, which is why I also think they need to tighten up the Leopard firewall ASAP. Security by obscurity is never a good idea, especially when you're becoming less obscure every day. Code signing won't make viruses impossible, but it will greatly limit the amount of damage they can do.

No, this seems more like Apple trying to match MS's code signing ability for other things. Like say, selling mp3s. I just read an article about it a few minutes ago. It seems Apple's main concern here is having the ABILITY to do such a thing.

What does selling MP3s have to do with signing applications?

You can increase security without having to go into measures were one can't even change an icon they don't like.

Sure you can change an icon you don't like. Copying and pasting icons works as it always has and doesn't break anything.

You can't go in and change the .icns file of the application itself, of course.

What seems to be happening in certain parts of the Application will be signed. Parts that can cause trouble. Parts that most people don't mess with in the first place.

I've been playing with this since well before Leopard was released, and you are wrong. Other than stripping a universal binary, deleting a localization, or pasting a custom icon, just about anything you change inside the app bundle will set off the code signing. Altering the Info.plist file (as the OP's tip requires) most certainly will set it off.

Originally Posted by Chuckit

Whew, I'm glad we narrowly avoided giving users any freedom with their computers.

I'm afraid you are going to have to get used to the fact that you are no longer running OS 9.

Kevin · Nov 9, 2007, 05:16 AM

Originally Posted by CharlesS

Again, an ounce of prevention is worth a pound of cure. Apple is becoming almost omnipresent on college campuses, which are a huge breeding ground for malware. If Apple is not careful, they are going to get bit, which is why I also think they need to tighten up the Leopard firewall ASAP. Security by obscurity is never a good idea, especially when you're becoming less obscure every day. Code signing won't make viruses impossible, but it will greatly limit the amount of damage they can do.

But as others said, it should be a feature that one should be able to decide they want or not. Like file vault. Or the firewall being turned on or not.

What does selling MP3s have to do with signing applications?

They could tie this code signing in on with mp3 manipulation. You know, hacking the DRM out of a Apple bought mp3.

Sure you can change an icon you don't like. Copying and pasting icons works as it always has and doesn't break anything.

You can't go in and change the .icns file of the application itself, of course.

I think we both know the first doesn't give the same results as the latter. At least not with me.

I've been playing with this since well before Leopard was released, and you are wrong. Other than stripping a universal binary, deleting a localization, or pasting a custom icon, just about anything you change inside the app bundle will set off the code signing. Altering the Info.plist file (as the OP's tip requires) most certainly will set it off.

The article I read (trying to find it now) talked about how the person coding the app could control what was signed and what was not. If that is the case, then I would have no problem with it.

I'm afraid you are going to have to get used to the fact that you are no longer running OS 9.

OS 9? This has nothing to do with OS 9. As I've been able to hack programs since 10.0.0 to 10.4 with no problems to my liking.

CharlesS · Nov 9, 2007, 05:32 AM

Originally Posted by Kevin

But as others said, it should be a feature that one should be able to decide they want or not. Like file vault. Or the firewall being turned on or not.

Or the root user being enabled or not.

Oh, wait.

They could tie this code signing in on with mp3 manipulation. You know, hacking the DRM out of a Apple bought mp3.

That makes no sense at all. Code signing isn't a copy protection mechanism - it's a way to make sure that a piece of code came from the developer you think it came from and that it hasn't been altered in the meantime. It wouldn't help much to keep MP3s from getting modified, because I'm sure that stripping the signature from a music file wouldn't be any harder than stripping the DRM off in the first place.

If it were imperative to determine that a music file came from a specific source, then code signing would make sense there. I can't think of any relevant scenario where that would be the case, though.

I think we both know the first doesn't give the same results as the latter. At least not with me.

I'm afraid that's going to cause a problem for you in the coming years.

The article I read (trying to find it now) talked about how the person coding the app could control what was signed and what was not. If that is the case, then I would have no problem with it.

Yes, of course the developer is in charge of signing the app. He or she can sign the whole thing, a part of it, or none at all.

OS 9? This has nothing to do with OS 9. As I've been able to hack programs since 10.0.0 to 10.4 with no problems to my liking.

Chuckit was referring to APE, which owes its existence solely to the fact that Mac users were used to being able to hack the system and other applications in evil ways via the old Extensions mechanism in OS 9. Apple killed that off for a reason, and that company which I won't name has been living on borrowed time since the beginning, knowing full well that what they were doing was not only unsupported, but actively discouraged. If the code signing feature works the way I think it does, this may be the time when Apple finally starts bringing down the hammer on them...

PaperNotes · Nov 9, 2007, 07:24 AM

Originally Posted by CharlesS

that company which I won't name has been living on borrowed time since the beginning, knowing full well that what they were doing was not only unsupported, but actively discouraged.

You mean Unsanity

Kevin · Nov 9, 2007, 08:17 AM

Unsanity already claims to have working versions of their programs for 10.5

Coming out soon.

There is always a work-around. I am no fan of theirs. But I would never want to take away the ability for someone who was to have it installed.

Developers in Apple's Mac OS X developer program (ADC) got the final 10.5 GM yesterday. We are still downloading the huge 6.66GB image and as soon as the downloads finish for our developers, we will be hard at work on making our software work on 10.5.

You can keep up to date with the status of haxies and 10.5 by viewing [unsanity] Products Compatibility - Unsanity - Makers of Haxies, small useful utilities that enhance and redefine how Mac OS X works. and we will post more information as we have it on our blog at [unsanity] Weblog - Unsanity - Makers of Haxies, small useful utilities that enhance and redefine how Mac OS X works. . Mac OS X 10.5 compatibility is currently our number one priority.

Horsepoo!!! · Nov 9, 2007, 08:55 AM

Originally Posted by Kevin

Unsanity already claims to have working versions of their programs for 10.5

Coming out soon.

There is always a work-around. I am no fan of theirs. But I would never want to take away the ability for someone who was to have it installed.

The problem isn't so much that the ability shouldn't exist but rather it shouldn't be installed without the user's understanding and consent.

Things like Logitech software or other 'haxies' should not install APE before installing itself. APE should be downloaded by the user, from the APE website...not from a haxie/APE package which buries the details of APE being installed within a Read Me file that nobody reads.

The existence of APE is fine but the way it's being installed by any ol' program that uses its framework without warning the user with big red letters is, frankly, troubling...especially when considering the people that installed Logitech software and got greeted by a blue screen when they upgraded to Leopard.

By giving more responsibility to the user (letting him download the APE framework him/herself), he/she is pretty much saying that he is aware of the consequences of having APE installed and no one entity but him/herself is responsible for damage to his computer or his data.

red rocket · Nov 9, 2007, 10:18 AM

Not a day goes by that I don't curse the universe for leaving me stranded with APE as the only option for customising my system properly. Just tried that Amnesty Singles app, guess what stopped it from functioning? APE. Screw Unsanity.

Person Man · 11:30 AM

Originally Posted by CharlesS

You can't go in and change the .icns file of the application itself, of course.

Originally Posted by Kevin

I think we both know the first doesn't give the same results as the latter. At least not with me.

You know, it seems to me that the entire signature is contained within the relevant CodeResources and other .plist files. One can get their own signature (even self-sign an application) without paying money for their own signature. One could strip out the signature already there, make their modifications, and re-sign the code. The app would, of course, no longer be recognized as coming from the original party, but it would still have all the features of the OS available to it. This would limit modifications to individual users willing to go through all the steps. It also wouldn't work on apps like Pacifist that verify the signature before running.

Also, you don't have to buy a signature if you're going to do this. Developers don't either, unless they want people to be able to verify that they are who they say they are. (Although, depending on the developer, I'd be pretty cautious about any developer whose identity I couldn't independently verify).

Don Pickett · Nov 9, 2007, 11:32 AM

Charles, a question for you about application signing:

I messed up my keychain (long story. Short version: I was dumb) and had to create a new one. Now it seems like every application which needs to use the keychain requires me to type in my admin password. Is this related to application signing, and is there some setting I need to change to have the apps access the keychain without my needing to type in a password all the time?

CharlesS · Nov 9, 2007, 12:49 PM

Originally Posted by PaperNotes

You mean Unsanity

Great, now this thread will turn up in a Google search. Nice going.

Originally Posted by Kevin

Unsanity already claims to have working versions of their programs for 10.5

Coming out soon.

I know they say that, but I think their users are going to find that things aren't going to be as rosy for them as they have been in the past.

Originally Posted by Person Man

You know, it seems to me that the entire signature is contained within the relevant CodeResources and other .plist files. One can get their own signature (even self-sign an application) without paying money for their own signature. One could strip out the signature already there, make their modifications, and re-sign the code. The app would, of course, no longer be recognized as coming from the original party, but it would still have all the features of the OS available to it. This would limit modifications to individual users willing to go through all the steps. It also wouldn't work on apps like Pacifist that verify the signature before running.

Well, I should hope that applications like Mail.app would verify that the signature was the correct one before getting access to the Keychain, because otherwise it would be trivial for a malware app to work around the code signing.

At any rate, it's a pretty easy thing to check.

Also, you don't have to buy a signature if you're going to do this. Developers don't either, unless they want people to be able to verify that they are who they say they are.

That's true. And for shareware/freeware, you are most likely going to be seeing the apps signed with self-signed certificates, since buying them from Verisign is really quite expensive.

Originally Posted by Don Pickett

Charles, a question for you about application signing:

I messed up my keychain (long story. Short version: I was dumb) and had to create a new one. Now it seems like every application which needs to use the keychain requires me to type in my admin password. Is this related to application signing, and is there some setting I need to change to have the apps access the keychain without my needing to type in a password all the time?

Why exactly is it asking for your admin password? What exact message are you getting?

Also, does the code signing for the application that is doing this show as being correct if you verify it with codesign -vv in the Terminal?

Kevin · Nov 9, 2007, 01:01 PM

I have heavily modified a file the REQUIRES admin password privs to even replace without any problems in 10.5

Here is the path

/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Resources/Extras.rsrc

If you can do that,I would think you could mess up the OS in other ways as well.

Unless you are of course saying it's not fully implemented.

I also hacked some resources in iTunes without problems.

I am betting only CERTAIN files and paranoid (some for good reason) developers will use this.

TETENAL · Nov 9, 2007, 01:02 PM

Originally Posted by CharlesS

You'd better get used to it.

Sure, I miss the old days of ResEditing everything, but let's face it - in a world where applications get trusted with keychain settings, application-specific firewall rules, and even root access, we can't have every process on the system being able to modify apps willy-nilly. It's security, and frankly, we need more of it right now.

That's interesting. Because when I was asking for this almost 2 years ago, you were arguing against it:

http://forums.macnn.com/90/mac-os-x/...apple-digital/

TheSpaz · Nov 9, 2007, 01:03 PM

The only App that broke for me so far was Mail and it didn't really break... it still runs fine with all the features and everything, but once per launch, it asks me for my keychain password and then I can get my mail. That's the only App I've had trouble with and I can deal with it... it's actually kinda nice because it will keep other people who may use my computer from retrieving new mail.

By the way, I tried modifying the CodeResources file to add the binary code for info.plist back into it but, I looked and looked and info.plist is not listed in CodeResources yet it lists versions.plist and all the files in the Resources folder. Does anyone know how to patch info.plist into CodeResources? I added info.plist and it's binary code to CodeResources but, it still didn't work. I got this information from this MacOSXHints.com hint: macosxhints.com - 10.5: How to update raw.plist modifications in 10.5 but, as I said, info.plist isn't found in CodeResources... am I out of luck then?

CharlesS · Nov 9, 2007, 01:36 PM

Originally Posted by TETENAL

That's interesting. Because when I was asking for this almost 2 years ago, you were arguing against it:

http://forums.macnn.com/90/mac-os-x/...apple-digital/

Yeah, occasionally, after thinking about something for a while and learning new information that I wasn't aware of before, I can sometimes come to the conclusion that I was wrong about a particular issue and change my position to reflect my current understanding of things. I know that may be a revolutionary concept to a lot of people, but hey. If you went even further back, you'd find me thinking that APE was a pretty cool thing back in 2001 when it first came out, before I realized how many problems it was going to cause. Oh well, it happens, times change, and no one gets everything right the first time around.

My complaint in the thread you linked to is pretty much nullified by the fact that Leopard's code signing works with self-signed certificates anyway.

Originally Posted by TheSpaz

The only App that broke for me so far was Mail and it didn't really break... it still runs fine with all the features and everything, but once per launch, it asks me for my keychain password and then I can get my mail. That's the only App I've had trouble with and I can deal with it... it's actually kinda nice because it will keep other people who may use my computer from retrieving new mail.

What you mean is that Mail was the only app that broke in a way you were able to notice. You most definitely did break the code signing on every app you did this to, and anything that ends up trying to use the code signing feature with those apps in the future is not going to work properly.

By the way, I tried modifying the CodeResources file to add the binary code for info.plist back into it but, I looked and looked and info.plist is not listed in CodeResources yet it lists versions.plist and all the files in the Resources folder. Does anyone know how to patch info.plist into CodeResources? I added info.plist and it's binary code to CodeResources but, it still didn't work. I got this information from this MacOSXHints.com hint: macosxhints.com - 10.5: How to update raw.plist modifications in 10.5 but, as I said, info.plist isn't found in CodeResources... am I out of luck then?

If I'm not mistaken, the CodeResources file is also signed... so if you change it, you're going to break the code-signing, even if you do figure out the correct way to unsign something else.

goMac · Nov 9, 2007, 01:50 PM

Originally Posted by Kevin

Because OS X was having SO MUCH trouble with security before this. No, this seems more like Apple trying to match MS's code signing ability for other things. Like say, selling mp3s. I just read an article about it a few minutes ago. It seems Apple's main concern here is having the ABILITY to do such a thing.

Someone wasn't paying attention to the month of Apple bugs.

Originally Posted by Kevin

You can increase security without having to go into measures were one can't even change an icon they don't like. That's going backwards instead of forwards. That is WHY I said it was MS like.

Hate to break it to you, but even changing an icon or a TIFF could be a security hole. I mean, look at the TIFF buffer overflow exploits. Someone could theoretically take control of an application just by changing out a TIFF inside.

Originally Posted by Kevin

What seems to be happening in certain parts of the Application will be signed. Parts that can cause trouble. Parts that most people don't mess with in the first place.

This doesn't work. If a "good" part of the application was taken over, it could be patched to request admin privs and wipe the entire drive. There is nothing stopping "safe" code from being turned into "dangerous" code.

Originally Posted by Kevin

I think some people are running around exaggerating what will and wont happen with code signing. When even Apple hasn't even put anything in stone yet.

Apple has warned developers they need to get used to code signing. This is the transition period before Apple fully implements restrictions. A lot of apps write to their own application directories and Apple doesn't necessarily want to break those... yet.

Big Mac · 02:01 PM

If I understand him correctly, Kevin is saying that Apple shouldn't take new measures to secure the OS unless they're made necessary by the existence of previous exploits. Kevin's view seems to be similar to the view of security held by M$ for many years, and we know how that turned out. In short, Kevin's view seems like a very backward approach to security. I'd rather Apple be proactive in securing the OS than Apple being forced to play catch up with a potential explosion of malware that could have otherwise been prevented by the types of security features Apple is now implementing. Security comes with some loss of unencumbered accessibility; the question is whether or not the tradeoff makes sense. I think it does in this case because it seems to be a major step forward in security with very little usability sacrificed; it makes sense to implement it especially since we've now seen the first true OS X trojan horse.

Kevin · Nov 9, 2007, 02:16 PM

No that isn't my view at all. I am saying am not so sure everything is set in stone like some people are acting like.

I am also saying if such "securities" hinders OS usage and being able to make it "yours" then those that like to do that, will look elsewhere.

There will ALWAYS be possibilities of bad things going wrong with computers. The biggest mistakes are made in between the keyboard and chair.

What I am saying is, they should make the feature thar can be turned on or off. If you are really concerned you can turn it on, if not, turn it off.

Just like you can most any other OS X "security" device. For example, FileVault.

I LOVE the idea of such things. I just think the ability to turn it on or off, even with certain apps like you would a firewall is a better solution.

There is nothing wrong with having a CHOICE. And if your computer gets screwed up, it's your fault.

Apple could even turn it on by default, and then give a warning "By turning off blah blah blah"

Big Mac · Nov 9, 2007, 02:24 PM

Okay, sorry for misunderstanding you - I agree that one should be able to turn off Code Signing.

Kevin · Nov 9, 2007, 02:27 PM

And about the month of Apple bugs goMac, how many people do you know personally that have gotten an OS X virus? And I am not talking about APE installers

BTW me and gomac are probably one of the longest running anti-APE style hacks ranters on the forums.

Since day one we both saw how such a thing could go horribly wrong and mess all kinds of things up.
It DID remind me of old extensions in OS 9. Whoever made that connection earlier was right.

But having said that, I would never want Apple to make it so someone couldn't install something like that if they wanted. Apple just wouldn't have to support said software.

goMac · Nov 9, 2007, 03:10 PM

Originally Posted by Kevin

Unsanity already claims to have working versions of their programs for 10.5

Coming out soon.

I'm not sure what Unsanity's planning. Given that the whole point of code signing is to prevent patching, if they do find a work around I expect Apple to immediately issue a patch stopping their workaround. I'm not sure if Unsanity is... unsane enough to go against Apple.

Originally Posted by Person Man

One could strip out the signature already there, make their modifications, and re-sign the code. The app would, of course, no longer be recognized as coming from the original party, but it would still have all the features of the OS available to it. This would limit modifications to individual users willing to go through all the steps. It also wouldn't work on apps like Pacifist that verify the signature before running.

This is true, but it would still mean Code Signing would have accomplished it's goal of keeping an untrusted app away from your personal data. If you change the signature of an app it can no longer access things that it did with it's old sig.

Originally Posted by Kevin

I have heavily modified a file the REQUIRES admin password privs to even replace without any problems in 10.5

I'm pretty sure HIToolbox will be signed soon. It's not signed right now.

Originally Posted by Kevin

I also hacked some resources in iTunes without problems.

If you've hacked iTunes, you've invalidated it's signature, and iTunes won't be able to purchase songs without asking you your password. I wrote a post in the GUI customization thread showing that hacking iTunes does invalidate the signature.

Originally Posted by Big Mac

Okay, sorry for misunderstanding you - I agree that one should be able to turn off Code Signing.

I can understand wanting to turn off code signing, but there are many technical reasons why this won't work. I'll just skip straight to the main one.

If codes signing can be turned off, then a virus would simply turn off code signing before it infected Safari and stole all your banking passwords.

Originally Posted by Kevin

And about the month of Apple bugs goMac, how many people do you know personally that have gotten an OS X virus? And I am not talking about APE installers

Just because no one has infected OS X, that doesn't mean it's not secure. Many of the Month of Apple bugs were working concepts that someone could have actually used. Code signing addresses most of those issues.

(Ironically enough, Unsanity could have used code signing to help prevent their Month of Apple bugs issue.)

Unless you are seriously suggesting Apple should wait to patch security problems until they are actually used for a virus.

Kevin · Nov 9, 2007, 03:27 PM

Originally Posted by goMac

If codes signing can be turned off, then a virus would simply turn off code signing before it infected Safari and stole all your banking passwords.

Well someone could just turn off file vault too. But they would first have to have admin password to do it. I assume the same would be with signatures.

Just because no one has infected OS X, that doesn't mean it's not secure. Many of the Month of Apple bugs were working concepts that someone could have actually used. Code signing addresses most of those issues.

Well cool. If one is worried about such things code signing would be great. For those that are not, we shouldn't be inconvenienced over it.

Unless you are seriously suggesting Apple should wait to patch security problems until they are actually used for a virus.

No, I am saying Apple should let it be up to the user as far as how paranoid he wants to go.

CharlesS · Nov 9, 2007, 04:08 PM

Originally Posted by Kevin

Well cool. If one is worried about such things code signing would be great. For those that are not, we shouldn't be inconvenienced over it.

The thing is, that's the same argument the OS 9 holdouts used to argue against the multi-user system in OS X and the fact that you have to enter an admin password to mess with system files and such.

It's also the same logic Microsoft used with XP that caused every user to basically have root access in the out-of-the-box setup, and we all know how that turned out.

voodoo · Nov 9, 2007, 04:34 PM

Originally Posted by CharlesS

The thing is, that's the same argument the OS 9 holdouts used to argue against the multi-user system in OS X and the fact that you have to enter an admin password to mess with system files and such.

It's also the same logic Microsoft used with XP that caused every user to basically have root access in the out-of-the-box setup, and we all know how that turned out.

I don't agree that you can compare this to anything previous. This is a first. Permissions on files can be changed. This is like the new translucent menubar, in the sense that it can't be turned off.

User preferences be damned. Security is necessary, but code-signing is not nearly as necessary as you are making it out to be. Not even close.

The old system in Tiger worked fine even though it didn't pass the 'mom' test. I'm no mom. I understood that system and it worked just as well as code-signing, since I knew what I was doing.

Using that over code-signing should be optional. Simple as that. As safe as code-signing.

V

TheSpaz · Nov 9, 2007, 04:39 PM

We've never had code-signing in the past... why is it an issue now? I've gone all these years without it... I'm not really that scared. I like to hack my Apps and change the icons within them. (Just pasting the icon over the top of the icon in the Finder doesn't always work when you have badges appear such as in iChat... or alert messages from within the App would be the old icon still).

I like to customize... if this means the end of customization... that's gonna suck.

CharlesS · Nov 9, 2007, 04:51 PM

Originally Posted by voodoo

As safe as code-signing.

Not really:

Quick, what caused this to pop up? Was it a legit change, was it a virus, was it something mundane like prebinding, or was it something else? You don't know. As a result, 99.9% of users are just clicking "Change All" every time to make the dialog go away.

Plus, if a virus used some other method - like an APE haxie - to rewrite your app in memory rather than on disk, you'd never get this message at all. Then, the virus could steal all your passwords, and you'd be none the wiser. It's hardly as safe as code-signing - in fact, it's a glaring security hole, and we're basically just lucky that it hasn't been exploited yet.

Horsepoo!!! · Nov 9, 2007, 04:51 PM

Originally Posted by TETENAL

That's interesting. Because when I was asking for this almost 2 years ago, you were arguing against it:

http://forums.macnn.com/90/mac-os-x/...apple-digital/

Interestingly, I commented in that thread too...but my comments were in answer to paying some outside source to digitally sign an executable.

AFAICT, the digital signatures present in Leopard are different. The developer signs his own executable so that no one can tamper with it without breaking it. This is a whole lot different than a certificate of authenticity. A malicious developer could sign his own virus if he wanted to...the idea however is that his virus wouldn't get far in a world full of signed apps.

And once broken, the user only has to reinstall his app...and the virus is destroyed.

goMac · Nov 9, 2007, 04:53 PM

Originally Posted by TheSpaz

We've never had code-signing in the past... why is it an issue now? I've gone all these years without it... I'm not really that scared. I like to hack my Apps and change the icons within them. (Just pasting the icon over the top of the icon in the Finder doesn't always work when you have badges appear such as in iChat... or alert messages from within the App would be the old icon still).

Linux and WIndows have had code signing for quite a while.

There have been exploits prototyped which code signing fixes. In essence, the Mac OS keychain has always been wide open. Any app can pretend to be Safari or Mail and steal all your passwords. Code signing finally closes this security hole.

With Apple's marketshare climbing these sorts of things need to be dealt with before someone actually does decide to build a virus based on these security holes. It's not like Apple added Code Signing just to be safe. Apple added code signing to plug known security holes.

goMac · Nov 9, 2007, 04:57 PM

Originally Posted by Kevin

Well someone could just turn off file vault too. But they would first have to have admin password to do it. I assume the same would be with signatures.

Of course, if an infected app had root privs, this would still be rendered completely ineffective, and Safari could be programmed so that all your passwords were stolen.

There is also a social problem involved. All Unsanity would have to do is issue an installer that disabled code signing. Obviously, this is what you guys are asking for... but then again, you guys know about code signing. When you look at it from Apple's perspective... they could be dealing with millions of users downloading said software that disables code signing. These users would have no idea what code signing is, or what code signing being off means. All these users would be open for infection.

TheSpaz · Nov 9, 2007, 04:58 PM

Originally Posted by voodoo

I don't agree that you can compare this to anything previous. This is a first. Permissions on files can be changed. This is like the new translucent menubar, in the sense that it can't be turned off.

User preferences be damned. Security is necessary, but code-signing is not nearly as necessary as you are making it out to be. Not even close.

The old system in Tiger worked fine even though it didn't pass the 'mom' test. I'm no mom. I understood that system and it worked just as well as code-signing, since I knew what I was doing.

Using that over code-signing should be optional. Simple as that. As safe as code-signing.

V

So, before... if you didn't know what you were doing... you could screw up an App. Now... even if you KNOW what you're doing... you still screw up the App... that just sucks. CodeSigning is evil because what if I WANT to change the App? If I go and make the changes myself, it shouldn't punish me... if someone else makes the changes behind my back such as another App or outside source, then it should warn me.... but, not when I make the changes myself.

goMac · Nov 9, 2007, 04:59 PM

Originally Posted by TheSpaz

So, before... if you didn't know what you were doing... you could screw up an App. Now... even if you KNOW what you're doing... you still screw up the App... that just sucks. CodeSigning is evil because what if I WANT to change the App? If I go and make the changes myself, it shouldn't punish me... if someone else makes the changes behind my back such as another App or outside source, then it should warn me.... but, not when I make the changes myself.

How do you propose OS X tell the difference?

Horsepoo!!! · Nov 9, 2007, 05:04 PM

Originally Posted by goMac

How do you propose OS X tell the difference?

White-list of 'Good Guys that are allowed to modify apps'
Black-list of 'BAD GUYS!!!'

Obviously the TheSpaz falls in the Good Guys category.

goMac · Nov 9, 2007, 05:07 PM

Originally Posted by Horsepoo!!!

White-list of 'Good Guys that are allowed to modify apps'
Black-list of 'BAD GUYS!!!'

Obviously the TheSpaz falls in the Good Guys category.

Of course in a world of AppleScript the "good guys" can be remote controlled to do anything the bad guys want.

Big Mac · Nov 9, 2007, 05:09 PM

There's no way to tell good from bad unless you want Code Signing; that gets us back to square one.

Horsepoo!!! · Nov 9, 2007, 05:09 PM

Originally Posted by goMac

Of course in a world of AppleScript the "good guys" can be remote controlled to do anything the bad guys want.

That's true. Mac OS X would need to exclude the Bad Guys from using AppleScript.

goMac · Nov 9, 2007, 05:11 PM

Originally Posted by Horsepoo!!!

That's true. Mac OS X would need to exclude the Bad Guys from using AppleScript.

You'd also need to make sure the good guys didn't have any known exploits.

goMac · Nov 9, 2007, 05:11 PM

Originally Posted by Big Mac

There's no way to tell good from bad unless you want Code Signing; that gets us back to square one.

Quite well put.

Kevin · Nov 9, 2007, 06:03 PM

Again there is no reason for this not to be optional. Other than people being code signing nazis.

goMac · Nov 9, 2007, 06:20 PM

Originally Posted by Kevin

Again there is no reason for this not to be optional. Other than people being code signing nazis.

There are many good reasons why this is not optional. We just gave a bunch of them on this page of the thread.

If it is optional, there is nothing preventing a bad program from turning them off, admin privileges required or not. Not to mention, if you did turn them off, you'd completely break how the keychain works in 10.5. Keychain can only operate in one mode or the other. It cannot switch modes.

Kevin · Nov 9, 2007, 06:38 PM

Originally Posted by goMac

There are many good reasons why this is not optional. We just gave a bunch of them on this page of the thread.

And I replied to them showing you were that can still happen. You can make it so turning it on or off requires a admin password. If you don't trust yourself you can reject things that ask for it. Or turn this thing on. If you do, you shouldn't have to. I bought the computer etc, I should be able to screw it up if I really want to. Unless they plan on taking people to court for changing icons and the like.

If it is optional, there is nothing preventing a bad program from turning them off, admin privileges required or not.

Well so? That's a chance some people are willing to take. I don't think you are getting what I am saying. Some people don't CARE if it works or not. Some aren't that interested in security, or would have a reason to worry about someone hax0ring their Mac. What I am getting from you is, you are saying that you should disable it because then it wouldn't work. Well why would you disable it if you wanted it to work? Some people don't.

Not to mention, if you did turn them off, you'd completely break how the keychain works in 10.5. Keychain can only operate in one mode or the other. It cannot switch modes.

Unless they recode it so it does...

goMac · Nov 9, 2007, 06:59 PM

Originally Posted by Kevin

And I replied to them showing you were that can still happen. You can make it so turning it on or off requires a admin password. If you don't trust yourself you can reject things that ask for it. Or turn this thing on. If you do, you shouldn't have to. I bought the computer etc, I should be able to screw it up if I really want to. Unless they plan on taking people to court for changing icons and the like.

Let me repeat this.

An app with admin privileges could be hijacked. At this point it could turn off code signing, and then get all your passwords by hijacking another app.

Originally Posted by Kevin

Well so? That's a chance some people are willing to take. I don't think you are getting what I am saying. Some people don't CARE if it works or not. Some aren't that interested in security, or would have a reason to worry about someone hax0ring their Mac. What I am getting from you is, you are saying that you should disable it because then it wouldn't work. Well why would you disable it if you wanted it to work? Some people don't.

You're right. Normal people certainly don't care if Safari is hijacked, sends all their back account passwords to some guy in Nigeria, and then get all their money stolen. It just simply isn't something people want to protect against.

You know that if you turn off code signing this could happen. 90% of people who would install apps that would automatically turn off code signing would not understand this.

Originally Posted by Kevin

Unless they recode it so it does...

Ok. Let me be frank. It is impossible for them to recode keychain so it does as you ask. If Apple codes keychain so that there is a secondary way to get items in the keychain, it completely ruins the point of code signing in the first place.

The point of code signing is the only applications that can get at your personal data are the ones that put it there. If you allow applications to get at keychain using non-signing protected methods, you've basically destroyed any reason to have code signing to begin with. For code signing to be effective, the one and only way for any application to get keychain data must be if they are correctly signed.

Kevin · Nov 9, 2007, 07:03 PM

Originally Posted by goMac

Let me repeat this.

An app with admin privileges could be hijacked. At this point it could turn off code signing, and then get all your passwords by hijacking another app.

That could still happen. There is always going to be a work aroung gomac.

You're right. Normal people certainly don't care if Safari is hijacked, sends all their back account passwords to some guy in Nigeria, and then get all their money stolen. It just simply isn't something people want to protect against.

Nevermind. I am going to go hunt some wabbits.

goMac · Nov 9, 2007, 07:08 PM

Originally Posted by Kevin

That could still happen. There is always going to be a work aroung gomac.

No, because admin apps can't turn off code signing. If AppleFileServer (which has admin privs) is hijacked via a remote exploit, it can't get at the password that Safari has saved for your bank account.

If AppleFileServer could turn off code signing with it's admin privs, it would turn off code signing, patch Safari, and then make Safari read all the keychain items and send them god knows where. Code signing will stop this because as soon as Safari is patched Safari is cut off from it's keychain.

Look, I can understand people wanting to modify applications, but code signing, among other things, addresses some pretty big security issues on the Mac. As Mac marketshare grows, the last thing we need is viruses and spyware.

Kevin · Nov 9, 2007, 07:13 PM

Grows from 3% to 5%...

Like I said, no one should ever complain about options. If not EVERY SINGLE THING is code signed then it wont work. And I am sure you'll have developers or people that simply don't want to play along.

goMac · Nov 9, 2007, 07:15 PM

Originally Posted by Kevin

Like I said, no one should ever complain about options. If not EVERY SINGLE THING is code signed then it wont work. And I am sure you'll have developers or people that simply don't want to play along.

Any application that requests a "signed" operating is automatically signed by the application. For example, specifying a rule for an application in the Firewall automatically signs said application. Limiting an application in parental controls will also automatically sign it. In addition, as has been mentioned, all of Apple's apps are signed, and Apple is recommending all developers start signing apps as part of their development process.

Kevin · Nov 9, 2007, 07:17 PM

Well we will see what this is all about when it all comes to pass. So far all the stuff I've been told has amounted to a lot of FUD. Before 10.5 came out I was told I wouldn't be able to change the scroll bars. That it would make the computer not work.

I am not going to get upset about something not many people really know a ton about.

goMac · Nov 9, 2007, 07:30 PM

Originally Posted by Kevin

Well we will see what this is all about when it all comes to pass. So far all the stuff I've been told has amounted to a lot of FUD. Before 10.5 came out I was told I wouldn't be able to change the scroll bars. That it would make the computer not work.

I am not going to get upset about something not many people really know a ton about.

Right, but we're in a transition period here. Honestly, the restrictions Apple has put down are pretty light right now so that bad applications, such as ones that write to their own Applications bundle, get time to adjust. In the future, Apple may require all applications to be signed or else they will not run, and also immediately quit an application if it's signature becomes invalid. If you look at some code signing demos they have done, they have certainly given themselves the power to do those things, and I don't think they just coded those sort of things because they were bored one weekend.

Person Man · Nov 9, 2007, 08:02 PM

Originally Posted by goMac

Right, but we're in a transition period here. Honestly, the restrictions Apple has put down are pretty light right now so that bad applications, such as ones that write to their own Applications bundle, get time to adjust. In the future, Apple may require all applications to be signed or else they will not run, and also immediately quit an application if it's signature becomes invalid. If you look at some code signing demos they have done, they have certainly given themselves the power to do those things, and I don't think they just coded those sort of things because they were bored one weekend.

Yes, and there will always be people who won't listen, and won't do it until they're forced to by the operating system.

A good example of this is Saft. The developer had created a version that functioned as a Safari launcher, inserting itself as a browser plug in at the time of launch of Safari, but as soon as he discovered that you can still use InputManagers in 32 bit code if you jump through a bunch of hoops (put in place to discourage their use), he jumped through those hoops and released the Leopard compatible version as an InputManager. Until 10.5.(6 months from now) which finally kills InputManagers for 32 bit code, which promptly breaks Saft. Then Apple is to blame, because "Saft worked before the new update."

Had the developer kept the non-InputManager method of implementation, then when that new release that disables InputManager comes out, his app might still work.

Until Apple chooses to force the issue by making Leopard refuse to run unsigned (or broken signed) apps, not every developer will sign their apps. And there will be users who blame Apple, and not the developer. "Booyeah.app worked JUST FINE until Apple released the new update." Not, "it's DevCo's fault because they didn't listen to Apple."

goMac · Nov 9, 2007, 08:07 PM

Originally Posted by Person Man

Until Apple chooses to force the issue by making Leopard refuse to run unsigned (or broken signed) apps, not every developer will sign their apps. And there will be users who blame Apple, and not the developer. "Booyeah.app worked JUST FINE until Apple released the new update." Not, "it's DevCo's fault because they didn't listen to Apple."

Right, but Mac OS X is correcting for these developers by automatically signing their apps with a self generated key.