Monday Nov 02, 2009

Immutable Service Containers @ Amazon EC2

Just in time for the OpenSolaris Developer Conference, we were able to publish new Immutable Service Containers images directly to the Amazon Web Services Elastic Compute Cloud (EC2) environment. Previously, I talked about creating ISCs using our security enhanced OpenSolaris 2009.06 AMIs. Today, I am happy to announce that we have taken the next logical step by making available AMIs that fully incorporate the ISC changes. If you want to try out this configuration, simply provision an Immutable Service Containers AMI on EC2. We have made AMIs available in both the U.S. (ami-48c32021) and European (ami-78567d0c) regions. As always, we would love to get your feedback on these images and what you would like to see next!

Take care!

Technorati Tag:

Immutable Service Containers @ OSDevCon

Just wanted to let everyone know of a new Immutable Service Containers technical presentation (ODF, PDF) that has been posted. This version was delivered last week in Dresden, Germany at the OpenSolaris Developer Conference. This presentation has all of the latest and greatest information particularly on the OpenSolaris ISC Construction Kit. As always, I would love to hear your comments and feedback!

Take care!

Technorati Tag:

Friday Sep 11, 2009

Immutable Service Containers on Amazon EC2

Back in June, we released the very first security hardened virtual machine images for the Amazon Web Services Elastic Compute Cloud (EC2) environment. These original images were based upon the OpenSolaris 2008.11 release and were configured in accordance with the guidelines published by Sun the Center for Internet Security. Since its initial release, we have provided an update to offer this image in the European Region. In August, we took another step forward with the release of a security-enhanced image based upon the OpenSolaris 2009.06 release. This image went beyond just the simple hardening of its predecessor to add functionality such as encrypted swap, non-executable stacks and auditing that was enabled by default. With such a strong foundation, it should have been no surprise that it was likely to be used as a foundation for layered functionality. Just this month, for example, we announced the release of an image pre-configured with Drupal (v6.10) along with Apache (v2.2), MySQL (v5.0), and PHP (v5.2).

In parallel, the Immutable Service Containers project was announced back in June. This project was focused on the creation of secure execution environments for services. One of the key deliverables from this project has been the OpenSolaris ISC Construction Kit (Preview) that transforms an OpenSolaris 2009.06 system into an ISC configuration. Interestingly, several of the functional elements used today as part of the security-enhanced AMIs actually got their start as part of the ISC Construction Kit.

This brings us to today. For the first time, we have been able to create ISCs in the Cloud on Amazon EC2! Using the OpenSolaris ISC Construction Kit and the security-enhanced OpenSolaris 2009.06 AMI, we have deployed an ISC that exposes a representative service (in this case, a web server).

HELLO WORLD!

The nice thing about this is that the installation process was essentially the same as the one we used to create our pre-configured OVF image. There were two settings that needed to be adjusted in order for the ISC Construction Kit to properly work on EC2:

export ISC_SVCS_DOCK="fs network zone encrypted_scratch"
export ISC_DOCK_NET_IF_NAME="xnf0"

These two parameters had to be set before running the iscadm.ksh command. The first parameter simply removes steps that have already been completed in the base AMI (or are not needed for EC2). The second parameter changes the network interface name from e1000g0 (default) to xnf0 which is needed on EC2. That's all there was to it!

If you are interested in ISCs and how you can use them in your environment, I would love to hear from you! Also, just in case you missed it, I had the pleasure of joining Hal Stern to discuss ISCs on a recent Innovating@Sun podcast. Check it out and send us your feedback! Thanks in advance!

Take care!

Technorati Tag:

Friday Aug 14, 2009

NEW: Security Enhanced OpenSolaris 2009.06 on Amazon EC2

It is with great pleasure that I can announce the availability of security enhanced OpenSolaris 2009.06 on Amazon EC2! This release builds upon the work previously completed for the hardened OpenSolaris 2008.11 images as well as recent advances from the Immutable Service Container project. The end result is a OpenSolaris 2009.06 virtual machine image that is hardened, leverages a non-executable stack, encrypted swap as well as auditing enabled and pre-configured to record administrative events, logins, logouts, and all command executions. Just as with the OpenSolaris 2008.11 images, the hardening configuration of these new images complies with the recommendations published by Sun, the Center for Internet Security as well as the U.S. National Security Agency. This really cool thing is that they are all have the exact same guidance! I wonder how that happened?

Want to give it a spin? Check out the release announcement for more details. The AMI identifier is ami-e56e8f8c! Please send us your feedback!

As always, this work would not have been possible without the extensive support of the OpenSolaris on EC2 team. You are the greatest! Thank you so much for all of your help and support in making these images a reality!

Technorati Tag:

Wednesday Aug 01, 2007

Solaris Non-Executable Stack Concluded

Since publishing my two part series on non-executable stacks in the Solaris operating system, I received some very useful feedback and clarifications that I wanted to share with everyone. First, Vladimir Kotal commented on my first article that:

Having to grep(1) for the CPU features is really clumsy. Maybe psrinfo(1M) could be extended to print them out? (for every (virtual) CPU present in the system)

Frankly, I agree. After asking around however, today there does not appear to be a cleaner interface (although there is a bunch of discussion around adding one). Sherry Moore and Joe Bonasera were kind enough to point out that there is a programmatic way to access this information in the form of cpuid(7d). Joe also shared the following with me that you may find interesting:

The NX information doesn't belong in isainfo. isainfo, I'm told, is only meant to reflect processor capability information that is directly usable from user mode.

The NX bit feature has to do with page table construction which is not something you do from userland. What's a more interesting thing to know is "Does not specifying PROT_EXEC have any effect on this system, or is PROT_EXEC implicit for all PROT_READ segments?" Even cpuid doesn't help with that information as various bits of the OS memory subsystems might do different things along the way. For example if for some reason you're running a non-PAE 32 bit kernel, even though cpuid says that NX is supported, NX bits wont be used.

A similar issue has come up in the Open Solaris Xen project, in that many people want to know if their processor supports AMD-V or Intel VT-x. That information comes from CPUID, but is only usable from supervisor (either kernel or hypervisor) code, hence we haven't added it to isainfo. But it is a valid question to ask if the cpu/bios you have would support running such software w/o actually having it.

That said, Sherry did clue me in on a program called cpuid which can allow us to get this information and a lot more (subject to the issues noted by Joe above). Unfortunately, the cpuid program was developed for Linux and will not compile by default on Solaris:

blackhole$ gmake
cc -g -Wall -Wshadow -Wcast-align -Wredundant-decls -Wbad-function-cast -Wcast-qual -Wwrite-strings -Waggregate-return 
-Wstrict-prototypes -Wmissing-prototypes -D_FILE_OFFSET_BITS=64 -DVERSION=20070801 -o cpuid cpuid.c
cpuid.c:26:25: linux/major.h: No such file or directory
cpuid.c: In function `explain_errno':
cpuid.c:3191: error: `CPUID_MAJOR' undeclared (first use in this function)
cpuid.c:3191: error: (Each undeclared identifier is reported only once
cpuid.c:3191: error: for each function it appears in.)
cpuid.c: In function `real_setup':
cpuid.c:3472: warning: implicit declaration of function `makedev'
cpuid.c:3472: error: `CPUID_MAJOR' undeclared (first use in this function)
cpuid.c: In function `main':
cpuid.c:3751: warning: initialization discards qualifiers from pointer target type
cpuid.c:3752: warning: initialization discards qualifiers from pointer target type
cpuid.c:3753: warning: initialization discards qualifiers from pointer target type
cpuid.c:3754: warning: initialization discards qualifiers from pointer target type
cpuid.c:3755: warning: initialization discards qualifiers from pointer target type
cpuid.c:3756: warning: initialization discards qualifiers from pointer target type
cpuid.c:3757: warning: initialization discards qualifiers from pointer target type
gmake: \*\*\* [cpuid] Error 1

Luckily, the changes to get this program to work on Solaris were simple (Thanks Sherry!). All that we needed to do was remove the references to /dev/cpu/\* as that is a Linux-ism that does not exist on Solaris. Here is the complete diff for those wanting to try this at home:

blackhole$ diff linux-cpuid.c cpuid.c
25a26
> #if 0
26a28
> #endif
3188a3191
> #if 0
3194a3198
> #endif
3450a3455
> #if 0
3489a3495
> #endif

Clearly, if you wanted the program to work on either OS, you could just substitute the #if 0 strings for something like #if !defined(SOLARIS) and then just define SOLARIS in the CFLAGS parameter when compiling on Solaris. But I digress... With this simple change implemented, you can now compile the cpuid program on Solaris:

blackhole$ gmake
cc -g -Wall -Wshadow -Wcast-align -Wredundant-decls -Wbad-function-cast -Wcast-qual -Wwrite-strings -Waggregate-return 
-Wstrict-prototypes -Wmissing-prototypes -D_FILE_OFFSET_BITS=64 -DVERSION=20070801 -o cpuid cpuid.c
cpuid.c: In function `main':
cpuid.c:3757: warning: initialization discards qualifiers from pointer target type
cpuid.c:3758: warning: initialization discards qualifiers from pointer target type
cpuid.c:3759: warning: initialization discards qualifiers from pointer target type
cpuid.c:3760: warning: initialization discards qualifiers from pointer target type
cpuid.c:3761: warning: initialization discards qualifiers from pointer target type
cpuid.c:3762: warning: initialization discards qualifiers from pointer target type
cpuid.c:3763: warning: initialization discards qualifiers from pointer target type
gzip < cpuid.man > cpuid.man.gz

These warnings can be safely ignored. With the program now compiled, let's give it a try and see what it can tell us about the NX bit:

blackhole$ ./cpuid | grep exec
      execution disable                      = false

Interesting. This system does not have the NX capability likely because I am running (Nevada in this case) in a Parallels VM which is 32-bit (reference Joe's note above). Let's give this a better test subject by trying it on a Sun X2100. This command is run from the global zone of a system running Solaris 10 11/06:

$ ./cpuid | grep exec
      no-execute page protection            = true

Careful observation will also show the AMD and Intel naming differences that I had talked about previously with respect to XD and NX.

Well, I think that I have talked about this subject to death. I hope that you found it interesting and perhaps a little educational. As always, I love to get your feedback! Before signing off, once again I would like to thank Sherry Moore and Joe Bonasera for sharing their knowledge and experience with me (and thereby with you)!

Take care,

Glenn

Technorati Tag:

About

This area of cyberspace is dedicated the goal of raising cybersecurity awareness. This blog will discuss cybersecurity risks, trends, news and best practices with a focus on improving mission assurance.

Search

Archives
« April 2015
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
  
       
Today