Suns Solaris Takes Security Mainstream

The upcoming release of Solaris 10 is the latest sign that crucial security features are making their way to mass-market platforms.

A little less than a year ago, I remarked in this space that seat belts werent always standard equipment in cars but that we expect them today as a basic safety feature. Its nice to be able to note that the same sort of transition is finally gaining momentum in mainstream IT, with crucial platform security and reliability features expanding beyond formerly specialized domains to merge into mass-market platforms.

Case in point is the promised release of Suns Solaris 10 operating system before the end of this year. I spoke last week with Sun VP and CTO for Software John Fowler, who appeared at the Sun Software Summit event that Jason Brooks and I attended.

/zimages/5/28571.gifFor eWEEK Senior Analyst Jason Brooks take on the Sun Software Summit, click here.

When Fowler said role-based privileges were central to the security vision at Sun, I asked if that meant future versions of Suns platform would eliminate the notorious single point of failure on Unix systems sometimes called "the God user"—that is, the "root" account, with its total control of and access to all the systems resources.

Fowler immediately confirmed that Solaris 10 does not, by default, define a root user. "We no longer believe in God," Fowler said, in response to my use of that word, then hastily corrected himself as a ripple of laughter greeted that reply. Theological issues aside, he clarified his message as, "We no longer believe in root."

Fowler and other Sun officials with whom I met last week made it clear this is just one symptom of the convergence of the mainstream Solaris product and the Trusted Solaris product thats been sold for more than a decade to security-conscious users.

Trusted systems are defined by their selective granting of granular privileges for use of specific resources. Ive always found the "trusted" label a little odd for systems that seem better labeled "mistrustful"; the origin, I suspect, is in the difference between a truly compartmentalized system and one that must operate in the mode called "system high," with all personnel cleared for access to the highest level of information that is processed, stored or transmitted by that system. When the system is trusted to enforce compartmentalization, all users need not be held to such a high standard.

The trusted-systems approach has a good reputation here at eWEEK, where the third of our international OpenHack security challenges—played out a little more than three years ago—employed kernel-level file and network access controls to become the first such exercise in which no attacker succeeded in cracking the system.

Significantly, several OpenHack III attackers did exploit application-level vulnerabilities to gain administrative access, but the trusted-system platform used for that exercise did not grant divine rights. Attackers were therefore unable to use their admin powers to gain access to the "crown jewel" information assets that we defined as the prizewinning targets.

Fowler observed in his remarks last week that selective privileges of this kind are quickly becoming not merely good practice but also mandatory elements of enterprise IT system design: "Look at Sarbanes-Oxley and HIPAA," he said. "You cannot have systems administrators gain access to data. Thats a little bit foreign to people."

Many PC users know just what Fowler means. I routinely try to install applications on Windows 2000 machines using only the privileges available to a Power User rather than an Administrator, and many of these attempts fail despite platform features designed to make this possible. Many enterprise applications on several platforms invoke elevated privileges to write to system directories or registry keys, which opens doors to attackers if that access can be successfully misused.

But, as I said, things are getting better. Apples Macintosh OS X, like the forthcoming Solaris 10, has no root user in its default configuration. Microsofts .Net Framework offers mechanisms for application developers to be much more explicit and precise about the privileges their applications should, and should not, enjoy.

Developers are learning to allow whats necessary rather than trying to enumerate whats forbidden. And IT buyers are learning to look for seat belts as standard equipment.

Technology Editor Peter Coffee can be reached at

/zimages/5/28571.gifCheck out eWEEK.coms Security Center at for security news, views and analysis.
Be sure to add our security news feed to your RSS newsreader or My Yahoo page: