Windows vs Mac Security 513
sdhorne writes "There is a good technical discussion over at InfoWorld on the merits of launchd and what is lacking in a comparable Windows secure solution. It is a throw back to the UNIX vs Windows security discussion that has been hashed out for many years." From the article: "it always traces back to Microsoft's untenable policy of maintaining gaps in Windows security to avoid competing with 3rd party vendors and certified partners. Apple's taking a different approach: What users need is in the box: Anti-virus, anti-spam, encryption, image backup and restore, offsite safe storage through .Mac, and launchd. Pretty soon any debate with Microsoft over security can be ended in one round when Apple stands up, says 'launchd', and sits back down."
Re:Well written, but (Score:5, Informative)
What's launchd? (Score:5, Informative)
In Mac OS X v10.4 Tiger, Apple introduced a new system startup program called launchd. The launchd daemon takes over many tasks from cron, xinetd, mach_init, and init, which are UNIX programs that traditionally have handled system initialization, called systems scripts, run startup items, and generally prepared the system for the user. And they still exist on Mac OS X Tiger, but launchd has superseded them in many instances. These venerable programs are widely used by system administrators, open source developers, managers of web services, even consumers who want to use cron to manage iCal scheduling, and they can still be called with launchd.
The launchd daemon also provides a big performance boost to your system. At any given time, only those daemons that are actually used are launched; combined with the fact that daemons can shut themselves down and be relaunched as needed means that you can reduce the average memory footprint of the system.
http://developer.apple.com/macosx/launchd.html [apple.com]
Unfortunately his reasoning is flawed. (Score:5, Informative)
This is a substantial win. However, if you manage to compromise a process that is running as root, you do have full control of the machine, and you can install your own privileged software on the machine without an authentication prompt appearing on the console.
Also, most of the man pages on OS X are woefully out of date, so giving the existence of these as a reason for why security is better on OS X is unfortunately a cruel joke. Third party apps from the Open Source community do often have better documentation, but the basic man pages from OS X are often years out of date - this is one of my pet peeves about OS X, I will admit.
It sounds like the hack he's describing occurred because he'd installed third-party software that ran as a service with an open port, as SYSTEM (i.e., with full privileges) and that took over his machine. The reason this is less likely (not impossible, just less likely) is because if you are running a third party server process on OS X, it's probably a piece of open source software like Apache, which has been vetted to within an inch of its life, because it is open source, and the many people who care that it is secure have the freedom to check that it is secure. And it probably doesn't run with full privileges, as the author says.
Anyway, like I said, he's right, but his reasoning is a little foggy. And it's important to be aware of the ways in which it's foggy, because this is your best chance of avoiding having your machine hacked.
Re:in fairness to microsoft (Score:2, Informative)
Anti-virus software in the box? (Score:5, Informative)
Re:But what if Microsoft offered it all together? (Score:4, Informative)
Psst. They're called OEMs. Try buying a PC from a big-box store these days without Mcafee or Norton on it.
Re:I might be missing something, but.... (Score:3, Informative)
Re:Market Share (Score:4, Informative)
Re:UNIX and viruses (Score:5, Informative)
When people say something like that, hold them by hand and take them over to netcraft.com and show them the market share of Web servers. Apache has been owning >60% of it for a long long time compared with ~20% share for IIS. And point out that almost all the worms attack IIS and not Apache. The reason why Windows/IIS remain vulnerable is because MS wrote them, not becuase of their high/low market share.
Re:Well written, but (Score:5, Informative)
.Mac is not "safe". (Score:4, Informative)
dot Mac is not in any way secure / "safe storage". Unfortunately I bought a subscription before I realised how dangerously unsecure it is. When I started to configure Backup, I thought I'd do some digging first to see what was going on. It turns out that credentials are sent in plaintext. Communication between the user and mac.com is not encrypted. Storage on iDrive is also not encrypted. Backup archives have no encryption.
It's completely wide-open to snooping attacks, and nobody should trust anything to it besides their weekly grocery list or other documents that they don't mind any snoopers (wireless interceptors or Apple employees) from freely browsing. I expect a major security breach is inevitable.. it's just a matter of time. It would take one person with a wireless snooper at Macworld, gathering hundreds of juicy high-profile targets to mess with - and dot Mac will be destroyed by a torrent of negative publicity.
Of the entire Apple product range, dot Mac is the one that is most stuck in the early 90's. It works.. but is a severely inadequate solution.
Re:Microsoft is just too nice? (Score:4, Informative)
Bundling is fine if OEMs, such as HP, Dell, and Compaq, can UNBUNDLE IE and install Firefox, for example. What happened was that Microsoft threatened Compaq with withholding OS licenses if they installed Netscape Navigator as the default web browser. Had they ONLY bundled, nothing would have been brought up against Microsoft.
Re:Market Share (Score:3, Informative)
If OSX had that kind of a market share, youd bet your ass that everyone would be breaking down its walls, in exactly the same way.
Most people keep their money in their mattress. If most people had home safes, everyone would be breaking into safes and taking their money in exactly the same way.
Do you see how this analogy exposes the flaw in your logic? To show a classic example, IIS has a much smaller market share than Apache, but is compromised more often. If OS X had an equal market share as Windows, OS X would still be compromised less often for the following reasons:
Would you rather it effect Apples measly market share, or Microsofts dominant machine?
It depends upon my motivation. Ideally, it would run on both. The thing is, there is plenty of motivation for crackers to write malware for OS X, simply to gain publicity and respect in the community or to shut up smug mac users. It hasn't happened yet because there are a lot of barriers besides market share.
Most mac users are just as dumb as most windows users, they just tend to have some sort of superiority complex.
I'm not sure this is true. There are plenty of dumb users on both systems, but a lot of the security industry has moved to macs, providing a greater likelihood a mac malware will end up on the machine of someone with a clue. More importantly, however, mac users can be dumb, and because they have a more secure system by default, they are still not exploited as often.
neither is really better than the other, from a sheer 'does this work' standpoint.
I strongly disagree as do most users I know that have actually run OS X and Windows as their regular machine. From both a security perspective and a general use perspective, OS X is a more usable desktop machine for most people. Just because OS X is not perfect for security, does not mean it is as bad as the abysmal mess that is a standard Windows installation.
I think he has some points there (Score:5, Informative)
The biggest flaw in Windows is stuff running as SYSTEM. Try this in Windows: schedule a command in a terminal to run cmd.exe the next minute using the "at" command. As you will notice, you will get your cmd.exe... running as SYSTEM. You don't even have to be a very privileged user to do that, kill your own explorer.exe and start explorer.exe in that cmd.exe you have and guess what: you're running your system as SYSTEM. This would be like running Bash, KDE or Gnome as root, although possible, you can't elevate root out of standard user rights. Same thing for hooks into IIS (.NET) or any other application, they can all elevate to SYSTEM without too much trouble. Would be like suggesting to run Bind or Apache as root, and as any Unix guru would say: Blasphemy! Blasphemy! and you would feel the vibration of Rich Stevens (http://en.wikipedia.org/wiki/W._Richard_Stevens) spinning in his grave at the speed of the fan running in the server.
A few points (Score:5, Informative)
[From the article]
SYSTEM doesn't trump Administrator(s): since either can control the kernel, they both represent full control. SYSTEM can't magically bypass security descriptors any more than administrators can; both have but indirect end runs available. SYSTEM's profile has the global system environment. In Win32, shells have considerably less importance, but SYSTEM processes can still have them. SYSTEM's actions can certainly be audited, so I'm not sure what they meant by impossible to log.
There are lots of services running as low privilege LOCAL SERVICE and NETWORK SERVICE. Perhaps there could be more. Note that a single svchost can represent several services.
The binaries that implement system services are protected by system file protection. SFP isn't a security feature; it's there to work around buggy installer behavior.
This isn't true on a domain where the admin has designated installable packages, and RunAs works fine for installation programs that are written properly.
I'm not sure what's meant by this, but if your kernel is owned on any OS, a rootkit can be installed to evade any kind of debugging.
Non-human-readable? Never used the registry editor? The key and value names seem to be in English... It's like saying that a filesystem isn't human-readable because you need ls. There are no plans to make the registry obsolete for system configuration. In fact, the new boot loader's config database is a registry hive. As for owning the computer throught the registry, every key is protected by an ACL. There's nothing inherant in the registry that allows an attack, privilege escilation or otherwise.
So then the admin takes ownership of the keys in question, forcibly with the SeTakeOwnershipPrivilege, and since the owner of an object can always set the DACL, the admin returns himself full control. Either that or use the SeRestorePrivilege to overwrite the key directly.
What's wrong with the shell's ACL editor? What's wrong with the default permissions?
Since root can ignore security, this isn't saying anything. In Windows, only the kernel can bypasss security.
Re:Market Share (Score:5, Informative)
There are PLENTY of hackers out there, of every level, who would absolutely love to be able to point to themselves as the first "l33t hax0r" to write a real world OS X virus and "wipe that stupid little grin off their [Mac user's] smug little faces."
And in the six years OS X has been out, not one, NOT ONE, has succeeded.
Re:But it still has the rootkit fallacy (Score:4, Informative)
There is, by default, no valid password for this account, and the gui does not volunteer information about it as an account for people to log into. But the account very much exists, and is used.
Re:Anti-virus software in the box? (Score:4, Informative)
Re:Concept Versus Implementation (Score:4, Informative)
Up until a few weeks ago, people in the *nix world didn't want to look at launchd because of "contamination concerns" regarding Apple's open source license. However at the recent WWDC, Apple announced that launchd (among other things) is being relicensed under the Apache License - so hopefully that will do the trick for the open source crowd.
I realize that there are always going to be some GNU fanboys that won't touch anything unlesss it's under the GPL, of course.
Re:What's launchd? (Score:5, Informative)
The story I heard was that a bunch of Apple engineers got tasked with improving OS X boot times, and the problem they kept running into was the way that init worked. In order to create a good way of launching stuff simultaneously (when possible) and generally making everything boot quickly, they ended up just writing a new system for launching services, and the result was launchd. It also minimizes the number of running daemons at any one time, saving memory and processor cycles, and can start and stop them as-needed. Apparently you can also do some neat stuff like actually feed programs commands rather than just start/stop, but I've never used that.
I think Apple's hope was that other UNIX-ish systems might like the launchd concept and replace init with it, but I'm not sure that the faster boot times will really be worth the retraining costs for systems that aren't booted up often.
The things I dislike about launchd, aside from the traditional UNIX objection to anything which is New And Therefore Bad, is that its config files are XML instead of flat text, which I find obnoxious, and that it makes it marginally more difficult to see what services are running on a given system. You can be running a local mailserver but not have a daemon active, because launchctl will bring up postfix as needed. If you're not looking for it, you can miss the fact that postfix is set up. (However you can program it to bring up particular services and leave them -- in fact you can use init and cron normally, if you like.)
I still use cron for scheduled tasks as well, because I've never wanted to figure out how to replicate cron with Apple's stuff, but I'm told it can do that, too.
Overall I think it's pretty neat, and for a desktop-UNIX system it's a major step forward. For a server or non-desktop environment, I think the benefits are more mixed.
My Response (I know you want to read it!) (Score:3, Informative)
Microsoft does not sign or document the name and purpose of the files it places in SYSTEM32
Most, if not all of the files can be identified through a simple Google search. It doesn't get Microsoft off the hook -- they should provide proper documentation, but such information is available.
Windows requires that users log in with administrative privileges to install software, which causes many to use privileged accounts for day-to-day usage.
Not all software. User-level installations should be possibly to non-restricted directories.
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.
TCPView [sysinternals.com]. Now you have it. And since Microsoft now owns Sysinternals, I guess they have it too.
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.
This is not really Microsoft's problem. If no one can remember the features of the OS, it's their fault when they overlook them.
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.
Duty-bound? Sure, they probably all provide them because that's what everyone else does, but most Windows applications include a help file too.
Launchd can tripwire directories so that if they're altered unexpectedly, launchd triggers a response.
I believe TripWire exists for Windows too.
The UNIX/POSIX API, standard command-line tools and open source tools leave malware unable to hide from a competent OS X administrator. It takes a new UNIX programmer longer to choose an editor than it does to write a console app that walks the process tree listing privileged processes. Finding the owners of open TCP/UDP ports or open files is similarly trivial. The "system" is not opaque.
I may be wrong here, but aren't their other ways of injecting malware into a system than setting it up as a detectable process? I know on Windows machines there are a number of ways to get around a process walk -- does the same thing exist in *nix?
Re:What's launchd? (Score:4, Informative)
Microsoft's no-win situation (Score:2, Informative)
And if they did, a lot of the same people who praise Apple for including such features would scream "MONOPOLY!!!" Microsoft can't win on this issue. Either they're not secure, or they're being anticompetitive.
I'd prefer the latter, but then MS learned that such "bundling" lands them in court long before Apple released OSX.
Re:My Response (I know you want to read it!) (Score:1, Informative)
Yes, this is the idea behind a rootkit. Get root access, then modify the system's tools in such a way that they don't reveal your evil software. They exist for *nix systems as well as Windows.
Re:What's launchd? (Score:5, Informative)
Launchd will bring postfix up as needed. But, launchctl is what you want to use to see what launchd has loaded. And that is loaded, not necessarily running. The command you want to use is "sudo launchctl list". For example, mine shows org.postfix.master and com.openssh.sshd, which aren't actually running but will be activated when there is traffic on the specified ports. Of course, you'll also notice org.xinetd.xinetd. Nothing by default runs under xinetd, but if you've added a server, it could be in /etc/xinetd.d rather than in the launchctl list.
The XML vs. flat file debate has been fought all over the web, so I won't rehash it here, but I think the benefits of machine-parseability are worth it and it uses Apple's standard plist format, so it is consistent the rest of the OS.
Overall, launchd is a huge step forward. Apple has open-sourced it and it would be interesting to see it implemented in other systems. Perhaps Solaris can use it in exchange for giving us ZFS (10.5).
Re:But what if Microsoft offered it all together? (Score:2, Informative)
By your rationale, Microsoft's Notepad and Wordpad, and Apple's Text Edit would all violate the law because they are bundled with the OS and there are definitely existing markets for word processing.
Actually, it is very arguable that Wordpad is illegal bundling, but it is really more of text editor than a word processor and whether or not it competes with an existing market is debatable. I think MS actually settled out of court with several companies over this very inclusion. As for TextEdit, it is not a violation because OS X is not a monopoly in any market.
Having a large market share of a product is not the same as having a monopoly.
This is true, although many laws specify 70% of a market as a guideline for potential monopoly influence.
If Apple starting buying up other companies and disolving them, or put pressure on retailers of the iPod to not sell competing brands, that would be illegal.
The former actually would not be illegal. The latter would be illegal if and only if Apple was found to be wielding monopoly power in the market in which iPods are sold as defined by the court. There are many indicators of monopoly influence and the iPod is definitely coming close in some ways.
Making a product that sells insanely well is not illegal...
You're missing the point. It isn't illegal to have a monopoly or gain a monopoly. It is illegal to use a monopoly to gain more money from other markets. If Apple gains a monopoly on iPods, nothing stops them from maintaining that monopoly, but the law makes it illegal for them to bundle or tie that monopoly to other markets. That means they can no longer bundle iTunes with iPods unless they are willing to include every other jukebox software someone asks for. That means they can't tie the iPod to the iTunes music store by refusing to let other music sellers include the same level of DRM that music from the iTunes store does. Note, all of this is if they have a monopoly. Microsoft does have a monopoly.
Let me clarify the bundling issue for you. If I have no monopolies I can bundle anything I want with anything. If I have a monopoly on say, televisions, I'm prevented from bundling anything with those televisions. For example, if I started building DVD players into my televisions, I'd quickly own the DVD player market as well, since no one will buy another DVD player when they had to get one included with their TV anyway. Even if my DVD players are inferior quality, they would still take over the market so long as they were just "good enough." In the same way it is illegal for MS to bundle a Web browser. IE is inferior to firefox, but it is just "good enough" that most people use it anyway, since otherwise they have to go out and find a different browser and most don't even know they can do such a thing. Whether or not it can be removed after the fact is irrelevant. If I bundled a DVD player with every TV, but you could easily remove the DVD player and throw it away would most people throw it away and buy a different one? Of course not. When you buy Windows you paid for the IE developers' work regardless if you throw it away later. Hence it is the initial bundling that matters, not the ability to remove it after the fact. Also note, it only prevents me from bundling not others. If Circuit city wants to give away a free DVD player with each of my TVs they sell, nothing is stopping them, just as nothing stops Dell from bundling Windows and IE and selling them. Only the monopolist is forbidden from doing so.
I hope that clarifies things.
Re:the article may have some good points, but... (Score:2, Informative)
Re:Well written, but (Score:5, Informative)
simply removing a filthy icon from the QuickLaunch menu while leaving the whole pile of unsafe, vulnerable infrastructure INTACT, completely BETRAYS the meaning of the word UNINSTALL.
Sheesh... and people talk about Jobs's Reality Distortion Field
Re:Well written, but (Score:2, Informative)
Re:Well written, but (Score:2, Informative)
You only need admin privileges to install software in the system-wide
Re:Total crap (Score:3, Informative)
Think about what the complaint is about, even if not well written: NTFS allows secondary streams, and the only programs that use them for the most part are Malicious. The complaint is that the OS allowing access to these streams is YET ANOTHER point of contention. It is not an exploitable hole (in the hacker sense), but it is exploitable by hackers (in the making Windows hard as hell to keep secure). Simple to close that up.., yet Microsoft just seems completely unconcerned.
Launchd allows you to specify rights. You get a lot more control of the order processes are started. Launchd, like xinit, allows you to start processes on demand. Launchd can control who/what is allowed to start processes, unlike the "net start" command, "oh it's set to automatic, great, I'll start it" mentality.
Overall, I give you 4 MEH's out of 5.
Author is clueless about how Windows works. (Score:1, Informative)
* The server service is the service that allows file/printer sharing in Windows and other remote admin capabilities. Since things that only administrators might have access to might be accessed through the server service, running it under a lesser priviledged account cannot be done since the server service must be able to access everything that it provides access too. The bottom line is, the server service is an extermely sensitive service that must be protected. It's Microsoft's fault for enabling/exposing this service by default, but this has nothing to do with the fact that the server service needs "root" permissions. In OSX and other unix-type OS's, there are several different daemons that for one reason or another have to have root permissions.
* Contrary to what the author writes, the SYSTEM account can be logged, audited, and access rights can be taken away from it...and no, it's not hard to do.
* In one of his "bullet points" the author says "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.". Boo frikken hoo! If you are a Windows server admin, and you can't grasp the concept of filesystem (and registry) ACLs, then you are in the wrong proffession.
* The author says "All Windows background processes/daemons are spawned from a single hyper-privileged process and referred to as services." This is flat out wrong. The "Services" exactuable is used to run many services, but it is not required to run all services, and the priviledges it carries depend on how the induvivual service is configured. It's very easy to run Windows services as regular user accounts, and the "services.exe" executable need not be involved at all. I've run MSSQL server and several other third party services as "guest" users on Windows. They work just fine.
* The author says, "By default, Windows launches all services with SYSTEM-level privileges.". Again, the author is dead wrong. The "LocalService" and "NetworkService" accounts do nOT have system-level priviledges. In fact they are severly limited in what they can do.
I could go on four hours refuting his "bullet points" (85% of them are flat out wrong),but what's the point?
happy ignorance everyone!
Re:Well written, but (Score:3, Informative)
Well, you need to take the timeframe in which I wrote that article into account. I started writing it back when launchd was brand new and had it share of issues. (FWIW, I think the reported SSH issues were due to a, now corrected, bug in lookupd.) My hesitant approach to it was due to a healthy dose of old fashioned administration by skepticism. For a while I was turning back to xinetd and cron, but now I use launchd where I can.
Since then it has matured nicely to the point I would consider it a 1.0 product. It still has a few annoying limitations for sysadmin level folks, but overall is incredibly flexible and useful.
If you want to look at the codebase you can. Apple has always released it under the ASPL, and as of WWDC has turned it out as an active OSS project under the Apache 2 license at http://www.macosforge.org./ [www.macosforge.org]
Personally I thought TFA was pretty lame, the author shows misunderstandings of some very basic Mac OS X facts.
Re:Total crap (Score:3, Informative)
There are a lot of services that run as SYSTEM, but remember that Win32 doesn't have setuid binaries. Instead, NT uses privileged services accessible only on the local machine that listen for requests. Compare the entire list of setuid binaries plus daemons that run as root (and any dependent libs) on a UNIX to all the processes on NT that have the SYSTEM token (and any dependenent libs)-- these are the comprehensive lists of system trusted user mode binaries for the two platforms.
Re:Well written, but (Score:4, Informative)
On the other hand, you CANNOT get rid of Internet Explorer. And that's bad. IE is full of security holes and you can't get rid of it. Safari is far safer, and you can get rid of it.
Deleting Safari on a Mac is about as effective as deleting iexplore.exe on a Windows PC as far as getting rid of the browser is concerned. Sure, you've just nuked the front end, but the backend still exists in the OS and is not easily removed. Have you ever heard of Webkit?
Re:Windows Firewall????? (Score:1, Informative)
(Where the Windows firewall sucks is that any application can automatically override the firewall settings, though to be honest, with more and more routers using UPnP for firewall autoconfig, it's not that much worse
WebKit != Explorer (Score:4, Informative)
Re:Well written, but (Score:3, Informative)
Because some DLLs are loaded in context of other applications. For example hooks: global keyboard shortcuts, creation of processes, creation of windows. This requirement from from M$ itself - so inevitably all the crap is landing in %SysDir%. Also, dynamic linker on M$Windows look for DLLs exclusively by %PATH% - and %WinDir%/%SysDir% are always there.
Mac OS X uses concept of frameworks (which are set of libraries) and no such problem exists. The core OS frameworks go to one folder - applications keep their frameworks in bundle or install copy to analogue of Unix /usr/lib (have no Mac at hand - can't name the folders, sorry). The dynamic linker is made to properly resolve such run-time dependencies. Sort of just like on Unix with difference that Mac OS linker also looks into application bundle, while Unix one looks only in standard prescribed directories (/lib:/usr/lib:... - see /etc/ld.conf).
+100. Quote again just to reread. Well said.