OS X–Safer by design?

Today, my attention was directed at this blog, discussing the security of Apple’s OS X. I suggest you read it, as it makes a number of good points.

Some parts also remind me of the issues I brought up in this earlier blog, and some of the comments that followed. For example, there is the mention of Windows ACLs, which are a clear example of security-by-design, which OS X and most other *nix-based OSes lack (including linux).

Another thing is that he points out that exploits for OS X most certainly do exist. Just because the chance of getting infected on an OS X machine is much smaller than on a Windows machine, doesn’t mean that OS X is actually safer by design than Windows, or that Apple has a better security policy. On the contrary, in many areas, OS X is actually trailing behind Windows.

Lastly, he makes the point that I’ve also made in the past: an exploit doesn’t need admin/root rights in order to be effective. Eg, for a spambot, the exploit mainly needs to be able to send email. Most regular user accounts will have sufficient rights to send email, so you get the point. Just think about anything you normally do on your computer, under your own account. Perhaps you have compromising pictures stored on your computer, or sensitive personal information, such as your bank details etc.

Basically, everytime you hear someone talk about “safer by design”, referring to OS X or linux, you know that they have no idea what they’re talking about. These self-proclaimed experts just perpetuate this myth, without knowing the facts about security.

Advertisements
This entry was posted in Software development, Software news. Bookmark the permalink.

21 Responses to OS X–Safer by design?

  1. Jed Smith says:

    I read your comments there and here. I don’t particularly care about it, but I do want to point out that ACLs are a feature of a *filesystem*, not an operating system. You’re free to critique things but at least know your material beforehand — you can use Windows without ACLs (they’re specific to NTFS, in fact, and will not work on any filesystem that uses FAT), just like you can use OS X without ACLs by not using HFS+, and you can use Linux without ACLs by using a filesystem that doesn’t support them.

    The kernel doesn’t particularly care about the security model of a filesystem beyond a simple “yes/no” decision made by the filesystem. SELinux, AppArmor and other security enhancements take the security model even further. The mere presence of ACLs in NTFS is not indicative of Windows being any more secure than another operating system, and it’s an entirely flawed argument to believe so.

    It’s also a pointless argument, frankly, as the browser is the weakest vector these days.

    • Scali says:

      You are incorrect.
      See this page: http://msdn.microsoft.com/en-us/library/aa374872(v=vs.85).aspx
      As you can see, ACLs exist for any ‘securable object’.
      For a list of securable objects, click through: http://msdn.microsoft.com/en-us/library/aa379557(v=vs.85).aspx

      ACLs are NOT specific to NTFS. As you can see, various kernel-related objects, such as pipes, processes, threads, registry keys, synchronization objects etc also have ACLs. Based on that, I would say that the kernel DOES care about the security model.

      Really, the information is right there. Why didn’t you bother to check before trying to ‘correct’ me?

      • Jed Smith says:

        On UNIX, everything in that table is treated as a file for simplicity, so there is only one set of ACLs (not differing ones based on the object in question). A named pipe under most UNIX systems is a file, and filesystem ACLs apply to them.

        ACLs for files and directories on Windows are quite specific to NTFS. The other things like pipes and registry keys don’t have equivalents in a UNIX system because everything in UNIX is a file. There’s a slight apples-to-oranges comparison taking place here.

      • Scali says:

        Well, we aren’t talking about UNIX, are we? We were talking about ACLs, NTFS and Windows. Your claim that ACLs only exist in NTFS is simply wrong.
        Your claim that ACLs for files/directories are specific to NTFS is still wrong. Windows can support any filesystem that you are willing to write a driver for, and ACL support is part of that. In the case of a filesystem such as FAT, the filesystem itself does not have any concept of access rights, so a NULL ACL is used, which means ‘full access’ (like in most of the Windows API, when it comes to security descriptors). This however is a limitation of the filesystem, not of the OS.

        The *real* point you were trying to make is even more wrong: “The mere presence of ACLs in NTFS is not indicative of Windows being any more secure than another operating system, and it’s an entirely flawed argument to believe so.”
        Clearly Windows is more secure because it allows the fine-grained control of ACLs on all its kernel objects. This is something that most *nix-like OSes do not support, despite ‘everything being a file’. The problem is that in *nix-like OSes, ACLs are indeed an add-on to the filesystem, which means that if the kernel creates an object with a file-handle, it will not care about what kind of ACL it should create for it.

        Compare for example Windows’ CreateThread() with the POSIX pthread_create(). CreateThread() asks you to pass security attributes… pthread_create() does not. How can I get the correct security information into pthread_create(), when the entire API is not aware of any such security even existing?

  2. Jed Smith says:

    It’s a pretty significant leap from “POSIX threads don’t ask for an ACL at creation time” to “Windows is more secure because it does”. Let’s go item by item in the Windows kernel, and enumerate the rights that each object has — these, remember, are part of your claim that Windows is more secure because these ACLs are part of the core:

    http://msdn.microsoft.com/en-us/library/aa374902(v=vs.85).aspx

    1. Files or directories in an NTFS system — http://msdn.microsoft.com/en-us/library/aa364399(v=vs.85).aspx

    FILE_GENERIC_READ
    FILE_GENERIC_WRITE
    FILE_GENERIC_EXECUTE

    These are exactly equivalent to mode bits in POSIX, and the ACLs for specifying users appropriately are native to filesystems in common UNIX distributions. The user and group model of POSIX actually goes most of the way to accomplishing the cases that ACLs cover in this case. Windows is basically exposing +rwx here, just in a more creative way. For Windows, you’d put FILE_GENERIC_READ in your security attributes. Under POSIX, you chmod +r for the user or group in question. No difference whatsoever.

    2. Named pipe — http://msdn.microsoft.com/en-us/library/aa365600(v=vs.85).aspx

    FILE_GENERIC_READ
    FILE_GENERIC_WRITE
    FILE_GENERIC_EXECUTE
    SYNCHRONIZE

    Under POSIX, this is equivalent to a file. Under Windows, it apparently is too, because there is no extra functionality or security offered here. For Windows, you’d put FILE_GENERIC_READ in your security attributes — under POSIX, you’d chmod +r for the user or group in question. No difference whatsoever.

    3. Anonymous pipe — http://msdn.microsoft.com/en-us/library/aa365142(v=vs.85).aspx

    GENERIC_READ
    GENERIC_WRITE
    SYNCHRONIZE

    This is accomplished under POSIX the same exact way the Windows API handles it — there is a handle returned for reading, and a handle returned for writing. The ability to modify ACLs here is a little pointless, since anonymous pipes in themselves are not a globally-namespaced item.

    4. Console screen buffers — not supported

    Under POSIX, these are a file, and can have ACLs applied to them as well. In this respect, Windows does not offer functionality that UNIX systems have.

    5. Processes — http://msdn.microsoft.com/en-us/library/ms684880(v=vs.85).aspx
    6. Threads — http://msdn.microsoft.com/en-us/library/ms686769(v=vs.85).aspx

    All of these functionalities under POSIX are only permitted for a process’s/thread’s owner or the superuser. For Windows, you’d put TERMINATE_PROCESS in your security attributes; for POSIX, you’d signal and the kernel checks whether you are able to (by being UID 0 or by owning the process). What security is gained with this model over that of POSIX?

    I could go on for all of them. Each system does things in a different way, and using Windows’s more specific model as evidence of greater security is really misguided.

    • Scali says:

      It takes too long to cover each and every point… There is also no reason to, since you seem to misunderstand the Windows API. CreateFile/CreatePipe/CreateThread/CreateConsoleScreenBuffer (yes, console buffers DO exist in Windows)/etc… they ALL allow you to pass security information.

      In short, the point is that by specifying an ACL when creating a file/thread/whatever, you can create it with LESS rights than yourself. That is where the extra security should come from: you create an object with only the minimum rights required. Eg, if your thread or process is somehow exploited, it still does not have all the rights of the user owning the process.

      This is a standard feature designed into the Win32API as you can clearly see. The linux kernel however was not designed with such features, which is where add-ons such as POSIX ACL support, SELinux and AppArmor come in.

    • Sune Marcher says:

      Jed, one of the points of ACLs compared to traditional unix user/group is that it’s a fair amount more flexible (not just with the actual permissions, but also the specific users and groups) – and it would seem that even *u*x users agree, since there’s work on supporting ACLs for both Linux and BSD (they were rather limited last time I checked, though). And it’s not like this is some new and evil MS/Windows creation, the idea was adopted from VMS.

      The way security is implemented on NT also lets you *drop* rights, something that afaik isn’t possible with vanilla posix (but eventually the linux guys Saw That It Was Good(TM) and implemented special APIs for it…).

      You don’t just SET permissions on created objects, controlling which entities can access them, you can also specify the permissions you need when *opening* an object – so even if your process was exploited, you can mitigate how much damage can be done.

      It’s also baked into pretty much every part of the NT kernel, everywhere you deal with objects… there’s a LOT of APIs that take a SECURITY_ATTRIBUTES.

    • Scali says:

      And thank you for playing… Another self-proclaimed security expert with a severe bias towards linux, but not an actual clue as to how Windows even works. Really, I have NEVER encountered someone who wanted to argue that *nix is safer, and actually managed to hold himself in a technical discussion. You guys are all ignorant.

    • Scali says:

      In fact, what the heck were you thinking when you decided to reply here anyway?
      It is quite apparent that you know nothing of Windows. It looks like your only experience with ACLs is based on the *nix-world, where they indeed tack it onto the filesystem only, as an afterthought. Then you take your limited understanding of ACLs based on these limited add-ons for *nix, and try to generalize that for Windows’ security model and API.

      The idea in itself is quite illogical anyway. After all, if there was no merit to ACLs, why would these ACL extensions exist for the *nix-world anyway? Same for SELinux/AppArmor, these provide functionality that Windows NT has always provided out-of-the-box, via its use of ACLs/security attributes.

      Who the heck do you think you are, replying here, pretending to be an expert, and throw arrogant lines such as “You’re free to critique things but at least know your material beforehand” around? Take your own advice to heart. You need it, badly. I don’t.

    • mh says:

      You do realise that what you’ve just described is actually NOT Windows ACLs, don’t you?

      • Scali says:

        His deafening silence seems to be an indication that he was originally led here to start a discussion to feed his ego, rather than to feed his knowledge.

  3. mouse says:

    Re. ACL: the question is – how much security in the real world does it buy you? Why this capability didn’t seem to stop or affect all those well-publicized attacks against the big targets that presumably know better?

    • Scali says:

      That is a different subject altogether.
      The point that the article tries to make is that OS X may be ‘safer’ in the real world, in the sense that it doesn’t receive many successful attacks. *BUT*, this is NOT the result of OS X having the best security design of all OSes, or Apple having the best security policy. On the contrary.
      So it tries to debunk the myth that OS X (or linux for that matter) is ‘more secure by design’, simply based on attack statistics.

    • Sune Marcher says:

      That’s a very relevant question, mouse!

      As Scali already partially said, you can’t determine that from just the amount of published attacks on the system (market share and all that) you’ll have to look at the *type* of attacks. If somebody chooses to run from an account with administrator privileges(1), there’s not much you can do to save the person from himself (MS still tries, though – ASLR, DEP, et cetera).

      IMHO you have to look at *what* is being exploited (parts of the core OS, 3rd party programs, …?) and what *effect* it has. Crashing a process isn’t nearly as bad as remote root or local privilege escalation.

      (1): and I believe MS is very much to blame for this being the standard – prior to Win2k, it was perhaps excusable that the standard user account has administrator privileges, considering that OS wasn’t *directly* targeted at consumers… with XP, it’s unforgivable.

      • Scali says:

        I agree that XP Home is nasty since the underlying technology would support limited user accounts, but it was just ignored basically.
        But it was a big cultural shift… I’m not sure how much better of a job Microsoft could have done. Since Windows 9x didn’t enforce any kind of security, a lot of software just ignored it as well, and developers freely wrote to Program Files, system portions of the registry etc.

        Even years later, with Vista, there was still a lot of trouble with software being poorly written, and therefore only running as administrator. Imagine what it would be like on XP, without UAC and similar features to make things more ‘comfortable’.
        And what alternative was there, really? Continue to use Windows 9x? I’d rather have people using XP Home as administrator than 9x. It may not offer much more in terms of security, but at least it is robust.

        Luckily that is all in the past now, though. XP is ancient history, as is people running as administrator.

  4. Pingback: The kernel.org hack | Scali's blog

  5. Pingback: First kernel.org, now mysql.com hacked | Scali's blog

  6. Pingback: The myth of linux/open source security | Scali's OpenBlog™

  7. Zeta says:

    I realize this thread is over 3 years old, however I found it very interesting and would like to know whether I have a proper generalization of the issue. Basically what I take away from this is that in the Nix world permissions are handled by the file system such as ext4 or xfs and not in the kernel. Further any processes initiated by the user runs with the full rights of that user. In windows (NT) permissions are baked into the kernel, further it does not automatically follow that any process initiated by the user runs with the full permissions of said user, it could be less. Is this conceptualization correct?

    • Scali says:

      Well, the filesystem is part of the kernel (either literally, or as a kernel module). But the thing is that the filesystem is the only place where these rights are applied. UNIX has the ‘everything is a file’-philosophy (so you have device ‘files’ like /dev/eth0 etc, and process ‘files’ in /proc etc).
      Problem is, not everything is a file, and not everything is designed in a way that you can control the rights with which an object is created or accessed.

      Windows is different. You have ‘security attributes’ which can be passed to many functions in the Windows API, allowing you to control the rights with which eg a new process is created, or a socket/file/etc is created/opened etc.
      And yes, by default the security attributes will be inherited from the default rights of the current user. But you can optionally pass different rights (which can only be less than that of the user).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s