Why is it more difficult to write a virus for a Mac OS than Windows?
Here are few, there are others as well.
• All Windows background processes/daemons are spawned from a single hyper-privileged process and referred to as services.
• By default, Windows launches all services with SYSTEM-level privileges.
• SYSTEM is a pseudo-user (LocalSystem) that trumps Administrator (like UNIX's root) in privileges. SYSTEM cannot be used to log in, but it also has no password, no login script, no shell and no environment, therefore
• The activity of SYSTEM is next to impossible to control or log.
• Most of the code running on any Windows system at a given time is related to services, most or all of which run with SYSTEM privileges, therefore
• Successful infection of running Windows software carries a good chance of access to SYSTEM privileges.
• Windows buries most privileged software, service executables and configuration files in a single, unstructured massive directory (SYSTEM32) that is frequently used by third parties. Windows will notify you on an attempt to overwrite one of its own system files stored here, but does not try to protect privileged software.
• Microsoft does not sign or document the name and purpose of the files it places in SYSTEM32.
• Windows has no equivalent to OS X's bill of materials, so it cannot validate permissions, dates and checksums of system and third-party software.
• Windows requires that users log in with administrative privileges to install software, which causes many to use privileged accounts for day-to-day usage.
• Windows requires extraordinary effort to extract the path to, and the files and TCP/UDP ports opened by, running services, and to certify that they are valid.
• Microsoft made it easy for commercial applications to refuse a debugger's attempt to attach to a process or thread. Attackers use this same mechanism to cloak malware. A privileged user must never be denied access to a debugger on any system. My right to track down malware on my computers trumps vendors' interests in preventing piracy or reverse-engineering. Maintaining that right is one of the reasons that open source commercial OS kernels are so vital.
• Access to the massive, arcane, nearly unstructured, non-human-readable Windows Registry, which was to be obsolete by now, remains the only resource a Windows attacker needs to analyze and control a Windows system.
• Another trick that attackers learned from Microsoft is that Registry entries can be made read-only even to the Administrator, so you can find an exploit and be blocked from disarming it.
• Malicious code or data can be concealed in NTFS files' secondary streams. These are similar to HFS forks, but so few would think to look at these.
• One of the strongest tools that Microsoft has to protect users from malware is Access Control Lists (ACLs), but standard tools make ACLs difficult to employ, so most opt for NTFS's inadequate standard access rights.
Why this can't happen under OS X:
• OS X has no user account with privileges exceeding root.
• Maximum privilege is extended only to descendants of process ID 1 (init or Darwin's launchd), a role that is rarely used and closely scrutinized.
• Unlike services.exe, launchd executes daemons and scheduled commands in a shell that's subject to login scripts, environment variables, resource limits, auditing and all security features of Darwin/OS X.
• Apple's daemons have man pages, and third parties are duty-bound to provide the same. Admins also expect to be able to run daemons, with verbose reporting, in a shell for testing.
• OS X Man pages document daemons' file dependencies, so administrators can easily rework file permissions to match daemons' reduced privileges.
• Launchd can tripwire directories so that if they're altered unexpectedly, launchd triggers a response.
• If an attacker takes over a local or remote console, any effort to install software or alter significant system settings cannot proceed without entering the administrator's user name and password, even if the console is already logged in as a privileged user. In other words, even having privileges doesn't ensure that even an inside hacker can arrange to keep them.
• OS X has a single console and a single system log, both in plain text.
• OS X's nearest equivalent to the Registry is Netinfo, but this requires authentication for modification. In later releases of OS X, it is fairly sparse.
• Applications have their own per-user and system-wide properties files, private Registries if you like, stored in human-readable files in standard locations.
• Every installed file is traceable to a bill of materials that can verify that the file is meant to exist, and that it and all of its dependencies match their original checksums. Mac users, back up and protect your Receipts folder!
• The directories used to hold OS X's privileged system executables are sacred. Anything new that pops up there is immediately suspect.
