July 02, 2006
Apple to help Microsoft with "security neutrality"?
Peter points to news that Apple are moving (back) to a proprietary OS. It's not entirely clear as yet, but it looks like the Intel Mac OSX will go proprietary.
Apple still publishes the source code for OS X's commands and utilities and laudably goes several extra miles by open sourcing internally developed technologies such as QuickTime Latest News about QuickTime Streaming Server and Bonjour zero-config networking.The source code required to build a customized OS X kernel, however, is gone. Apple says that the state of an OS X-compatible open source x86 Darwin kernel is "in flux."
The article waxes on about performance and tuning and the like, but I worry about security. The reason this blog's "Top Tip #1" for your security is to buy a Mac is not because I like them, but because they are relatively secure. Relative being the operative word here -- for best user-bang-for-buck, they are the way to go if security is your need.
The marketing people will likely waffle on about how they can be just as secure with a proprietary OS as without. "Honest Injun!"
Nonsense. Here's what happens. Once the public scrutiny goes, the internal food fights start. Once the OS team no longer has the easy excuse of "that's insecure and _someone will notice_," all of the application teams' marketing directors will be lining up to throw old eggs and rotten tomatoes at the OS team.
Going open source doesn't make it secure -- you've still got to do the hard work. It only makes it possible to go secure. And without it, it is unlikely that you can be secure in a complex, multi-application, mammoth user base scenario like Apple's, no matter how good your people are. Open source works like governance in security, it's the feedback mechanism that keeps you honest.
If Apple withdraws the committment to open, honest security, I'd give it five years, and they won't be able to open it again. They'll have caught up with Microsoft, the OS will be riddled inside with strange and scary artifacts, and that nice shiny apple will be skin, only, the worms having eaten the core away.
Still, one supposes that the other guys needs a "level playing field." Or perhaps we should call it "security neutrality" to use the current inanity. There's a thought -- Adam is going to work for Microsoft security. Wouldn't it be ironic if Microsoft were to announce an open source policy ... beyond the Chinese government that is ... and take another bite out of the apple?
the thing is mate ...
(period A) through 2003 (or whatever it is, I don't know or care) Apple had a proprietary closed OS; and Microsoft had a proprietary closed OS.
(period B) since 2003, Apple has an open OS (freeBSD isn't it?), and microsoft has a proprietary closed OS.
During those two periods:
(period A) Every single Windows machine on earth had compromised security; no macs had compromised security
(period B) Every single Windows machine on earth had compromised security; no macs had compromised security
the simple secret is, of course, that there AREN'T ANY MACS. For every one mac user (I know most of them!) there are 17.25 million PC users.
The one and only reason there is not an enormous flood of phishing, worm, etc, attacks on Macs, is that there are only a handful of macs out there, so no villains bothered.
mac has a marketing line: "We have Security, because we have BSD!" which is patently absurd.
(What explained the fact that there were no security attacks on Mac boxes BEFORE they had BSD? Of course, the explanation is that no villains give a shit about the one or two Macs per continent that are out there.)
It seems to me that if, suddenly, 99% of computers were Macs --- or, alternately, if suddenly Windows changed over to using BSD --- in that case the numerically huge computer would be overwhelmed with security attacks ... just as Microscoff is today.
If there was another operating system that was EVEN MORE OBSCURE than osx, I would change to it this afternoon.
(I wouldn't even know or consider whether than other operating system was open, closed, red, green, whatever. it's just a numbers game. Script kiddies bother developing worms, phishing kits etc only for the dominant OS, it appears !!)
some thoughts !
http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/About/chapter_1_section_5.html
from above:
Mac OS X is based on the Mach 3.0 microkernel, designed by Carnegie Mellon University, and later adapted to the Power Macintosh by Apple and the Open Software Foundation Research Institute (now part of Silicomp). This was known as osfmk, and was part of MkLinux (http://www.mklinux.org). Later, this and code from OSF’s commercial development efforts were incorporated into Darwin’s kernel. Throughout this evolutionary process, the Mach APIs used in Mac OS X diverged in many ways from the original CMU Mach 3 APIs.
... snip ...
NeXT had started with the MACH kernel proior to Mac OS.
Mach was one of the CMU projects, along with stuff like Andrew File System (a lot of which you see later in Open System Foundation/OSF), Andrew widgets, Camelot, etc.
IBM and DEC had jointly funded MIT's Project Athena to the tune of $25m each ... sort of from which came X-windows and stuff like Kerberos. Kerberos is now the basic authentication mechanism for a lot of things, including m'soft Windows. misc. past kerberos postings
http://www.garlic.com/~lynn/subpubkey.html#kerberos
IBM had funded CMU to the tune of $50m.
Part of the idea of microkernels is that they are usually much smaller and easier to maintain and support; KISS contributing significantly to consistancy, integrity and security.
One of the issues with traditional microkernels is that it can be hard to maintain KISS focus and discipline over span of decades.
This is one of the places that virtual machine hypervisors have sometimes played ... as a form of microkernel ... where it is easier to maintain focus on what feature/function is being provided by the microkernel ... helping control the feature creep, bugs, mistakes, etc that can occur in typical operating system development (especially when you are talking about periods spanning decades).
disclaimer ... i've been preaching advantages of KISS and microkernels since I started rewritting large amounts of virtual machine hypervisor code as an undergraduate back in the 60s ... and the vendor picking up the code and shipping it as part of standard product.
Posted by: Lynn Wheeler at July 2, 2006 11:29 AMre:
http://www.garlic.com/~lynn/aadsm24.htm#15 Apple to help Microsoft with "security neutrality"?
at conference last week ... mentioned in earlier thread
http://www.garlic.com/~lynn/aadsm24.htm#11 FC++3 - Advances in Financial Cryptography, Number Three
one of the vendors mentioned that they were moving SSL into the kernel ... in order to improve the performance (eliminating some number of buffer copies and other things).
followed was a discussion of microkernel philosiphy and trying to get everything out of the kernel than the bare minimum needed to provide things like authorized permissions.
Mark mentioned that this is a re-occuring theme for coyotos
http://www.coyotos.org/
where there has been ongoing attempts at trying to get the TCP/IP protocol stack out of the kernel (I think Mark mentioned that the current kernel, w/tcp/ip stack, is something like 230k lines of code).
This is sort of the evolution of capability operating system starting with GNOSIS, KeyKos, EROS, etc. a few recent posts on the subject:
http://www.garlic.com/~lynn/2006k.html#37 PDP-1
http://www.garlic.com/~lynn/2006m.html#34 PDP-1
There is a lot of confusion on this subject.
Since Darwin 7.6 (OS X version 10.3.6), long before the move to Intel, it has been impossible to completely recompile the kernel because Apple stopped supplying the source code of a few drivers. This includes header files required by a number of other drivers. Both PowerPC and Intel editions could be compiled from the same source code.
Apple's stated reason was that they had included new proprietary source code in the drivers. The real reason may have been that they stopped caring about keeping out proprietary source code because Darwin, as an independent open source project, attracted almost no attention and certainly very few kernel hackers.
The Intel edition of OS X has, from the start, been based on a separate branch of the source code, the one in which real development takes place. In a few cases, universal editions of drivers distributed with the Intel edition have more recent PowerPC binaries included than the actual PowerPC edition. However you can still compile Darwin -- with the exception of those drivers for which the source code is omitted -- from either branch, for both Intel and PowerPC editions.
Since Darwin 8.4 (OS X 10.4.4), Apple has been making the source code for the new "Intel" branch available, with the exception of all of the kernel code. You can still compile for Intel from the old "PowerPC" branch, but the resulting code won't be exactly the same as that found on Intel Macs.
Posted by: Felix at July 3, 2006 09:10 AM