I must tell you that am really enjoying this conversation... I hope that others are getting as much from it as I am. Sometimes what I type is not what I meant, or I may state it unclearly so that more than the intended meaning can be inferred. (Both cases are undesirable) Here are my latest responses.
>> Yes, but you can just as easily turn off the computer. Your info on the PowerPC being able to stop wherever is irrelevant here. Anyone with a debugger can get access to an application's data. However, who is silly enough to install a system debugger on a supposedly secure server mac? <<
Hmm, read what I said again....especially the part about NOT blowing the machine state. Turning off the computer does not give you access to the information within it., which is the objective of most attacks.
Actually a debugger is a handy tool for every Mac, at least until all the crashes are resolved. (gee when can we hope for that???) Unfortunately it can also be used for much more than legit diagnostics because you can probe just about anywhere with it.
>> Maybe. However, if you can go to these lengths (get hardware in, access the motherboard, etc), you would surely also be ready to simply take the computer and fiddle with it at your leisure at home? <<
Hardware is not needed to do this today... which is a part of my point now as it was back in my original comment: The server CPU should be physically secure, no matter what kind it is.
>> Yes, but only if a person has direct access and a debugger-style app. If they have direct access, then they will then be able to access such things anyway. What kind of strings have you 'though I should not see'?? <<
I have seen lots of crap in the input dialogs of certain applications that turned out to be string data from OTHER applications. This is inexcusable and could be used to recover logins and passwords and other sensitive data. Such sloppiness is being addressed in internet applications today. It should likewise be addressed in the MacOS and applications of tomorrow.
>> Memory protection isn't really so much of an issue here. Again, the key is that people AREN'T going to get to this stage (no shouting, just emphasis ;) because inherently with the Mac one doesn't need to go this far to discover secretive data. I realise that this is your key point, but I am trying to show that this nonsense about tapping into or hijacking processes isreally irrelecant. <<
My point is that it should not be possible to "get to this stage" so easily. Since there is no such thing as process ownship on the Mac, one task can examine the memory occupied by another. With more effort, the memory of the "snooped on task" can be altered by external means. This is very relevent to the topic of discussion.
>> DO> 1. General lack of knowledge of the internal mechanisms of DO> the firmware, and operating system. Toolbox programming fosters this.
Toolbox programming isn't the only aspect of MacOS programming. It's what people who aren't in the know assume the mac is all about because that's what they hear about from time to time. <<
My statement is not intended to offend or belittle toolbox programming. Quite the contrary, I see it a flexible and beneficial, as well as imparting an element of difficulty to those who would attempt to create a hostile application that exploits the firmware directly.
When I stated that toolbox programming fosters a general lack of of internal knowledge of internal firmware details, I was referring to the contents of firmware and OS that are not visible because they are "hidden inside the tools." In the pre-toolbox programs I wrote , I used published (and unpublished) entry points into the system firmware (PROM) and operating system. I also had assembly listing of the sourcecode to the firmware routines, so I knew where to go to get what I wanted. These approaches do not apply any longer from what I have seen of Mac programs. I would not event know how to make them work, given the number of firmware/OS combinations out there.
The complete, low-level, details of the firmware routines are not revealed to application programmers and do not need to be. The actual system routines may or may not exist where the published toolbox entry points are. (I suspect more often than not, the two are different, as the firmware and OS design change with time.) The mechanism for *using* the routines in a developers application is what is known and used by application developers.
The indirect methods used by tool calls are the best way to promote compatibility, but at somewhat less understanding of how and where code runs. (Thank goodness!!!) The indirect methods used would appear to make it hardware to create a hostile application that exploits the firmware directly.
>> DO> 3. Relatively steep learning curve and high cost involved to DO> become proficient in toolbox programming, when transitioning from older DO> methods.
I disagree--(toolbox==mac programming in general) the Mac is very easy to get to grips with, provided the learner can understand the event/object driven programming model. In addition, the inner workings of the system are fairly elementary, and may be mastered without much difficulty. Provided one is familiar with a debugger (eg MacsBugs), practically anything can be done. <<
Perhaps I am dated since I come from the non-toolbox school, but I do understand the event-driven model. The "high cost" and "steep learning curve" I am referring to are when compared to other older methods (as I said before) and were most likely more applicable in the earlier days of the mac.
I didn't need a ton of expensive references and fancy development systems to write and compile programs the non-toolbox way, but the the ones I wrote were tailored to the hardware and memory configuration of the system. They would not function as relocatable code, and made few calls to simple firmware routines. The addresses of the called routines were not hidden either. Geeze it was fun. By constrast, you can do almost no application programming without information on the use of toolbox routines and the new compilers are expensive, unless you want a stripped down version.
I would not begin to tackle a hand-coded implementation of the complexity of today's programs, nor would I wish that on anyone else, even when the implementation is limited to one hardware/OS combination. The cost in man-hours would be prohibitive and the payoff minimal.
>> Once again my key point is that all your program-hacking points aren't of relevance, because of the inherent insecurity of the Mac. People don't really need to go to all this trouble. Hence scaremongering. <<
The "inherent insecurity of the Mac" is made up of things such as those I brought up. Your statement: "People don't really need to go to all this trouble" shows that the severity of the problem, if anything, is worse. If the Mac is to be touted as a secure system, especially in an unsecure commercial environment, then these things should be addressed in the next incarnation of the O/S and CPU's. Access control and process ownership become important immediately when more than one person uses the CPU, whether or not that use is concurrent. Ditto for memory protection and memory management. These things were not part of the MacOS because it was designed to primarily be be a single user system. Things get much more complex when multiple users which to have, what appears to them as full use of the computer, but with their data protected from all others, network threats, etc. My point in all of this is to stress what should be made a part of the next MacOS if it is to succeed in unsecure commercial environments such as "point of sale" application.
As long as the mac "stays at home" I suppose these are not strong points, but I would ask you how long do you give the Mac to exist, if it only stays at home? I would absolutely love to see a Mac chosen over other platforms in the business world (including my job site, where Macs are being replaced with WinTel CPUs) based upon its power, its ease of use and its superior security features.
--- Daniel O'Leary, Sysop KloneZone Mac - A TeleFinder 5.5 Mac/Windows BBS 10036 North Suttonwood, Fort Forth TX USA 76108 (817)367-2558 (Voice) (817)367-2712 (Dial-in) 1:130/1015(Fido) klonezone.tfnet.org (TFNet) kzpwrmac.cyberhighway.net (Internet) http://kzpwrmac.cyberhighway.net (WWW)
