The Second System

John Martellaro's nightmare.

Get It Try It

John Martellaro's recent article at TMO is full of good intentions. John wants to help mainstream Unix gurus get up to speed with Apple's off-centre version of Unix.

Unfortunately John, a notorious reseller of the Apple Kool-Aid™, spikes his article with claims and flames revolving around the rather daring idea that Apple's 'Unix' is somehow 'better' than the others.

This stance is not only wobbly but will almost certainly serve to frighten potential switchers away instead.

For someone who's been a system engineer for a long time such statements as John is guilty of might seem shocking. But John is no system engineer. His credits describe him as a 'senior scientist', whatever that is, and go on to mention he worked in the marketing department at Apple for five years.

Which explains two things for us simultaneously.

Same is Good

In the world of today's operating systems it's not good to have a proprietary OS kernel. Linus Torvalds more or less proved that. Linux has been to the planet Mars; it's unlikely Apple's Darwin will make it.

Moreover: Linux is a kernel and no more. It fits with Apache, Apache Stronghold, GNOME, KDE, and other major modules. In fact it's Apache on Linux that runs the TMO site John works with.

John admits the 'pros' prefer stability and continuity but doesn't see how this should apply to what he calls the 'casual consumers' as well.

The OS kernel of today should be a commodity. It must be a commodity. Long gone is the day of the Beige Box where access to a computer was through the door to the room where it was located. Plug in the cords on a computer of today and the whole world has access to it.

Under such circumstances it's imperative that the OS kernel be a commodity. This is the only way this all-important code can be properly vetted and thus guard the user against the onslaught of black hat exploits.

That Microsoft's OS kernel is not a commodity but closed source chaotic confusion is well known. It's also well known Microsoft's OS is beyond repair and that company's days as an OS vendor are numbered. Microsoft could have taken the open source commodity path as all the rest but chose not to out of pure greed and megalomania; today they're paying the price.

Apple's kernel isn't commodity either. Apple make a lot out of how they use the 'rock solid foundation' of FreeBSD Unix and there are certainly hundreds of thousands of similarities but Apple's Darwin and FreeBSD are not the same. Tragically so.

From the get-go Apple have taken the incomparable model of NeXT and ruined it for at the very best ludicrous purposes. Each time the FreeBSD group revamp their code, eliminating further potential threats, Apple must of needs today take this code and work slowly through it, perhaps line by line for millions of lines, to see where they in the past chose to diverge and to see how they're going to have to rewrite their own code to match FreeBSD's new code. It's time consuming - it's time wasting - and it's done at an agonisingly and dangerously slow pace. And this gives the black hats the rather ample window of opportunity they need.

A Hacker Reference Manual on Every Apple Hard Drive

As former NSA ace hacker Charlie Miller has pointed out and dramatically demonstrated on at least two occasions, hacking Apple's OS is child's play. You simply enumerate all the open source modules Apple are using - and here Apple serve up the details on a silver platter in the form of the file Acknowledgements.rtf found on every Apple computer - then compare the versions of Apple's older modules with the up to date ones provided by the open source suppliers. As Apple are notoriously behind schedule all the time there will always be a great number of modules dangerously behind the rest of the industry.

Then you check the changelogs for these modules and see if any potential security holes were discovered and fixed. And as soon as you find such a security hole you begin your attack.

Charlie Miller attacked Apple twice - methodically and mercilessly. And he was successful both times. With - it should be pointed out - the greatest of ease.

The whole point of open source is that dedicated groups extensively skilled in a single facet of computer software should be responsible for a very finite number of modules. At the same time the code is open to public scrutiny and outsiders can at any time alert the core group to fallacies, logical bombs, and outright security holes.

Apple are secretive, refuse to work with others, and always have to do things their way. The same way they've always done things - despite John Martellaro's contention they like to be 'different'. Apple won't be a part of the open source movement and consequently they're going to suffer.

Apple can do what they want with their user interface. Considering they have the NeXTSTEP classes at their disposal one can only hope they do. And no one is going to demand they open up the code to these classes to public scrutiny. A properly implemented GUI API working atop a commodity OS kernel need never be a security issue. In the real world where commodity OS kernels are considered mandatory there is no way code above the level of the kernel can dig down past the kernel to circumvent OS security. The kernel remains the only API user land code can access. If you can't do it through the user land APIs then you can't do it. Period.

This puts security - all-important security - in the right place. The purveyors of the kernel - such as Linus or the FreeBSD group - are responsible for maintaining and improving the security of the kernels - and thereby all computers that are using them. Security considerations are kept in one place. There is but one cook and the broth cannot be spoilt.

Anything built atop that must of needs obey the laws of the kernel. As long as the kernel is kept secure all research and security probes are limited to a study of the kernel. And the simpler the kernel the better it gets, the more stable systems as a whole become.

The Second System

But Apple don't even have one kernel. They have two. They use both their own version of FreeBSD and also a toxic blend of age old Beige Box APIs, many of which are downright dangerous. Developers need not obey the laws of Unix or even Apple's Darwin kernel - they can access Carbon APIs that push right past both.

An illustrative example: file time stamps. Unix allows for three time stamps for all file system items whereof two are programmatically modifiable. The three time stamps represent the 'last' time the item's inode was changed, the item itself was modified, and the item was accessed. For security reasons the Unix kernel only allows programmatic modification of the accessed and modified times (so called atime and mtime).

But Apple refused to play along. It wasn't a matter of Apple divining an improvement to Unix as John Martellaro would have you believe - it was a matter of Apple doing exactly what John Martellaro claims to despise: the same thing over and over again.

Instead of accommodating their adoption of NeXTSTEP full out Apple kept their abhorrent file system HFS which has not three but a total of five time stamps.

There are numerous further examples of the same type of 'hanky panky' being possible in Apple's 'kernels'. These invariably represent unvetted 'Apple' ideas that almost right as rain get users into trouble. To name but a few:

But the nightmare can't be said to end there for as long as you have two separate paths to the hardware - two kernels and a second system - you have a security nightmare. It's a pointless and a thankless task but essentially you have to crosscheck all the code in both systems to make sure they behave the same way. Which leads to the following.

When a Unix guru - commonly with much more professional experience than ever found in the world of Apple - confronts an Apple system for the first time the reaction is not necessarily or solely based on things being different. These 'professionals' by their very nature are capable of learning things in a way your two-bit Apple 'admin' won't ever be capable of.

What really disconcerts them instead is the immediate realisation that they're looking at a security nightmare.

 - 'Mac Skywatcher'