13 July 2015

Immutable Service Containers



Immutable Service Containers and Oracle Solaris Studio 12.4

Economics of Oracle Solaris


Solaris Immutable Service Containers




While the need for security and integrity is well-recognized, it is less often well-implemented. Security assessments and industry reports regularly show how sporadic and inconsistent security configurations become for organizations both large and small. Published recommended security practices and settings remain unused in many environments and existing, once secured, deployments suffer from atrophy due to neglect.

Why is this? There is no one answer. Some organizations are simply unaware of the security recommendations, tools, and techniques available to them. Others lack the necessary skill and experience to implement the guidance and maintain secured configurations. It is not uncommon for these organizations to feel overwhelmed by the sheer number of recommendations, settings and options. Still others may feel that security is not an issue in their environment. The list goes on and on, yet the need for security and integrity has never been more important.

Interestingly, the evolution and convergence of technology is cultivating new ideas and solutions to help organizations better protect their services and data. One such idea is being demonstrated by the Immutable Service Container (ISC) project. Immutable Service Containers are an architectural deployment pattern used to describe a platform for highly secure service delivery. Building upon concepts and functionality enabled by operating systems, hypervisors, virtualization, and networking, ISCs provide a secured container into which a service or set of services is deployed. Each ISC embodies at its core the key principles inherent in the Sun Systemic Security framework including: self-preservation, defense in depth, least privilege, compartmentalization and proportionality. Further, ISC design borrows from Cloud Computing principles such as service abstraction, micro-virtualization, automation, and "fail in place".

By designing service delivery platforms using the Immutable Service Containers mode, a number of significant security benefits:


For application owners:

  • ISCs help to protect applications and services from tampering
  • ISCs provide a consistent set of security interfaces and resources for applications and services to use


For system administrators:

  • ISCs isolate services from one another to avoid contamination
  • ISCs separate service delivery from security enforcement/monitoring
  • ISCs can be (mostly) pre-configured by security experts


For IT managers:

  • ISCs creation can be automated, pre-integrating security functionality making them faster and easier to build and deploy
  • ISCs leverage industry accepted security practices making them easier to audit and support


It is expected that Immutable Service Containers will form the most basic architectural building block for more complex, highly dynamic and autonomic architectures. The goal of the ISC project is to more fully describe the architecture and attributes of ISCs, their inherent benefits, their construction as well as to document practical examples using various software applications.

While the notion of ISCs is not based upon any one product or technology, an instantiation has been recently developed using OpenSolaris 2009.06. This instantiation offers a pre-integrated configuration leveraging OpenSolaris security recommended practices and settings. With ISCs, you are not starting from a blank slate, but rather you can now build upon the security expertise of others. Let's look at the OpenSolaris-based ISC more closely.

In an ISC configuration, the global zone is treated as a system controller and exposed services are deployed (only) into their own non-global zones. From a networking perspective, however, the entire environment is viewed as a single entity (one IP address) where the global zone acts as a security monitoring and arbitration point for all of the services running in non-global zones.

As a foundation, this highly optimized environment is pre-configured with:


non-executable stack
encrypted swap space (w/ephemeral key)
encrypted scratch space (w/ephemeral key)
security hardened operating system (global and non-global zones)

Further, the default OpenSolaris ISC uses:


Non-Global Zone. Exposed services are deployed in a non-global zone. There they can take advantage of the core security benefits enabled by OpenSolaris non-global zones such as restricted access to the kernel, memory, devices, etc. For more information on non-global zone security capabilities, see the Sun BluePrint titled "Understanding the Security Capabilities of Solaris Zones Software". Using a fresh ISC, you can simply install your service into the provided non -global zone as you normally would.
Further in the ISC model, each non-global zone has its own encrypted scratch space (w/its own ephemeral key), its own persistent storage location, as well as a pre-configured auditing and networking configuration that matches that of the global zone. You do not need to use the encrypted scratch space or persistent storage, but it is there if you want to take advantage of it. Obviously, additional resource controls (CPU, memory, etc.) can be added as necessary. These are not pre-configured due to the variability of service payloads.

Solaris Auditing. A default audit policy is implemented in the global zone and all non-global zones that tracks login and logout events, administrative events as well as all commands (and command line arguments) executed on the system. The audit configuration and audit trail are kept in the global zone where they cannot be accessed by any of the non-global zones. The audit trail is also pre-configure d to be delivered by SYSLOG (by default this information is captured in /var/log/auditlog).

Private Virtual Network. A private virtual network is configured by default for all of the non-global zones. This network isolates each non-global zone to its own virtual NIC. By default, the global and non-global zones can freely initiate external communications, although this can be restricted if needed. A non-global zone is not permitted to accept connections, by default. Non-global zone service s can be exposed through the global zone IP address by adjusting the IP Filter and IP NAT policies (below).

Solaris IP NAT. Each non-global zone is pre-configured to have a private address assigned to its virtual NIC. To allow the non -global zone to communicate with external systems and networks, an IP NAT policy is implemented. Outgoing connections are masked using the IP address of the global zone. Incoming connections are redirected based upon the port used to communicate. Beyond simple hardening of the non-global zone (a state which can be altered from within the non-global zone itself), this mechanism ensures that the global zone can control which services are exposed by the non-global zone and on which ports.

Solaris IP Filter. A default packet filtering policy is implemented in the global zone allowing only DHCP (for the exposed network interface) and SSH (to the global zone). Additional rules are available (but disabled) to allow access to non-global zones on an as-needed basis. Further, rules are implemented to deny external access to any non-global zone that has changed its pre-assigned (private) IP address. Packet filtering is pre-configured to log packets to SYSLOG (by default this information is captured in /var/log/ipflog).

So what does all of this really mean? Using the ISC model, you can deploy your services in a micro-virtualized environment that offers protection against kernel-based root kits (and some forms of user-land root kits), offers flexible file system immutability (based upon read-only file systems mounted into the non-global zone), can take advantage of process least privilege and resource controls, and is operated in a hardened environment where there is a packet filtering, NAT and auditing policy that is effectively out of the reach of the deployed service. This means that should a service be compromised in a non-global zone, it will not be able to impact the integrity or validity of the auditing, packet filtering, and NAT configuration or logs. While you may not be able to stop every form of attack, having reliable audit trails can significantly help to determine the extent of the breach and facilitate recovery.

The following diagram puts all of the pieces together:



Solaris 11 – Immutable Zones

Immutable zones are read-only zones, but still contain “whole root” file systems.  The immutable zone can be configured as a completely read-only zone or it can be partially read-only.  The immutable zone is controlled by a mandatory write access control (MWAC) kernel policy.  This MWAC policy enforces the zone’s root file system write privilege through a zonecfg file-mac-profile property. The policy is enabled at zone boot.

By default, a zone’s file-mac-profile property is not set in a non-global zone. The default policy for a nonglobal zone is to have a writable root file system. In a Solaris read-only zone, the file-mac-profile property is used to configure a read-only zone root. A read-only root restricts access to the run-time environment from inside the zone. Through the zonecfg utility, the file-mac-profile can be set to one of the following values.



- See more at: http://unixed.com/blog/2013/02/the-solaris-11-immutable-zone/#sthash.sCSNGFSo.dpuf









Oracle Virtualization  



Oracle Software in Silicon Cloud

Speed and Simplify Your Business  (https://www.oracle.com/corporate/features/software-in-silicon/index.html)

Accelerate application performance and significantly improve security.


Oracle’s revolutionary Software in Silicon technology hardwires key software processes directly onto the processor. Because accelerated functions are run on special engines on the processor's silicon, yet kept separate from its cores, the technology speeds up performance of an application while retaining the overall functionality of the processor.

Oracle’s revolutionary Software in Silicon technology hardwires key software processes directly onto the processor.

Because accelerated functions are run on special engines on the processor's silicon, yet kept separate from its cores, the technology speeds up performance of an application, and implements data security in hardware, while retaining the overall functionality of the processor.

At Oracle OpenWorld 2014 John Fowler announced Oracle Software in Silicon Cloud, which provides early access to revolutionary Software in Silicon technology that dramatically improves reliability and security, and accelerates application performance.





Introducing Oracle Solaris Studio 12.4


Oracle Solaris Studio 12.4 - Technical Mini-Casts


Oracle Solaris OpenStack


Network Virtualization Using Crossbow Technology



More Information:

http://docs.oracle.com/cd/E23824_01/html/821-1460/glhep.html


http://www.c0t0d0s0.org/archives/5033-Immutable-Service-Containers.html


http://www.unixarena.com/


http://www.unixarena.com/2013/06/solaris-11-new-features-capabilities-of.html


http://unixed.com/blog/2013/02/the-solaris-11-immutable-zone/


https://blogs.oracle.com/gbrunett/entry/new_opensolaris_immutable_service_containers


https://kenai.com/projects/isc/pages/OpenSolaris/revisions/2


http://securitywannabe.com/blog/2009/07/02/what-is-an-immutable-service-container.html


http://c59951.r51.cf2.rackcdn.com/5028-128-galvin.pdf


http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/32358


http://learnings-on-solaris.blogspot.nl/2014/01/immutable-zones.html


https://blogs.oracle.com/solaris/entry/solaris_11_3_bloglist


https://blogs.oracle.com/markusflierl/entry/release_of_solaris_11_3


https://www.oracle.com/corporate/features/software-in-silicon/index.html


Share:

0 reacties:

Post a Comment