Thursday Jan 31, 2008

HEADSUP: Solaris 10 Security Best Practices

Just a quick heads-up note to say that the official Sun location for the Solaris 10 security recommendations documents has changed. While you can still get to the content from the OpenSolaris Security Community Library page, the new location is on sun.com.

The recommendations documents have been bundled into an archive so that they can be more easily downloaded in a single step. The individual documents are still available and can be downloaded at:

Tuesday Jan 08, 2008

World's Youngest Sun Ray on Solaris Nevada User

Well, I can hardly believe that three years has passed since the birth of my second son. In keeping with past tradition, today he received his first Sun Ray. Just as his brother before him, he received a Sun Ray 150. Having used his brother's Sun Ray for quite some time, he took to it with ease and had fun playing on some of the typical kids sites. I am sure he will pick things up in no time with his big brother at his side to help him along.

IMG_4369 IMG_4369_2

This bet on early access to technology has certainly paid off (not that I had any doubt!). My eldest is very at home with technology and the Internet whether on a Sun Ray, a Ubuntu desktop or even his Wii. He recently even asked if he could watch me next time I "fix" (read: upgrade) the computers so that he could learn how to do it. With Indiana, he may very well be able to do the upgrade next time! Even in school where they are forced to use Microsoft products, he adapts very well switching from MS Paint to gPaint and IE to Firefox, and so on. I am sure his little brother will follow in his technological footsteps.

A few things have changed over the years since we started down this winding road... The original Ultra 10 was upgraded some time ago to an Ultra 20. Solaris 10 gave way to Solaris Nevada (and everything that comes with it), the Sun Ray Server Software was also brought up to date, and more memory was added. Time passes and all things must change. In this case, certainly for the better!

With each new Solaris and SRSS upgrade, the experience becomes easier to install, configure and use. My hats off to both engineering teams who do a remarkable job. I can't wait until we get Indiana and Sun Ray linked up! Special thanks this round to Kent Peacock and P.S.M. Swamiji who helped me work out one last kink in getting rid of some very, very outdated Sun Ray firmware on my last remaining DTUs! Now everything from the DTU firmware, to the Sun Ray software, to the operating system, etc. are all running the very latest and greatest - at least until Nevada build 81 comes out!

Happy birthday, little one!

Friday Nov 02, 2007

NEW: Solaris 10 Set-ID and World Writable Overview

Various organizations have often asked for more detail regarding the set-uid, set-gid and world writable programs that are shipped by the default in the Solaris OS. Well, the wait is over (at least for Solaris 10 8/07)!

Today, I am happy to announce the public release of an overview document that describes these file system objects in detail. This document is still a draft and could still needs to answer a few questions, but I believe that it is far enough along to open up the discussion and begin getting feedback from all of you! If you are interested and want a copy of the document, you can find it here. Looking forward to your comments!

From the document:

While there are often many files delivered by operating systems and other software products, organizations are often most concerned with those programs and services that have or run with special privilege. Unfortunately, there is at times a lack of information regarding what these programs do and why their privileges are necessary. The goal of this document is to provide additional information on four special classes of objects delivered by the Solaris OS: Set-UID Files, Set-GID Files, and World Writable Directories and Files. With this information, organizations will be able to better understand the privileged programs, directories and files that exist on their systems.

If you would like to make recommendations or even implement an improvement (such as one of the RFEs listed in the document), please consider joining the OpenSolaris Security Community!

Glenn

Technorati Tag:

NEW: Solaris 10 Security Best Practices

It is with great pleasure that I can (albeit belatedly) announce the arrival of the latest security guidance from both Sun and the Center for Internet Security. Working together, in concert with representatives from academia, industry and government, we have published security guidance for Solaris 10 11/06 and 8/07. This content represents the best and most complete form of Solaris security guidance ever produced.

Not only are the recommendations based upon industry consensus but they are also supported by Sun. What is even better is that this material was completed with support and feedback from both the National Security Agency and the Defence Information Systems Agency. I would like to especially thank both organizations for their significant contributions to this material! This iteration brings us (Sun, CIS, NSA and DISA) closer than even toward a single, consistent set of security recommendations for the Solaris OS.

The Benchmark itself has been restructured. Today, it comes in the form of two documents: (1) the core hardening Benchmark itself and (2) an extended appendix covering additional Solaris security controls with examples and references for more information. Further, the Benchmark itself has been significantly reorganized to improve its correctness and flow. Thanks to Carole, our editor!

Some new elements to the Benchmark include headers for each item that tell you if a given recommendation is a Solaris 10 default value, for what platforms it applies and even what configuration settings you need to implement the recommendation using the Solaris Security Toolkit. Overall the document is a tremendous step forward toward bringing the world the best available insight into how to harden and more generally secure their Solaris systems. There have also been quite a few updates to account for changes and enhancements in Solaris. The Solaris Security Appendix document is completely new and provides an overview of the security capabilities of the Solaris OS with many examples and references for more information including step-by-step BluePrints and HOWTOS. If you are responsible for managing or securing a Solaris 10 system, these documents are for you!

You can find a copy of these documents at both the CIS web site as well as on OpenSolaris.org (CIS Solaris Benchmark, Solaris Security Appendix). As always, feedback and ideas for future revisions are encouraged! If you are interested in participating in future versions of these documents, please consider joining the CIS Unix Benchmark Team. Contact Dave for more information!

Glenn

Technorati Tag:

Monday Aug 13, 2007

Solaris Fingerprint Companion v0.5

For some reason, the links to things on SunSolve like the Solaris Fingerprint Database have changed and as a result, tools like my Solaris Fingerprint Companion stopped working. I would like to publicly thank Richard Mayebo for being the first to let me know of this issue. In addition to just fixing the links, it felt like an excellent opportunity to re-test the tool with the latest versions of Perl shipping on both Nevada as well as Ubuntu. I am very happy to report that the Solaris Fingerprint Database Companion tool continues to work just fine (after the required add-ons are installed). I have posted the latest and greatest version here as part of the OpenSolaris Security Community.

Give it a try and let me know what you think!

Take care,

Glenn

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:

Wednesday Jul 25, 2007

Solaris Non-Executable Stack Continued

Previously, we covered some of the history and basics of Solaris non-executable stacks and how they can be enabled globally on both SPARC and x86/x64 systems. In this article, we extend that foundation by talking about how developers can configure their own programs to have non-executable stacks, regardless of the value of the global system setting, noexec_user_stack.

This little bit of magic is accomplished through the use of a linker map file. In the case of non-executable stacks, the linker map file in question is /usr/lib/ld/map.noexstk. Simply specifying this map file during a compilation or link will cause the resulting program to have a non-executable stack. Looking at the comments in this file, we see how this is accomplished:

#
#ident  "@(#)mapfile_noexstk    1.3     01/07/13 SMI"
#
# Copyright (c) 2001 by Sun Microsystems, Inc.
# All rights reserved.
#
# Linker mapfile to create a non-executable stack definition within an
# executable.
# The linker does not use this file automatically, so one must use the -M 
# option to cc or ld:
#
#       cc -M /usr/lib/ld/map.noexstk myprogram.c
#
stack = STACK ?RW;

If this sounds pretty straightforward and easy to use, that is because it is! Let's go ahead and give it a try! Before we begin, I would like to thank Scott Rotondo for sharing with me the following sample program. This program will attempt to execute code on the stack. Our test system is configured with noexec_user_stack=0 and we will compile our test program both with and without using the map file so that they can be compared with one another.

First, here is our test program:

#include 
#include 

int x = 0;

void
incr(void)
{
        x++;
}

typedef void (\*funcptr)(void);

int
main(int argc, char \*\*argv)
{
        funcptr f;
        char code[100];

        /\* Copy the incr() function to the stack. \*/
        memcpy(code, (void \*)incr, sizeof(code));
        f = (funcptr)code;

        /\*
         \* Increment x twice, once by calling incr() and
         \* once by running the copy on the stack.
         \*/
        printf("x = %d\\n", x);
        incr();
        printf("x = %d\\n", x);
        f();
        printf("x = %d\\n", x);
        return (0);
}

Now, let's compile the program (with and without the map.noexstk map file):

$ gcc -O -o incr incr.c
$ gcc -O -o incr-nx -Wl,-M,/usr/lib/ld/map.noexstk incr.c

(Thank you to Luke for pointing out a cleaner way to pass the linker map file using gcc!)

Note that if you were using the Sun C compiler, you could have used the following commands:

$ cc -O -o incr incr.c
$ cc -O -o incr-nx -M /usr/lib/ld/map.noexstk incr.c

So, how do we know that the program, incr-nx, has a non-executable stack? One of the easiest ways is to use the elfdump(1) command telling it to look for the program header type, PT_SUNWSTACK. The absence of this program header means that the program is effectively in a default configuration where (depending on the platform) the stack segment could be readable, writable as well as executable. If a PT_SUNWSTACK program header is found then the default is not being used, and we need only to look at the p_flags parameter to see what permissions are being assigned to the stack segment.

$ elfdump -p -N PT_SUNWSTACK incr
$ elfdump -p -N PT_SUNWSTACK incr-nx

Program Header[5]:
    p_vaddr:      0           p_flags:    [ PF_W PF_R ]
    p_paddr:      0           p_type:     [ PT_SUNWSTACK ]
    p_filesz:     0           p_memsz:    0
    p_offset:     0           p_align:    0

As you can see from the output of the two commands above, the incr program's stack segment is configured in the default manner and will therefore have an executable stack (unless of course the global system parameter noexec_user_stack is set to 1). On the other hand, the incr-nx program does have a PT_SUNWSTACK program header. Looking at the p_flags parameter, we see that this program's stack segment will have only the read (PF_R) and write (PF_W) flags enabled.

The next obvious question is whether these programs will behave differently. Certainly, we would expect them to given that they are configured to execute code on the stack yet such an operation is only permitted in one of the two programs. Let's take a closer look:

$ ./incr
x = 0
x = 1
x = 2
$ ./incr-nx
x = 0
x = 1
Segmentation Fault (core dumped)

If we had enabled logging of attempts to execute code on the stack using the noexec_user_stack_log parameter, we would have also seen a syslog message similar to:

$ tail -1 /var/adm/debug
Jul 25 22:11:36 quasar genunix: [ID 533030 kern.notice] NOTICE: incr-nx[12553] attempt to execute code on stack by uid 101

Pretty cool, eh? So with the simple addition of the linker map file, we can now deploy programs and services that will have non-executable stack segments (out of the box)! In fact, a large portion of the ON (operating system and networking) consolidation in the Solaris OS is already configured this way! In fact, even the Sun-contributed Firefox (that is also included in Solaris 10 and OpenSolaris) uses this mechanism to enable non-executable stacks. Yes, even OpenOffice/StarOffice and Xorg are in on the action! So, what are you waiting for? Give it a try today!

I hope you enjoyed this brief overview into Solaris non-executable stacks. As always, I would love to get your feedback and ideas. You can read more on this topic here and here.

Take care,

Glenn

Technorati Tag:

Solaris Non-Executable Stack Overview

The ability to configure a Solaris system to run with non-executable stacks is not overly new. That functionality was originally introduced into the Solaris 2.6 operating system with the noexec_user_stack kernel parameter. Looking at the source code, this is how this parameter was documented (in usr/src/uts/common/vm/seg_vn.c):

 207 /\* 
 208  \* Patching this variable to non-zero allows the system to run with 
 209  \* stacks marked as "not executable".  It's a bit of a kludge, but is 
 210  \* provided as a tweakable for platforms that export those ABIs 
 211  \* (e.g. sparc V8) that have executable stacks enabled by default. 
 212  \* There are also some restrictions for platforms that don't actually 
 213  \* implement 'noexec' protections. 
 214  \* 
 215  \* Once enabled, the system is (therefore) unable to provide a fully 
 216  \* ABI-compliant execution environment, though practically speaking, 
 217  \* most everything works.  The exceptions are generally some interpreters 
 218  \* and debuggers that create executable code on the stack and jump 
 219  \* into it (without explicitly mprotecting the address range to include 
 220  \* PROT_EXEC). 
 221  \* 
 222  \* One important class of applications that are disabled are those 
 223  \* that have been transformed into malicious agents using one of the 
 224  \* numerous "buffer overflow" attacks.  See 4007890. 
 225  \*/ 

While non-executable stacks provide are a very useful technique for thwarting certain kinds of buffer overflow attacks, it should be noted that there exist other attack methods that do not rely on executable stacks. One such method was discussed back in 1999 on Bugtraq, but even in this case the author noted that there was inherent value in non-executable stacks (if only as an additional defense in depth layer):

Hopefully, these exploits demonstrate that it is important to make sure that programs that run at an elevated privilege are free of buffer overflow bugs. The stack protection will certainly help protect you from the majority of intruders, but moderately competent intruders will probably be able to bypass it.

Just as with minimization, hardening, and the deployment of services with reduced privilege, non-executable stacks are just another layer or tool to be used as part of a more comprehensive security architecture. But anyway, back to our story...

As with other kernel parameters, the non-executable stack state can be be adjusted (enabled or disabled) using the /etc/system file. For example, the following statement added to /etc/system would enable this feature:

set noexec_user_stack=1

As noted in the inline documentation above, experience has shown that "most everything works". In fact, the recommendation to enable this feature has been in Sun BluePrints since 1999 and similarly in the Solaris Security Toolkit since its inception. Looking even further, you find this common recommendation across the industry.

As a companion to this parameter, the noexec_user_stack_log parameter could be used to enable logging when this feature (if enabled) detected an attempt to run code from the stack. By default, this parameter is enabled if the noexec_user_stack parameter is enabled so no further action is required unless of course you want to prevent such logging. That has not stopped authors of tools and articles from recommending to enable it anyway using the command:

set noexec_user_stack_log=1

When this parameter is enabled and there is an attempt to execute code on the stack, a message such as the following will be generated and delivered via syslog to kern.notice:

Jul 25 14:48:02 quasar genunix: [ID 533030 kern.notice] NOTICE: myprog[12289] attempt to execute code on stack by uid 101

In this way, a system administrator can detect such attempts and take appropriate action.

Back in the days of Solaris 2.6, this parameter really only applied to the SPARC platform. Years passed and this feature continued to be available in Solaris 7, Solaris 8 and so on. As good fortune would have it, Intel and AMD got on board with the idea and the NX Bit was born. Technically speaking, Intel refers to its implementation as the XD Bit (for Execute Disable) while AMD has used the term NX (for No Execute), but for the purposes of Sun's implementation and this article, we will consistently use the term "NX" to refer to this functionality.

To find out if your system supports the NX bit, you can check in with the dmesg(1M) command:

$ dmesg | grep features
Jun 28 11:00:05 sec1 unix: [ID 126719 kern.info] features: 1176fdf<cpuid,cmp,sse3,nx,asysc,sse2,sse,pat,cx8,pae,mca,mmx,cmov,pge,mtrr,msr,tsc,lgpg>

Similarly, if you have syslog configured to log kernel.info messages, you can also get the information from your system log files:

$ grep "features:" /var/adm/debug
Jul 19 16:43:06 quasar unix: [ID 126719 kern.info] features: 1076fff<cpuid,sse3,nx,asysc,sse2,sse,pat,cx8,pae,mca,mmx,cmov,de,pge,mtrr,msr,tsc,lgpg>

The first example was taken from a SunFire X2100 system whereas the second example was taken from an Ultra 20. The same commands should be able to be used on other x86/x64 systems in order to determine if this CPU feature is available.

On the SPARC platform, the non-executable stack functionality is available but disabled by default (for SPARC V8) in order to support a fully ABI-compliant execution environment. For 64-bit SPARC platforms, however, the SPARC V9 ABI specifies a non-executable stack by default. Note that 32-bit applications running on a 64-bit kernel do not automatically get this protection by default and would rely on the noexec_user_stack parameter being set to 1 for example.

On NX-capable x86/x64 platforms, Solaris OS uses the NX bit by default whenever PROT_EXEC is not specified. Stack segments, however, use PROT_EXEC by default, so the NX functionality must be explicitly enabled on these platforms to provide stack protection. As noted above, this can be globally configured using the noexec_user_stack parameter just as with SPARC-based platforms.

From the product documentation, it should be noted that a system administrator can disable all use of the NX bit (non-SPARC platforms) by using the eeprom(1M) command to set enforce-prot-exec to off. This variable is provided as a transition workaround for any system with legacy applications that are missing PROT_EXEC.

In this article, we have taken a brief look at the history of non-executable stacks in Solaris dating back to the original integration of this functionality in Solaris 2.6 all the way to the present. In the next article, we will talk a little bit about how this functionality can be enabled on a per-file basis in the Solaris 10 OS.

Take care,

Glenn

Technorati Tag:

Wednesday Feb 28, 2007

Tracking Infected Telnet Worm Machines

Today, there has been a lot of discussion about the new telnet worm which exploits the recently announced telnet vulnerability in Solaris 10 and Nevada.

Aside from the usual recommendation of you should not be using telnet. You should be using SSH, I would like to cast a vote for the use of IP Filter. IP Filter is quick and easy to configure and can help give you visibility into attacks such as this. Beyond its initial use as an enforcement point (blocking access to services such as telnet), IP Filter is also a great tool to allow you to see what other systems are attempting to do to yours.

An IP Filter entry for the telnet worm may look something like:

Feb 27 15:26:38 blackhole ipmon[100]: [ID 702911 local0.warning] 15:26:38.269526 ip.tun0 @0:11 b 192.168.1.112,55039 -> 192.168.19.6,23 PR tcp len 20 52 -S I

With this format, you could quickly whip up a script to tell you who is knocking on your system's telnet door (even if telnet happens to be disabled - which is the case on my system). See:

blackhole$ getent hosts `grep  ipmon  /var/adm/debug | grep " b " |\\
   grep ",23 PR" | awk '{ print $13 }' | awk -F, '{ print $1 }' | sort -u`
10.1.42.252     europa
10.1.88.164     io
10.1.90.171     castor
10.3.29.39      pollux
192.168.174.48  orion
192.168.43.112  mercury
With just a little scripting, you can easily find out systems (particularly in an enterprise) that need some special love and attention.

Technorati Tag:

Tuesday Sep 26, 2006

Treo 700p on Nevada

Will wonders never cease? Today, I decided to plug my Treo 700p smart phone into my newly upgraded Solaris laptop. Honestly, I was not sure what would happen as this was the first time that I had tried to connect up a Palm device.

My goal for doing this was simple. I wanted to synchronize my calendar to my phone so that I would have a list of my appointments while I was on the road. I had wanted to use something more direct like SyncML, but that option was not available to me. Oh, well... I have been using Evolution lately to manage my appointments. What is interesting about my configuration is that my calendar is hosted on Sun's EdgeCal service which allows me to easily access and share my calendar from the Internet or within Sun. EdgeCal is basically a Sun Java System Calendar Server environment and I use the JESCS Evolution Connector to access EdgeCal. By the way, this all worked out of the box too!

So, back to today's experiment... Since Evolution already has an ability to synchronize with devices such as Palm Pilots, I decided to give that a try. The process was completely painless. I simply connected up the 700p via a USB port (actually on a USB hub since I am also using a USB keyboard and mouse), provided some basic settings information to Evolution (Pilot Synchronization Dialog) and hit the HotSync button. Evolution was able to not only find my device but also push the calendar information from EdgeCal to my phone in a matter of seconds. Way cool.

What is really nice is that I can also use the pilot-xfer command to also back up your device (to a ZFS partition in my case). You really have to love it when things just work.

Take care,

Glenn

Technorati Tag:

Tuesday Sep 05, 2006

Laptop Upgrade to Nevada - b47 - Security Settings

Today, I would like to go over a few of the changes that I made to my laptop in order to improve upon its overall security configuration. It should be noted that the list of changes made is relatively small (from the default) and is based upon how I plan to actually use the system. As a result, you may need more or different changes than those listed here based upon your specific needs. With that said, let's get into the details.

Nevada by default enforces the settings specified by the Secure by Default project. As a result, there were no network services listening on my laptop for external connections (with the exception of Secure Shell). This is a great start and significantly simplifies getting a desktop or laptop secured and ready for the network. Since I generally do not permit inbound access to my laptop, I also disabled Secure Shell:

blackhole$ pfexec svcadm disable ssh
blackhole$ svcs ssh
STATE          STIME    FMRI
disabled       21:30:12 svc:/network/ssh:default

At this point, there are literally no local services listening that an external person could access. As there is a need, I will temporarily enable services such as SSH or perhaps VNC (x11vnc), but the default is to leave them in a disabled state until they are required.

Next, I configured IP Filter - the firewall software built into Solaris. I have been a huge fan of IP Filter for years and was absolutely thrilled to see it integrated into Solaris 10. The configuration that I use is based upon a version for laptops that was developed by Darren Moffat. To be completely honest, I have a few different firewall policies that are automatically installed based on the network profile that I have selected. This allows me, for example, to have one firewall policy when I am connected via Ethernet on my home network and a different one when I am travelling.

Before installing the firewall policy, I needed to configure the file /etc/ipf/pfil.ap. Since I am working from a Toshiba Tecra M2, I had to uncomment the entry for the e1000g driver and add an entry for the ath driver as follows:

# egrep "e1000g|ath" /etc/ipf/pfil.ap
e1000g  -1      0       pfil
ath     -1      0       pfil

Next, I installed Darren's firewall configuration, /etc/ipf/ipf.conf. I will not provide my specific settings - leaving the firewall configuration as an exercise for the reader.

#
# ipf.conf
#
# IP Filter rules to be loaded during startup
#
# See ipf(4) manpage for more information on
# IP Filter rules syntax.

pass out quick all keep state keep frags

# Drop all NETBIOS traffic but don't log it.

block in quick from any to any port = 137 #netbios-ns
block in quick from any to any port = 138 #netbios-dgm
block in quick from any to any port = 139 #netbios-ssn

# Allow incoming IKE/IPsec

pass in quick proto udp from any to any port = ike
pass in quick proto udp from any to any port = 4500
pass in proto esp from any to any

# Allow ping

# pass in quick proto icmp from any to any icmp-type echo

# Allow routing info

# pass in quick proto udp from any to port = route
# pass in quick proto icmp from any to any icmp-type 9 # routeradvert
# pass in quick proto igmp from any to any

# Block and log everything else that comes in

block in log all
block in from any to 255.255.255.255
block in from any to 127.0.0.1/32

For the first time IP Filter configuration, there are a few other steps that I will not cover here now. Check out the documentation for the specifics.

With this complete, I turned my attention inward for a few additional configuration changes. You can read more about them in the Solaris 10 Benchmark published by the Center for Internet Security.

First, I modified the /etc/security/policy.conf file to set my default crypt(3C) algorithm to Sun MD5:

# The Solaris default is the traditional UNIX algorithm.  This is not
# listed in crypt.conf(4) since it is internal to libc.  The reserved
# name __unix__ is used to refer to it.
#
CRYPT_DEFAULT=md5

This is useful for a variety of reasons most notibly because it would freak out any script kiddy running stock versions of Crack and john in an attack to guess passwords. In their stock configurations (just download, compile and run), neither of these tools can successfully deal with the Sun MD5 password format. See the crypt_sunmd5(5) manual page:

     This module is designed to make it difficult to crack  pass-
     words  that  use brute force attacks based on high speed MD5
     implementations that use code inlining, unrolled loops,  and
     table lookup.

Moving on, I enabled the following coreadm configuration:

# coreadm
     global core file pattern: /var/core/core_%n_%f_%u_%g_%t_%p
     global core file content: default
       init core file pattern: core
       init core file content: default
            global core dumps: enabled
       per-process core dumps: disabled
      global setid core dumps: enabled
 per-process setid core dumps: disabled
     global core dump logging: enabled

This is nice in that the system will notify me (via syslog) of core dumps:

Sep  5 15:01:16 blackhole genunix: [ID 603404 kern.notice] NOTICE: core_log: sleep[5691] core dumped: /var/core/core_blackhole_sleep_101_101_1157482876_5691

and will store the core files in a protected directory, /var/core:

$ ls -ld /var/core
drwx------   2 root     root         512 Sep  3 21:13 /var/core

Moving along, I also set the following parameters:

# grep "noexec_user_stack" /etc/system
set noexec_user_stack = 1
set noexec_user_stack_log = 1

# grep nfs_portmon /etc/system
set nfssrv:nfs_portmon = 1

# grep TCP_STRONG_ISS= /etc/default/inetinit
TCP_STRONG_ISS=2

These are typical changes and are discussed in older Sun BluePrints as well as the CIS Benchmark. Next, I also created the loginlog file:

# ls -l /var/adm/loginlog
-rw-------   1 root     sys            0 Sep  3 21:16 /var/adm/loginlog

and enabled debug logging in syslog:

# grep '\*.debug' /etc/syslog.conf
\*.debug                                         /var/adm/debug

Be sure to create the /var/adm/debug file before restarting syslog. In addition, I also disabled login access on the laptop's serial ports:

# pmadm -d -p zsmon -s ttya
# pmadm -d -p zsmon -s ttyb
After installing a few basic warning banners in the typical places (see the CIS guide), I also changed root's home directory, converted root to be a Solaris role, and assigned the rights to assume root to only my local account:

$ getent passwd root
root:x:0:0:Super-User:/root:/sbin/sh

$ grep "\^root:" /etc/user_attr
root::::type=role;[...]

$ roles
root

Lastly, using the normal methods, I also enabled and configured Solaris auditing and BART so that I can keep tabs on what is going on. Of course, this is also in addition to BIOS and GRUB security changes that I will not cover in this post.

Is this all you need to do? Well, unfortunately - it depends. There are certainly lots of other things that I could do.

For example, I could disable rhosts authentication for the rsh and rlogin services. Recall however that each of those services is (1) disabled by default and (2) subject to the firewall policy in place. So, to successfully exploit this path, an attacker would need to change both of these settings - which require administrative privileges - enough to add rhosts entries back into /etc/pam.conf. So for me, it was about maximizing security while minimizing change. In this specific case, changes to those states or configuration files would be detected by BART and Solaris Auditing. Similarly, there is not much point (except as a reminder) for me to enable password aging, history or complexity rules when I am the only user on the system (and the system does not accept remote incoming connections - except in very limited cases).

You get the point... For another perspective, check out how John Clingan approached this problem.

My longer term hope is that we can further reduce the changes required out of the box by making many of the most common settings default Solaris values. That way, everyone could benefit from a stronger out of the box installation posture. SBD was a great step forward down this path. Let's look at a few examples of RFEs that are outstanding right now:

Would you like to see these implemented? If so, let us know! If you have a valid Solaris support contract, you can also contact support to have you added as a customer call record for one or more of these RFEs. Just as important - are there other security changes that you would like to see made by default in future versions of Solaris! If so, be sure to tell us! File bugs or RFEs! Talk with us! and (if you are so included) participate and help us make the changes!

Before I sign off, you may be wondering why not just use the Solaris Security Toolkit and be done with it? Certainly, I could have used the (currently unreleased) version that supports SBD and implemented these changes. In fact, most companies may want to go that route since SBD alone (as demonstrated above) covers just part of the problem space. The reason however is simple. I wanted to demonstrate what it would take for you to quickly and easily secure a new OpenSolaris or Nevada laptop from an out of the box state. All too often the tools and guides make people think that it is harder than it really is. Certainly, the Toolkit is essential for building repeatable, auditable configurations, but in the case of my one off - the time difference to implement is negligible.

Take care,

Glenn

Technorati Tag:

Saturday Sep 02, 2006

Laptop Upgrade to Nevada b47 - A Few More Things

[Read More]

Friday Sep 01, 2006

Laptop Upgrade to Nevada b47 - The Next Day

Several hours into day 1 of the upgraded laptop and no significant issues to report. The complete installation went smoothly and all of my productivity tools appear to have retained their settings and are working as expected including:

This is in addition to the other tools I mentioned in my previous post, including: frkit, Nvidia drivers, punchin, pkg_get, and inetmenu. The Nvidia drivers are correctly pushing my screen image (by default) to both the laptop LCD and my external flatscreen. What more count I ask for?

During the course of my new installation, I set aside enough space to install Trusted Extensions, so that will be my next big step, but before I do that, I am going to put the laptop through its paces for a few days to make ensure everything continues to work as expected.

You really have to love it when things just work!

Take care,

Glenn

Technorati Tag:

Thursday Aug 31, 2006

Laptop Upgrade to Nevada b47

Well, it has taken me quite a while but I finally have bitten the bullet and started upgrading my laptop to a newer version of Nevada. Given that my laptop is my office, I am always a little hesitant to change things when everything is working smoothly. An honestly, that has been the case for quite some time as is evidenced by the fact that I am still running (dare I say it) build 18!

While I have a number of other systems at home at build 42, I wanted to be able to showcase some of the latest and greatest technology found in the newer builds including (but certainly not limited to): SBD, ZFS, and Trusted Extensions. In fact, I have a number of conference sessions coming up (I will write about those later) where it will be great to highlight this great technology.

I will not go into the gory details, but for those interested, I did follow the usual procedures, namely (1) backup existing content, (2) download and burn the DVD ISO, (3) boot the DVD ISO and do the initial configuration, (4) click install and sit back. Well, that is exactly where I am right now... Sitting back - about 68% through the installation. I have also downloaded the latest essentials for my M2 including: frkit, Nvidia drivers, punchin, pkg_get, and inetmenu. With this and a "quick" download of StarOffice 8, I will be back in business in no time. Well, at 78% complete, I have enough time to go brew some tea, so I will bid you all good night.

Take care,

Glenn

Technorati Tag:

Wednesday Feb 15, 2006

CIS Solaris 10 Security Benchmark Support

On Tuesday, Sun issued a press release titled, "Sun Announces Plan for Trusted Extensions for Solaris 10, the Most Secure Operating System on the Planet". Hidden somewhat discretely within this release (for reasons not entirely clear to me) was the following:

Support for CIS Benchmark

Sun has also extended support services for Solaris 10 OS deployments that adhere
to the Center for Internet Security (CIS) Benchmark. Named "best benchmarking 
effort" by Information Security Magazine, CIS Benchmarks are developed through 
a global consensus process involving hundreds of security professionals to 
determine best-practice security configurations. The CIS Level-I Benchmark for
the Solaris 10 OS is a compilation of security configuration actions and settings
introduced in March 2005. As a result of a close partnership between Sun and the
members of CIS, Solaris 10 Service Plan customers who now implement the CIS
security recommendations will have Sun support for their resulting configurations.
Complementing Sun's freely available Solaris Security Toolkit, CIS will also
introduce a Scoring Tool for the Solaris 10 OS later this month, giving users a
quick and easy way to evaluate systems and compare their security configuration
against the CIS Benchmark criteria. 

This is actually quite an important announcement!

A number of us have been working with the Center for Internet Security, or CIS, for years in an effort to promote more consistent and complete Solaris security recommendations and to better align their Solaris Security Benchmarks with our recommendations. In fact, the CIS Solaris 10 Security Benchark represents the highest level of collaboration and sharing to date. Together, we were able to develop and publish the updated Benchmark document before the GA of Solaris 10 (last year).

This announcement takes our relationship one step further by ensuring customers who implement the Solaris 10 Security Benchmark from CIS can receive support from Sun (under the Solaris 10 Service Plan). This is the first time that Sun has publically announced support for Solaris security recommendations (other than those documented in the Sun BluePrints program). Certainly this is a natural step that stems from our work over the last few years.

I believe that this is another great example of collaboration between vendors (Sun in this case) and members of academia, industry and government. We have all come together for the sole purpose of developing and sharing recommended security practices. By working together in this fashion, we have been able to generate more complete, consistent and supportable advice that will benefit Solaris users and administrators around the world.

This is participation and sharing in action!

Technorati Tag:

About

gbrunett

Search

Archives
« April 2014
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