Solaris vs. Linux: Framework for the Comparison

by Dr Nikolai Bezroukov

Security issues

In a large corporate environment incompetent people implementing security solutions are a bigger problem that most OS security weaknesses Softpanorama Third Law of Computer Security

"We have more to fear from the bungling of the incompetent than from the machinations of the wicked." from Slashdot

Due to "increasing Unix diversity" effect as well as the status of Linux as the lest secure and the most popular flavour of Unix (Microsoft of Unix) Introduction of linux in enterprise environment tends indirectly increase costs of IT security including but not limited to additional security software acquisition costs,  patching costs (see above), manpower costs and, potentially, additional security services necessary. The latter might be the most significant factor and is often overlooked in TCO comparisons.

But it is especially important in today "semi-outsourced" IT environments is the level of competence and level of loyalty of the people who are responsible for selecting and implementing security solutions. Those are much bigger factor then any factor that can be attributed to a particular OS. For example low loyalty of technical personnel naturally leads to increased probability of signing useless or harmful for the enterprise contracts: and security represents new Eldorado for snake oil sellers. A good recent example was market success of ISS intrusion detection appliances.

Therefore sometimes the side affect of adding yet another distribution can include additional $200K per year contract from some new (and supposedly necessary in new enlarged environment) provider of services like managed firewalls and IDS :-).  IBM loves selling security solutions to weakened by outsourcing IT of large corporations.

Moreover, security like love is a very loaded word.  See brief discussion of security issues in  Part 4: Comparison of internal architecture and key subsystems as well as my older whitepaper  [Bezroukov2005b]. Generally there is approximately  a dozen of  key dimensions in which linux and Solaris should be compared in security space that can be grouped into two large areas:

• Security of the OS itself. In case of Solaris and linux both are descendants of the same OS and share major architectural and security weaknesses of Unix. We will not discuss the issues connected with architectural weakness of Unix and concentrate of those dimensions of this metric that differ among two OSes:

  • Uniformity

  • Commonality

  • Availability of signed executables framework
     

• Universal mechanisms which increase the security of applications (and possibly OS itself). Among the dimensions of this metric we can mention:

  • Protection from buffer overflows.

  • Integrity checking mechanisms.

  • Virtualization. Solaris zones have a great security enhancing value. Xen is also useful but so slightly lesser degree.

  • Log aggregation and alerts extraction.

  • Role based access control.

  • Built in firewalls (that inccludes underutilised but very elegant TCP wrappers)

  • ACL and BSD-style file attributes support.

  • Know-how availability.

Security of the OS itself

We will distinguish two major factors here:

1. Uniformity. The major problem here is multiple personalities of linux. Sun is a single vendor of Solaris, and Solaris exists as a single OS with optional open source components that you can install or can ignore. All security mechanism are universally available.
   
   At the same time commercial linux consists of forked Linux kernel plus partially idiosyncratic environment peddled by a particular linux vendor, created by multiple loosely coordinated groups.  That creates many subtle differences in security space (for example, please compare SELinux and AppAmor: they are very different indeed with AppAmor being tremendously more user-friendly, but I doubt that any sysadmin is salivating about the necessity to learn both, even with company paid training: humans still have only one head). 
   
   Solaris is a single entity that encompass both kernel and environment. It has a powerful and transparent security framework based on RBAC and zones, one of the most underestimated technologies in security space. Both RBAC and zones are technologies that can really be implemented in large enterprise environment and stay useful after the implementation (often the most net benefits for the implementation of a security product are limited to the preparation phase which often entails really necessary and long overdue changes in infrastructure and procedures; after this phase all efforts including actual product deployment become counterproductive).
    

   Solaris RBAC and Zones is one of the most underestimated and underutilized security framework suitable for large corporate environment

   All Solaris utilities are RBAC-aware, can work with extended attributes and like. For linux this is a major problem as utilities (for example bash) are developed completely separately from the kernel, so if any distributor wants to implement something like RBAC he needs to do major work in kernel space. 
    

2. Commonality. Common, popular OSes are the most favorite target of attacks ("Microsoft effect"). Linux status in Unix space is pretty much similar to status of Windows in general OS space: this is the most hacked flavor of Unix.  Period.

   Also usage of GCC compiler and precompiled kernels are major disadvantages from the point of view of security as this greatly simplifies exploiting buffer overflows. Some Linux distributions like Gentoo are free from this limitation; also some recent work in GCC provides  randomization of generated code that can help to prevent such attacks.
    

3. Availability of signed executables framework. Unlike Windows, neither linux nor Solaris currently have such a framework in enterprise versions. There are patches that can emulate Windows-like sighing framework in linux using GPG. For additional  information see Industrial-strength Linux lockdown, Part 2: Executing only signed binaries In this case you first ensure that all approved scripts and applications are signed, and then build a kernel that executes only those applications.

Universal mechanisms which increase the security of applications (and possibly OS itself)

Here will consider the following factors:

1. Protection from buffer overflows. Operating system vendors have been regularly providing security fixes for their products but that does not mean that users are installing them. As the Code Red epidemics as well as subsequent once a year other network worm epidemics that rock Microsoft world has shown this is simply not the case and there is always critical mass of "unpatched" users despite such drastic measures as automatic updates installation. As for CodeRed,  Microsoft provided a security fix that prevented this worm from infecting Windows months before it was unleashed.  That's why hardware protection from buffer overflow has tremendous value for enterprise customers.

   NX bit that allows control access to memory with 4K granularity is not a new thing, and both Intel or AMD were very late in implementing it.. Mainframes, SPARC's, UltraSPARC's and Alpha's have had this for some time; Power CPUs probably have it for a long time as well. See Slashdot Red Hat Introduces NX Software Support For Linux for the discussion of this feature.

   On Solaris Sparc this feature is available probably from 1996 or earlier (Solaris 2.6 ???). On Solaris 10 NX protection is automatically enabled by default on all x86 processors that support this feature. 

   Situation with RHEL4-64 is less clear ( see [PDF] An Overview of the Red Hat Enterprise Linux 4 Product Family). In some sources I read that it is provided for SMP and large memory kernels (see for example Bug 123656 NX bit interferes with Java JRE 1.4.2, as well as redhat.com Knowledgebase); in other that it is supported only for the AS distribution. It looks like Suse64 provides support for NX bit for all 64-bit kernels starting from version 9.1. This is a definite advantage of Suse.

   Generally Linux kernels supports NX bit from August 2004, before the release of Solaris 10, but actual support has been very non-uniform between various distributions. Some application crash if NX bit is enabled. Here is more or less objective information about the NX-bit support [Wikipedia]:

   Linux kernel currently supports standard hardware NX on CPUs that support it, such as the current 64-bit CPUs of AMD, Intel, Transmeta and VIA.

   The support for this feature in the 64-bit mode on x86_64 CPUs was added in 2004 by Andi Kleen, and later the same year, Ingo Molnar added support for the NX bit in 32-bit mode on 64-bit CPUs. These features have been in the stable Linux kernel since release 2.6.8 in August 2004.

   The availability of the NX bit on 32-bit x86 kernels, which may run on both 32-bit x86 CPUs and 64-bit x86 compatible CPUs, is significant because a 32-bit x86 kernel would not normally expect the NX bit that an AMD64 or IA-64 supplies; the NX enabler patch assures that these kernels will attempt to use the NX bit if present.

   Some desktop Linux distributions such as Fedora Core 6, Ubuntu and OpenSuSE do not enable the HIGHMEM64 option, which is required to gain access to the NX bit in 32-bit mode, in their default kernel; this is because the PAE mode that is required to use the NX bit causes pre-Pentium Pro (including Pentium MMX) and 400MHz bus Pentium M processors (which does not support the NX bit or PAE) to fail to boot. Fedora Core 6 does provide a kernel-PAE package which supports PAE and NX though.

   RHEL4 also has some complier level protection mechanism against buffer overflow which but they are not universally deployed [ redhat.com Limiting buffer overflows with ExecShield]:

   In Fedora Core 3 and Red Hat Enterprise Linux 4, gcc and glibc gained a feature called "FORTIFY_SOURCE" that will detect and prevent a subset of the buffer overflows before they can do damage. While this feature is present in these two releases, it's not used for significant portions of the Fedora Core 3 and Red Hat Enterprise Linux 4 distributions itself. This is different for Fedora Core 4; here almost the entire distribution is compiled with this feature enabled.

2. Integrity checking mechanisms. There is probably parity in this area as neither Solaris not linux have cryptographic protection and on the fly integrity checking of executables by loader that Microsoft has. For a long time Solaris has so called Fingerprint Database (sfpDB, see Sun Blueprints article), a centralized vendor supported database tool that enables users to verify the integrity of any file distributed with the Solaris OS. Recently Red Hat tried to re-implement this concept so at least this distribution will be on par with Solaris in his important area. On the other hand RPM for a long time has built-in integrity checking that can be used as a proxy for central database.
   
   Unlike Microsoft neither linux nor Solaris currently have such a signed executables framework in enterprise versions. There are experimental patches that can emulate such a framework in linux using GPG. For additional  information see Industrial-strength Linux lockdown, Part 2: Executing only signed binaries In this case you first ensure that all approved scripts and applications are signed, and then build a kernel that executes only those applications.
    

3. Virtualization. Virtualization is very important for both security and server aggregation. But there are several distinct types  virtualization with each providing its own unique advantages (and disadvatanages). We will discuss them later.
   
   Solaris 10 has built in light-weight virtualization capabilities called zones, which have great security enhancing value and can help to improve applications stability the holy grail of large enterprise IT.  Neither Suse 9 nor RHEL 4 currently have any comparable light weight virtualization capabilities. FreeBSD is the only OS that can compete with Solaris in this respect (actually jails were inspiration for Solaris zones, but Solaris 10 zone generalized and enhanced the concept to the level almost beyond recognition :-).
   
   What is commonly called virtualization in main-steam IT press should be more properly called heavy-weight virtualization and currently VMware is the most popular solution in this area in Intel space (on RISC IBM AIX 5.3 LPARs are king of the hill and it remains the most stable and tested large enterprize heavy weight virtualization solution).  Suse 10 was the first enterprize linux distribution which introduced Xen 3.x. The latter takes full advantage of Intel and AMD hardware support for virtualization available in newer 64-bit CPUs, delivering capability of bare-metal virtualization: with Xen 3.x integrated into the OS VMware is no longer necessary and that means huge cost saving in deploying this solution in large enterprize environment.

   Still it is important to understand that Solaris 10 supports a different type of virtualization then Xen and this light-weight virtualization provides 80% benefit of heavy-weight virtualization without noticeable "virtualization drag" inherent in heavy-weight virtualization solutions. That means that the advantage of having light-weight virtualization capabilities will not disappear even after full integration of Xen in other enterprise linux distributions (RHEL 5 was released with Xen 3.x support in early 2007). Moreover Solaris 10 users have advantage in the access to light weight virtualization from day one and the most advanced IT organizations among those which are using Solaris already have build competitive advantage both in security and availability of applications in comparison with other types of virtualization solutions. As zones are perfectly well integrated with RBAC, Solaris 10 represents a really unique platform, the only one that really solves an important large enterprize problem: "root password hell". The essence of this problem is that applications owner usually have enough clout to request and get root access to the production instance of the server. This creates a complex and ripe with conflict situation of two cooks sharing the same kitchen. With zones Unix group can provide root password to zones instead of providing root password to the server and that really improves both security of environment and relations between Unix group and application owners.  I would never say that this is easy to do but theoretically such possibility exists.
   
   Another important advantage is that if applications are installed in zones they can be configured to behave in "mini-cluster" styles. For example the central zone can control very complex aspects of the behavior of satellite zones and detect situation when application runs into trouble. In case instances are redundant the central zone can exclude troubled zone from the pool and then reboot the zone. In case the redundancy is not complete switch to the secondary zone might work or some other unique for the application in question solution can be developed that take into advantage relative ease and speed with which zones can be created and destroyed.  Websphere already supports such deployment[WebSphere6.0.2 release notes]. Since Solaris 10 11/06 update zones also can be dynamically cloned and migrated from one server to another in the same fashion as VMware virtual OS instances [Jeff Victor's Blog].  That also can improves availability.

   Sun also working on incorporating Xen in Solaris but in this area Suse 10 customers have a competitive advantage for all 2006 and probably 2007.  Actually the lag might be slightly bigger as one year delay in adopting new features is a common sense measure the large enterprises use (in Windows environment this behavior often is called "waiting for service pack 1" ); there are very few "beta-addicts" among surviving large enterprise IT managers: the cost of mistake is usually the loss of job.
   
   We will discuss this issue in more details later
    

4. Log aggregation and alerts extraction. Both Solaris and Red Hat include outdated syslogd daemon. Suse uses syslog-ng which is generally a better daemon and that means that Suse have substantial advantage over both Red Hat and Solaris in this area. Red Hat has upper hand in logs analysis tools as it includes a simple but very useful Perl script (logwatch) for analyzing logs. It is installed by default. Paradoxically Suse dropped the ball here and as of mid 2006 does not include this package. Still this weakness can be easily compensated in both Solaris and Suse by adapting the same script, which is not too Unix-flavors dependent and has an advantage of being written in a scripting language (Perl).   Suse 10 also supports mon, a lightweight monitoring package written in Perl that can monitor various daemons on the server and provide alerts to syslog. Also included in the distribution in Nagios, more heavy monitoring package written in C that has a Web front end (console).
    

5. Role based access control. Solaris provides the most technically elegant solution.  Red Hat is limited to SELinux functionality which looks like an overkill for non-military organizations and is incompatible with AppAmor solution used in Suse. Moreover SELinux looks inferior and too over-engineered in comparison to Solaris 10 RBAC capabilities.  Overcomplexity in SELinux backfire and the most common situation is RHEL installation with SELinux disabled. In this sense it is pseudo security solution. The performance overhead for Solaris solutions is significantly lower than that of SELinux ( 7-16%).  This is another reason why SELinux is disabled so often.  Novell AppArmor is more large enterprise friendly framework and should be seriously considered as an alternative is SELinux needs to be enabled in the environment.
   
   Red Hat understands the scope of the problem and probably has pretty damning internal statistics about amount of RHEL installations with SELinux disabled at the marketplace (they collect quote a lot of configuration information from the registered servers), so they tried hard to make it more manageable in RHEL 5. But we are talking about RHEL 4, here the train already left the station.
   
   BTW disabling SELinux became a standard, almost recommended, step in debugging RHEL network connectivity problems so this is only one step from using it as a temporary measure to leaving it disabled and this step is easily done by most (probably 80%) of  linux administrators :-). Using security labels like "Secret", "Confidential", etc are appropriate to very few organizations outside military and selected three letter agencies. Novell AppAmor is a better technology and Novell is a more experienced operating system developer then Red Hat, but it is different from RHEL solution which creates problem due to lower SUSE market share and still it cannot match Solaris 10 RBAC +Solaris Privileges+Zones security troika.

   Solaris Zones can greatly complement RBAC implementation by ensuring real separation of duties. Solaris zones essentially allows application owner to control it own lightweight virtual machine and as such greatly reduce conflicts in access control in Unix environment. The problem of "too much privileges for application owners" which is essentially irresolvable in ordinary Unix environment no matter how many documents are produced or meeting conducted can be finally at least partially addressed in a way that minimally hurt (and even can in a way benefit) all parties involved.  It is a really innovative solution that that's why Solaris 10 can be called the first XXI century Unix.
    

6. Built in firewalls. Red Hat is superior to Solaris in this respect despite the fact that networking-wise IPFilter is technically superior to IPTables and is more robust under high loads.  IPTables firewall is better integrated into RHEL, enabled by default and Red Hat training materials reflect this integration. For example all exercises in RHS333 presuppose active firewall and the necessity to open or close certain ports when installing a particular network daemon (although this is still highly inconvenient and something about it probably can be done in the RPM package).  Solaris 10 does contain an IPFilter implementation but it is an installation option. Current Solaris 10 training materials do not reflect configurations with firewall enabled  and that for each new demon you need to correct rules. Previous versions of Solaris used different firewall (SunScreen, which has richer set of proxies but is less reliable) and it is still available. IPFilter that are used in Solaris 10 came from BSD: they were one of the first fully integrated firewalls in OpenBSD until due to licensing conflict they were replaced by pf. They still are widely used in FreeBSD. That creates a certain advantage and synergy for Solaris users, advantage that linux does not have: for both OpenBSD and FreeBSD a lot of materials how to configure firewall exists and sophisticated rulesets were published. such material now can be reused in Solaris environment, avoiding reinventing the wheel.  For example there is a possibility to rewrite the source address of the reply so that blocked ports were not classified as filtered by nmap. According to Stevens TCP closed ports should reply a TCP RST packet and  UDP closed ports will reply an "ICMP Port Unreachable" message.
   
   Static packet filtering is perhaps the simplest mechanism for network access control, but also deceptively hard to implement correctly. Both IPFilter and IP tables support stateful filtering, called "stateful inspection" by Checkpoint Firewall-1 (FW1), and NAT. But as for interface IPFilter is a rather old firewall implementation and have rather convoluted rules structure that users of Checkpoint Firewall 1 (typical firewall in large corporate environment) have difficulties to adapt to. However, during these years, IPFilter became a de facto firewall standard for the segment of users which didn't have money or didn't want to pay for the very high price of CheckPoint's firewalling products.  Internals-wise it's pretty competitive product.
   
   While I'm no expert on packet filtering I still feel that rules semantic of IPTables are closer to Firewall-1. Generally Firewall-1 and IPTables are rather similar in their packet filtering technology. Both  Firewall-1 and IPTables are "first match" firewall. When "first match" firewall receives a packet, it compares it against the first rule, then the second, then the third, etc.  When it finds a rule that matches, it stops checking and applies that rule.  If the packet does not find any matching rule it's denied. It is important to understand that in the "first match" firewalls rule that matches is applied to the packet, not the rule that best matches.
   
   By default, IPFilter (and also ph that replaced it in OpenBSD) is last match firewall. You can short circuit this logic by using the quick keyword. This restores the "first match" logic that I prefer. The "last match" method seems both backwards and harder to maintain. There are also good GUIs that can be used with both IPTables and IPFilter, for example Firewall Builder. Using GUI can "ease your pain" with IPFilter.  I do not recommend maintaining IPFilter from the command line: it has one of the most dysfunctional command line interface I encountered.
   
   That suggests that for a typical corporate Unix administrator IPTables might be easier to configure and manage then IPFilter while due to its long history of development IPFilter is more mature product.  Due to additional complexity IPFilter might also be significantly more resource intensive then IPTables, especially with large rules sets. But FreeBSD boxes with IPFilter easily sustain 100Mbps traffic. It's unclear how it behaves on gigabit traffic. Other things equal firewall more closely integrated with the kernel beats generic firewall on load intensive tests.  See Design and Performance of the OpenBSD Stateful Packet Filter (pf) for additional details. There are efforts to implement packet filtering for Solaris using an interface similar to Linux. See Darren Reed's, the principal developer of IPFilter, paper Packet Filtering Hooks design document 9-3-2006  for details.
    

7. ACL and BSD-style attibutes support.  Solaris looks better then linux in this area.  ACLs are fully integrated into the system for more then a decade  (since at least Solaris 2.5 which was released in October 1995). They are supported by all relevant utilities and are eminently usable. This is definitely not a beta-code level implementation. 
   
   Solaris does not linux support BSD style attributes like immutable, while linux supports them incorrectly.
    

8. Know-how availability. Linux is superior to Solaris as for security know-how availability, especially on application level where the most threats reside. In addition to various third party books and papers Red Hat has rudimentary Security Guide for Red Hat Enterprise Linux 4

A useful overview of Red Hat security issues can be found at redhat.com Risk report A year of Red Hat Enterprise Linux 4

Protection from buffer overflows

While it is difficult, or even impossible to discuss OS security separate from hardening and qualification of personnel (see Softpanorama laws of hardening). Still there are some architectural issues that transcend hardening. One of such things is built-in stack overflow protection.  It look like both Linux and Solaris support it on CPUs that have NX bit. For example as Solaris X86 FAQ states

(6.43) Is noexec_user_stack supported in Solaris x86?

Yes, but only for AMD64 (Operon) on Solaris 10 or higher. For 32 bit x86, you can set it but it won't do anything. On SPARC and AMD64, it prevents execution of code that was placed on the stack. This is a popular technique used to gain unauthorized root access to systems, locally or remotely, by executing arbitrary code as root. This is possible with poorly-written programs that have missing overflow checks. To enable stack protection, add the following to /etc/system
set noexec_user_stack = 1
set noexec_user_stack_log = 1
and reboot with /usr/sbin/init 6

With Solaris 10 release it is clear that Solaris security is superior and architecturally is reached more advanced stage,  especially in RBAC area and light-weight VM area (zones),  than Linux security. I would say that Solaris 10 RBAC implementation and zones make it the first XXI century Unix. Red Hat implementation of SELinux in version 4 of Red Hat Enterprise makes it more competitive with Solaris then Suse, but still this is a less mature implementation and more questionable architecture then Solaris RBAC (not every algorithm that NSA produces reaches the quality of DES).  RBAC was first  distributed with Solaris 8 that was released in 2000. Also SELinux looks overengeeneered and completely administrator hostile: label-based security enforced by SELinux is a huge overkill for non-military installations.  That's why SUSE has a huge edge over Red Hat in this area, but this edge was achieved by breaking compatibility with Red Hat and adopting a different simpler and more efficient approach (AppArmor)

To ensure working of complex applications is more difficult under SELinux then RBAC and that probably means that in reality SELinux will be eventually switched off in many enterprise installations.

Due to availability of RBAC Solaris probably can compete in security even with OpenBSD despite being substantially larger, more complex OS as well as OS were security was not the primary design goal.  OpenBSD like Solaris 10 has a role-based system call access manager.  Like Solaris 10 RBAC, the OpenBSD systrace policies define which users and programs can access which files and devices in a manner completely independent of UNIX permissions. This approach can help to diminishes risks associated with poorly written or exploitable applications. While defining such policies is not a simple task either in Solaris or OpenBSD, OpenBSD has an advantage because systrace has been around for a long time and there are online repositories with systrace sample policies (see for example Project Hairy Eyeball). Also, systrace includes a policy-generation tool listing every system call available to the application for which the policy is being generated. Although an experienced system administrator could probably still tighten the security of the system by refining the default policy generated by the tool, the defaults are often secure enough for most uses.  AppArmore has a very similar appeal.

At the same time Red Hat Enterprise version 4 has better level integration with firewall and better kerberization of major daemons. I do not like the interface provides by new Solaris firewall ( IP filter ) as well as semantic of operations.  It might the best open source firewall but still I would prefer something really well integrated into kernel not add-on package. Red Hat interface is simpler and more corresponds to firewall 1 which is a standard de-facto in this area. By default firewall is enabled and provides substantial additional level of protection. Also by default neither telnet not ftp are available, which is a good (although minor) thing.  So in applications area out-of the box Red Hat looks slightly better then Solaris: it has better integration of ssh, more secure default Apache installation and many other minor but important things (for example root has its own separate directory /root). So in applications area Red Hat generally wins over Solaris due to following reasons:

• Better documentation about securing applications (and better course: 2006 version of RSH333 beats outdated Solaris SC-300 course)

• Better and more thoughtful defaults

• Somewhat better kerberization of major daemons. 

This better application security is very important because people who install OSes in enterprise environment often do not understand the details of applications, and applications "owners" are often completely clueless about security. 

Therefore we have slightly fuzzy situation here: on kernel and filesystems level Solaris is definitly  more secure than Red Hat 4 Enterprise 4, but on application level the situation can well be opposite (unless you use zones to compensate for this in Solaris). Indirect evidence of higher security of kernel and filesystem is higher grade of USA military certification for Solaris. While this is largely a bureaucratic procedure, Solaris is rated a level higher than Linux for graded security. Two major security subsystems that Solaris kernel and filesystem supports -- ACLs and RBAC -- have weaker or "cut corners" type of implementation under Linux.

It's actually does not make sense to compare OSes without hardening anymore, so availability and quality of hardening packages is another important differentiator, especially for enterprise environment. Here Solaris has slight edge as there is one enterprise-quality hardening package r Solaris -- JASS and one easily modified package that can be adapted for 'ad hoc" additional hardening (Titan) [Softpanorama2005a]. JASS recently became Sun-supported package (configuration changes introduced by JASS are supported by Sun's tech support). JASS can also be used as a part of  Jumpstart-powered installations. Although JASS's scripts itself are very weak: primitively architectured and written in not very suitable for the task language (Borne shell is used), the resulting configurations are not bad and some ideas (like making /usr a read only filesystem) are replicable in linux. 

Bastille used in linux is extremly weak, badly written and thought out package that provides essentially a false sense of security.  In essence linux currently does not have any viable hardening package (I might be wrong as NIST and DISA are doing decent job for government organizations and their document and scripts have real value in this area. see UNIX STIG Script Page and DISA Security Checklists). 

All-in-all Solaris had advantages in hardening area and especially in  minimization area (if, for example, anyone have plans for minimizing Suse SLES 10, I wish him/her success; even removing of mono ( ..NET clone promoted by Miguel de Icaza, the microsoftizer in chief ) is not that that simple  ;-). At the same time there are replicable procedures for packages minimization for Solaris that help to produce very tight, bastion host type configurations.

While both Solaris on Sparc and Solaris on Opteron have protection from buffer overflow, Solaris on Sparc is slightly more secure. This is kind of security via obscurity, but only complete idiots can argue that security via obscurity is a bad idea (typical argumentation making analogy if such complex system as Os with crypto algorithms does not stands any critique). To write an exploit for UltraSparc you need to shell out at least $500 to get an UltraSparc box (some ancient UltraSparc boxes like Ultra 5 and Ultra 10 can be obtained for less on eBay, but this might be pretty humiliating experience for exploit writer used to disassembly and compilation speeds of dual CPU 3.x GHz Intel boxes ;-).  Also you need to learn a new architecture and most exploit writers are looking for low hanging fruit. Attempts to write exploit "on a cheap" face the risk being caught abusing your office or University lab server.  So the main source of Solaris exploits can be security companies selling some vulnerabilities info and prototypes to IDS companies. But PR return on such an investment is low, so we can safely assume that Windows are their favorite target with Linux as a close second and Solaris as distant, distant third if on the radar screen at all. In most cases they do not have specialists to cover more then two OSes and few startups have specialists who have in-depth understanding UltraSparc architecture. 

In any case the mere differences on hardware architecture and the status of Intel as a dominating hardware architecture guarantees that the potential number of people who can write a Solaris-specific exploit (or port an exploit from Intel to UltraSparc) is several orders of magnitude less than for Linux or Windows. In the latter case nothing prevents you doing this in a privacy of your home using a regular PC. And no amount of advocacy can change this simple fact.

I would like to stress it again, that UltraSparc provided a usable defense for stack overflows, the dominant exploit type for Linux. So to use linux advocates catch phase here Solaris rules and Linux sucks :-). To slightly offset this advantage, it is fair to mention that Dtrace can probably be used by exploit writers ;-)

Formally Solaris 10 is being evaluated for RBACPP and CAPP. Solaris 10 trusted extension will include LSPP. That means that Red Hat with its label based security does not have advantage over Solaris even if we believe those largely bureaucratic certification procedures (Sun's older Trusted Solaris 8 complies with CAPP, RBACPP and LSPP at EAL 4+.)

Another topic are overflow exploits. Here we need to distinguish what really works from what is theoretically possible. Solaris stack protection really works. But most modern OSes now use additional technologies to protect programs from primitive overflow exploits.  That actually means that exploits for which alerts are produced by usual suspects like  CERT may or may not be an actual threat depending on the setting used.  This is especially true for stack overflow exploits against which along with hardware protection other methods exist and now can be activated (but usually are not :-).   Although Solaris is not mentioned the following blog entry gives a good overview of  the additional options available but provides incorrect comparison diagram.

Actually diagram looks more like a wishful thinking then actual depiction of the state of the art. I am very skeptical that RHEL ever can match OpenBSD in this area. Also it is new to me that RHEL 4 has default hardware stack overflow protection enabled in non AS-level kernels. I think that this is a typo and actual version should be 5 as  capabilities listed on the diagram below mostly belong to RHEL 5. Even in this version most are still experimental (SELinux restricts certain memory protection operation only if the appropriate Boolean values enable these checks; those options are rarely used and if used might not work in RHEL 4. For more information see [PDF] Security Enhancements in Red Hat Enterprise Linux (beside SELinux), LWN Security-improving technologies which could be deployed now , LWN Edgy and Proactive Security and danwalsh SELinux Reveals Bugs in other code.;

Both in Solaris and Linux stack protection requires modern 64 CPUs with NX bit like Opteron or Intel Duo.

Anyway here is diagram :

Note: OS X does have an NX stack now, but I don’t want to modify Gunnar’s chart. Note also: this slide is currently sourced to Rich Johnson.

Section Reordering lines up executable image sections so that a single data overflow can’t take out, say, the global offset table.

EXE randomization, a la PIE, randomizes the layout of text sections in position-independent code.

DLL randomization makes the base addresses of DLLs random so that shellcode won’t know the address to jump to to reach sensitive functions.

Frame Protection for the stack inserts unpredictable cookie values and runtime checks to make sure stack frames aren’t overwritten.

Exception Checks do the same thing for exception handlers, which are function pointers stored in reliable locations and a target for overflows.

Local Variable Protection creates checked guard values next to overflowable stack buffers.

Stack Randomization makes stack address offsets unpredictable.

Nonexecutable stacks use hardware page protection to prevent code from running on the stack at all, meaning shellcode needs to be stored somewhere else.

Heap Metadata Protection a la Win32 XOR’s key fields in the allocator tracking structures so that they don’t have predictable valid values.

Randomization in the heap works like randomization in the stack, and

The heap can also be made non-executable.

There are features that aren’t covered in Gunnar’s chart. For instance, OpenBSD deserves ticks for Niels Provos’ Systrace, which allows the OS to revoke capabilities from programs entirely. Win32 uses cryptographic signatures for code loaded in certain environments. Windows also supports managed code. Even Cisco IOS had an elaborate periodic heap sanity checker. MacOS X does not yet have any of these features.

In general protection from buffer overflows is a complex topic and many theoretically attractive methods are very difficult to implement in mainstream distribution like RHEL See Comparative Study of Run-Time Defense Against Buffer Overflows. Also to add insult to injury a lot of users switch SELinux off as the level of additional complexity it creates is unacceptable to them.

Solaris RBAC

As for RBAC, Solaris 10 is probably the first Unix that implements a usable, elegant  version of RBAC that might eventually seduce mainstream administrators. Before that RBAC in Solaris can be implemented only under the gun.

Because of that the level of mainstream adoption of RBAC in Solaris 8 and 9 was essentially limited to conversion of root to the role (that means that you cannot directly to login to root; in order to get root privileges you need first to login into your own account that has privileges of switching to root and only then you can assume the root role.  Even emulation of sudo capabilities did not work well before Solaris 10 and many enterprises paradoxically installed sudo on Solaris 8 and 9 servers.

While RBAC implementation alone puts Solaris 10 above Linux in security, zones make linux just a backwater OS suitable only for non-security conscious administrators (but we will discuss this issue separately). I would say that only Solaris 10 is up to the task in helping to make sense out of such an illusory and fuzzy goal as SOX conformance, this new Mecca of IT managers of publicly traded large US companies (with newly minted ayatollahs from major accounting companies dispersing their stupid or not so stupid fatwas with interpretation of meaning of "compliance" with the holy book that in best oriental religions tradition does not even explicitly mention IT :-)  

Solaris also has pretty good support of PAM, but paradoxically despite the fact that PAM originated in Solaris,  Linux surpassed Solaris in this area and the assortment and the level of integration into major distributions of PAM modules is significantly higher for Red Hat and Suse. Both has larger variety and sometimes higher quality of PAM modules available. They can be converted into Solaris PAM modules without major problems but you need to be a programmer (or hire one) to do that. For most companies the fact that many Linux PAM modules licensed under GPL does not matter as they do not plan to distribute the result of conversion outside the company anyway. Still other things equal BSD licensed modules are a better source of inspiration (see Labyrinth of Software Freedom (BSD vs. GPL and social aspects of free licensing debate for more details).

Zones

What is really important for enterprise environment (and for enterprise security) is that version 10 has a light weight VM, a derivative of BSD jails called Solaris Zones.  While useful for many other purposes they completely and forever change Unix security landscape.  If Sun marketing is more inventive it should adopt the initial internal name for zones and call them "Kevlar vests for applications" :-)

Zone sometime called containers because Sun marketing people cannot get their act together and have a tendency to rename things until total user confusion (along with zones the notable victim of their addiction to renaming is iPlanet aka SunOne or whatever the name of this former Netscape Enterprise Web server is today; it seems they rename it each quarter ;-)

Zones behaves as an individual machine, with its own IP address.  Paradoxically but in The current SOX-crazy climate this is one of the most important things you can do to insure isolation of applications on a given server instead of writing tons of useless reports with mutipage spreadsheet in best Brezhnev socialism traditions. Sometimes you can also use this for running several instances of the same application with different access rights. For example, zones represent a very attractive solution for WEB hosting. The Register described this feature in the following way:

In many ways, the Solaris Zones - known internally by the Kevlar code-name - will be a hardened version of the Solaris Containers currently offered to users for keeping applications isolated from each other. With the Zones, users can split up applications into numerous different compartments all running on one OS image. The amount of processor power, I/O bandwidth and memory for each Zone can be altered, and each one can also be rebooted, said John Fowler, CTO of software at Sun.

"It's a pretty simple idea," Fowler said. "You want to keep the number of OS images down to a reasonable level. With the Zones, you have a single layer of hardware and a single operating system. You have applications that think they are running on their own OS."

Sun customers currently rely on physical or hardware-based partitioning to slice up their midrange and high end servers for different operating system images. While this method of partitioning provides the most protection between OSes, it does not let users create as many divisions as the logical partitioning (LPAR) from IBM or HP.

Solaris Containers do help split up applications from each other and form something resembling a logical partition, but they have not been proven to isolate errors with the same success as a LPAR, say analysts. This could be the same potential problem faced by Zones unless Sun can show the technology works as billed.

"The big question with Kevlar is whether it will really isolate software faults to nearly the same degree as LPARs," said, Illuminata's Gordon Haff. "This is going to be a very tricky question to get better than anecdotal evidence about even after the technology is available."

Sun does get some benefit of the doubt when a new feature of Solaris is under debate because the vendor tends not to muck around with its prized code base.

IBM and HP are beating the LPAR server consolidation drum quite hard, but Sun is rejecting this path. It thinks adding more and more OS images is a waste of users' time and money.

"I think there is a diminishing point of return if you want to run multiple OS images on a single server," Fowler said.

Sun wants to avoid the road taken by HP and IBM, which puts one copy of the OS in each LPAR. Tasks such as applying patches, software updates and adding more disk space will take less time with just one image of the OS to worry about, Fowler argued.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Created Jan 2, 2005.  Last modified: March 12, 2019