> How about if Machine Lock completely disables the usage of the shift > key at startup?
A Machine Lock extension (without a system patch) does not address the other forms of attack I pointed out (re-posted below)
> DO> ANY Mac user with basic experience knows to attempt this method to > bypass extension-type lockouts. Again, I stand by my original > statements that security measures must be built-into the OS rather > than tacked on as applications to be truly effective. Another way of > defeating this method involves booting the CPU from another disk with > an operating system, and then mounting the "locked-out" disk for > attack.
> I don't deny this Daniel, but Machine Lock is at least a start to > prevent nosy people from taking a casual look at the server.
As I recall, Machine Lock was created in response to Marcella/Glen's request for security on an UNSECURE CPU. It cannot fulfill this function.
> People who want to do serious damage etc can ALWAYS pull the plug--on > any computer (without UPS!). If people are seriously converned about > local access security, the phyiscal computer should be physically > secured.
People with basic knowledge of Macintosh startup procedures and troubleshooting learn early-on about the method to bypass extensions. Pressing the Power Button on most macs does the same thing as pulling the plug, albeit a bit cleaner, electrically. Because of this, extension-based "protection" is not effective to stop even the causual snooper. In the original security thread, I did point out that training is also a component of a security program. Such training includes items detailing appropriate location of computing devices and storage media, as well as ancillary equipment.
> DO> 1. REAL security measures include the ability to totally protect files and directories from reading, listing as being written to, linked to, or otherwise modified. Other than the permissions within AppleShare, there is no method within the MacOS to do this other than locking and hiding files. Locking can be undone from the Finder on a local machine, and hiding can be undone with many utilities. Therefore, disabling control of the screen and keyboard I/O are used to prevent access to the Finder. If files are not encrypted then they are accessible by defeating the lockout as I described above, and plainly readible.
> DO> If file/directory permissions, access control lists, and in-process encryption, were implemented INTO THE O/S, the system would be MUCH MORE SECURE from this type of an attack. Attempting to tack it on via an application is a doomed proposition which further complicates other OS operations such as file recovery in the event of a crash.
> Yes, but don't shout at me. > ;)
Sorry, the caps are used for emphasis here.
> DO> 2. REAL security proviodes means to restrict program execution of system processes by their owner and also limits monitoring of such processes so that data is not revealed by "sniffing" the system.
> The more observant readers will notice that you are a UNIX man, > Daniel. In all your wise ideas, why not point out that this is how a > UNIX system operates, and be done with it? Or, get a UNIX system and > do away with the Mac, which will doubtedly ever have a fully secure > operating system. Although, do remember that UNIX's security was added > as an afterthought.
Security provisions in unix implementations vary; not all variants do the things I stated, and security was much LESS an afterthough in unix as it was with MicroSoft products, including NT.
My personal computing preferences (Mac first, then Unix, by the way!!!) are irrelevent in a discussion of security. I can tolerate a fairly lax policy on my mac-based BBS because I control both its local physical access and its network presence/connection and I can tolerate the consequences of loss/corruption of my data. I can rely on my family members and guests to refrain from malicious activity on the CPU hosting the BBS, and excercise the care needed for day-to-day operation. My point in bringing these issues out is not to dissuade Mac users from doing anything other than urging Apple to release an operating system that does provide countermeasures to known threats. I want MacOS to sidestep the pitfalls which plague those who do not learn from the development of secure operating environments for other platforms.
> DO> The MacOS does NOT implement the concept of process ownership and > is therefore susceptible to attacks designed to tap into or hi-jack > running processes. Fortunately not many people currently know how to > do this, but tools for learning about the processes running on a CPU > and what data is involved in their operation do exist and can be used > to break system security.
> Errm, excuse me. Please explain what you mean. I get the feeling that > what you have written here is just designed to scare people. From an > experienced Macintosh programmer, 'tapping into' and 'hi-jacking' > running process is absolute nonsense.
I would beg to differ with you, from my viewpoint with experience in both hardware design and test, as well as some software design. here is why:
1. With the tools available today, can you tell me that you can not stop a running program (Hint: The Power PC is one of few processors that you can actually get to stop ON an instruction without blowing through the pipelines) and analyze the current machine state as well as view internally used data?
I was on a project over eight years ago to develop hardware that essentially accomplished this. Its output was a disk file containing a totally readible representation of the data entered by the user and the program's processed output. Thus it could be mis-used to totally circumvent CPU security. I can only imagine what could be done with today's technology.
2. I have often seen the plain text contents of strings and other program variables in memory locations I thought I should not see when performing various tasks on the mac. Often I see the contents of memory locations that contain data associated with other programs. I have caught several programs doing this. Such poor handling of the memory could also be used to hack a system.
3. Because there is poor memory protection, there is not much to stop clever programmers with good tools from inserting additional code into the system and altering the schedule of the calls so that internal information regarding other system processes is available to their on a periodic basis.
4. Obviously, this code modification cannot easily occur while the CPU is executing the program code, but it can happen in-between runs. Real-time dumps are not neccessary for the compromise to be effective.
> Please don't take offense, but I feel you are exaggerating the problem > somewhat.
I do not feel that I am exaggerating the problem at all. I have a good idea as to what is possible. It may be that the average PC Hack does not know, or does not care to expend the time to learn. The major factors that Macintosh systems rely upon for security are:
1. General lack of knowledge of the internal mechanisms of the firmware, and operating system. Toolbox programming fosters this.
2. Misconceptions that Mac OS and other OS's share common weaknesses in their security.
3. Relatively steep learning curve and high cost involved to become proficient in toolbox programming, when transitioning from older methods.
4. Relatively low levels of CPU deployment in areas where CPU's are vulnerable to sustained, malicious attack by individuals with both the knowledge and the tools to accomplish their task. Crashing a CPU or scrambling the system folder are not the kinds of attacks I am referring to.
5. Use of off-the-shelf products to do the following:
A. Physically protect the CPU.
B. Physically protect the storage media.
C. Allow the users to use the most advanced encryption algorythms with largest keys practical.
a 117MHz PowerPC processor outperforms a 200Mhz Pentium system by 5%. a 200Mhz 603e processor as used in the Apple Performa (home user systems) outperforms a Pentium 200Mhz by 80%. a 200Mhz 603e processor outperforms a Pentium Pro 200Mhz by 40%. a 200Mhz PowerPC 604e processor outperforms a Pentium 200Mhz system by 125% and a Pentium Pro 200Mhz system by 80%.
Nuff Said...
Daniel O'Leary, Sysop KloneZone Mac - A TeleFinder 5.5 Mac/Windows BBS (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)
