Monday Jan 03, 2005

Solaris 10, SunRays, and even JDS3 Linux...

I realize that it has been a while since my last posting, so I wanted to provide a quick update as to some fun I had over the holiday break. I am planning on providing some new security content in the very near future. As an aside, for those who prefer a more structured format, the Sun BluePrints will be publishing a few of my articles (with new and updated content) later this month.

Anyway, during the holiday, I decided to tackle two things. First, I upgraded my home Ultra 10 to Solaris 10 (build 74). The installation process was completely smooth and without incident. I had everything up and running in a hour or so. With that out of the way, I then installed the (version 3.0). This too worked out of the box (or CD has the case may be) without any problems. So, in just a few hours, I found myself with an Ultra 10 with SRSS 3.0 on Solaris 10 - ready for action.

To go with this setup, I recently purchased 3 Sun Ray 150 clients. My goal is spread them throughout the house so that people can have easy access to the network using a comfortable user interface. In fact, my son, who is going to be three in a few days, is going to get one for his birthday! (Sssh! Don't tell him!)

Using the Sun Ray Server Software kiosk mode, I can give him easy access to the web content of his choosing like PBS Kids and Noggin making him have to login to a system, start a browser, etc. Quick and painless. The only thing that I needed to do beyond what I have described above was install the Macromedia Flash plugin for Solaris so that he could play some of the games at the sites above.

Now that all of that software and hardware had been tested, I turned my eyes to my laptop. I have been running beta (pre-release) versions of JDS Linux on my primary (read: only) laptop since the very first release of the software. As such, I jumped at the chance to participate in the JDS3 Linux beta program. So, with reckless abandon, I wiped my laptop and dropped down the JDS3 Linux bits. I am in fact typing up this blog entry from my freshly installed system. For those who are curious, so far so good. I installed JDS3 a few days ago and have already seen a significant improvement a number of areas including support for hardware devices. I am using a Toshiba M2 (1.7GHz, 512M, 60G, NVidia GeForce FX Go5200, 1000BT, 802.11abg).

I have it running currently using an external monitor (@ 1280x1024), but I have also been using its LCD (@ 1400x1050). Both the wired and wireless network adapters were recognized and worked out of the box. In fact, the only software that I loaded on the system (beyond what was available on the JDS disks) was the Cisco VPN client and some networking and security utilities that I use for my "day job".

Anyway, I have to run - post-break work pileup. If you have questions on any of the above, please let me know. Take care!

Glenn

Friday Nov 12, 2004

JASS & me

As many of you may know, over the last 4+ years, I have worked as the lead developer on the Solaris Security Toolkit. It has been a wild ride and a lot of fun. After supporting over 20 releases of the code however, I have decided that it is time for me to try some new things. While I am not leaving Sun, I will no longer be actively developing JASS. Instead, I will be working on a number of other new skunk-works projects that I can only hope will be as useful to our customers and as successful as JASS has been.

The Solaris Security Toolkit has come a long way from its humble beginnings as a skunk-works project. The Toolkit has grown and matured over the years and has been deployed at over 20,000 customer systems across the globe helping to secure Solaris and Trusted Solaris on the SPARC, Intel and AMD platforms. It has been integrated into a number of Sun Client Solutions and iForce offerings as well as Sun Education courses and certification exams. In short, it has become the de facto standard to hardening the Solaris OS.

More recently, the Solaris Security Toolkit has undergone a productization effort and detailed architectural review. JASS has gone a long way from just a "toolkit developed by SunPS". Today, JASS is an official project with dedicated resources for architecture, development, quality assurance, release engineering and documentation. You should start the the fruits of this effort starting with the next release of the Toolkit. Alex Noordergraaf, the co-founder and lead architect of JASS, will continue to drive the project ever forward. This is all great news and will serve to make the Toolkit even better than ever.

I will continue to work with the JASS team in a consultative capacity especially on matters of architecture, Client Solutions integration and support. As many people have in the past sent me JASS related questions and RFEs directly, I would take this opportunity to ask that you forward them to jass-feedback@sun.com so that they can be properly handled.

Lastly, I just wanted to thank all of the JASS users! Without you, the Toolkit would not be what it is today. This project has succeeded more than I could have ever dreamed. Please accept my heartfelt thanks for your enthusiasm for the project as well as your support and patience (especially for those early releases) ;-)

Take care,

Glenn

Thursday Oct 28, 2004

Integrating Solaris 10 BART and the Solaris Fingerprint Database

In a previous entry, I discussed on how you could automate the collection of file integrity information using the Solaris 10 Basic Auditing and Reporting Tool (or "BART"), Process Privileges, Role-based Access-Control and Secure Shell. Today, I would like to talk about how you can quickly and easily validate BART manifests for file integrity against the Solaris Fingerprint Database (or the "sfpDB").

Before jumping into the details, I would first like to talk about BART and the sfpDB including what they are, how they differ and how they can be used to complement one another. These are important considerations that must be understand in order to be able to use these technologies effectively.

The Basic Auditing and Reporting Tool is used to collect and compare attributes of filesystem objects installed on a system. BART collects filesystem object attributes including name, size, permissions, access control lists, UID, GID, etc. The exact attributes collected are depend on the type of object being evaluated. For a more detailed description of the attributes collected, see bart(1M).

You can run BART as many times as you like. In fact, each run of BART captures point in time information about the filesystem. Any two independent BART runs can be compared to determine if there have been any changes made to the objects being assessed. This is a great capability for detecting change. For example, with BART, you can quickly and easily answer the question: "has this file changed since yesterday"? In fact, since you can compare any two BART runs, you can select the time duration based on your individual requirements.

Regardless of the time intervals that you select, however, BART is still not able to answer the question: "is this a genuine object that Sun shipped?" This is because you need to manually perform your data collection using BART after the system has been installed. There is always the possibility (however slight) that someone or something could have changed a Sun-provided file from its default before you performed your first BART snapshot. As a result, it is important to be able to determine if the files contained in your BART manifest are genuine.

Luckily, there is another tool that you can use to help solve this problem. It is called the Solaris Fingerprint Database or sfpDB for short. The Solaris Fingerprint Database is a free SunSolve Online service that enables users to verify the integrity of files distributed with the Solaris Operating Environment. You can read more about the Solaris Fingerprint Database in the Sun BluePrints article The Solaris Fingerprint Database - A Security Tool for Solaris Operating Environment Files.

In a nutshell, the Solaris Fingerprint Database takes as input a list of MD5 file fingerprints and returns information about any fingerprints that match known files shipped by Sun. This is precisely where BART comes into play since BART collects MD5 signatures of the files that it processes. You can extract these fingerprints from the BART manifest and with some minor manipulation prepare them for submission to the Solaris Fingerprint Database, either directly using the web site interface or using the Solaris Fingerprint Database Companion tool. The Solaris Fingerprint Database Companion is a small Perl script that automates the submission process.

So, why would you want to do this? Great question! Leveraging the Solaris Fingerprint Database is very useful when you build your first BART manifest. Since this could have been done at system installation or perhaps days, weeks or months later, it is important for your to determine if you are creating a baseline from known good and genuine files. Further, this same technique can be re-applied to help resolve any conflicts that may arise from the installation of patches, for example. That way, you will know if a conflict was generated as a result of a new, genuine Sun file being installed versus some other type of change.

So, let's look at how you can implement this tip. We will use a very simple BART rules file to collect file signatures for items in the /usr/lib/nis directory. This directory was chosen arbitrarily for its relatively small size (making it more useful as an example). Any directory or set of directories could have been used here. To instruct BART to create a manifest for the files in /usr/lib/nis, we use the following command:

# find /usr/lib/nis | bart create -I
! Version 1.0
! Tuesday, October 26, 2004 (03:50:42)
# Format:
#fname D size mode acl dirmtime uid gid
#fname P size mode acl mtime uid gid
#fname S size mode acl mtime uid gid
#fname F size mode acl mtime uid gid contents
#fname L size mode acl lnmtime uid gid dest
#fname B size mode acl mtime uid gid devnode
#fname C size mode acl mtime uid gid devnode
/usr/lib/nis D 512 40755 user::rwx,group::r-x,mask:r-x,other:r-x 4166bb19 0 2
/usr/lib/nis/nisaddent F 63668 100555 user::r-x,group::r-x,mask:r-x,other:r-x 415cec73 0 2 ba94af26a1fa9dbb26ba0e2a07d888ec
/usr/lib/nis/nisauthconf F 10104 100555 user::r-x,group::r-x,mask:r-x,other:r-x 415cec73 0 2 08f50f2555553710f9eb3225ebc7a04e
/usr/lib/nis/nisclient F 38374 100755 user::rwx,group::r-x,mask:r-x,other:r-x 415cec8c 0 2 1bf5c90088933a61c0b1e9138d52b841
/usr/lib/nis/nisctl F 9816 100555 user::r-x,group::r-x,mask:r-x,other:r-x 415cec8b 0 2 fb4cade13611fb4904f06f26cc51ad8b
/usr/lib/nis/nisopaccess F 5545 100755 user::rwx,group::r-x,mask:r-x,other:r-x 415cec8d 0 2 00f19fcd403283f0510efadeafac2e66
/usr/lib/nis/nisping F 9904 100555 user::r-x,group::r-x,mask:r-x,other:r-x 415cec8b 0 2 dd928cf7778e19749b28334dfaf503b2
/usr/lib/nis/nispopulate F 33943 100755 user::rwx,group::r-x,mask:r-x,other:r-x 415cec8d 0 2 5af2053863e687464285d4892bcc4b11
/usr/lib/nis/nisserver F 38443 100755 user::rwx,group::r-x,mask:r-x,other:r-x 415cec8c 0 2 87e05dc59fd5e25f117313a3160c2c33
/usr/lib/nis/nissetup F 10927 100755 user::rwx,group::r-x,mask:r-x,other:r-x 415cec8c 0 2 8bdc76f327b86edee2c1dcafef289cb6
/usr/lib/nis/nisshowcache F 9656 100555 user::r-x,group::r-x,mask:r-x,other:r-x 415cec8b 0 2 a3d06fea784afe9ce6974cfa87dbe1d6
/usr/lib/nis/nisstat F 11056 100555 user::r-x,group::r-x,mask:r-x,other:r-x 415cec8a 0 2 63be71e1fb14121e20e95e1369d1485b
/usr/lib/nis/nisupdkeys F 18172 100555 user::r-x,group::r-x,mask:r-x,other:r-x 415cec8b 0 2 8f0fd3abbefd1ae1ef31083a18d59c18

What you will notice about this output is that the very last field is an MD5 fingerprint when the object type (column 2) is a file (type F). With this information, it is then easy to construct a command that will create a list of MD5 fingerprints that can be passed to the Solaris Fingerprint Database in a format that it will be able to recognize. Basically, we just need to select any type F (file) records and capture each corresponding fingerprint value. This can be accomplished using the simple command:

# find /usr/lib/nis | bart create -I | grep -v "\^#" | awk '$2 == "F" { print $NF }'
ba94af26a1fa9dbb26ba0e2a07d888ec
08f50f2555553710f9eb3225ebc7a04e
1bf5c90088933a61c0b1e9138d52b841
fb4cade13611fb4904f06f26cc51ad8b
00f19fcd403283f0510efadeafac2e66
dd928cf7778e19749b28334dfaf503b2
5af2053863e687464285d4892bcc4b11
87e05dc59fd5e25f117313a3160c2c33
8bdc76f327b86edee2c1dcafef289cb6
a3d06fea784afe9ce6974cfa87dbe1d6
63be71e1fb14121e20e95e1369d1485b
8f0fd3abbefd1ae1ef31083a18d59c18

Now that you have a list of MD5 fingerprints, you are ready to submit them to the Solaris Fingerprint Database. The sfpDB will only accept a total of 256 individual fingerprints at a time. In this case, it is not an issue since we only generated 12. If we had generated more than 256, which is likely for a real BART run, then we could use the Solaris Fingerprint Database Companion to process them since this tool will automatically break up the list of fingerprints into chunks of 256 and process each chunk in turn until all of the fingerprints have been processed.

So, let's see what happens when these fingerprints are submitted to the database. For the sake of simplicity, for this example, I used the sfpDB web interface which produced the following result:

Results of Last Search

ba94af26a1fa9dbb26ba0e2a07d888ec - - 0 match(es)
    Not found in this database.

08f50f2555553710f9eb3225ebc7a04e - - 0 match(es)
    Not found in this database.

1bf5c90088933a61c0b1e9138d52b841 - - 0 match(es)
    Not found in this database.

fb4cade13611fb4904f06f26cc51ad8b - - 0 match(es)
    Not found in this database.

00f19fcd403283f0510efadeafac2e66 - - 9 match(es)

        \* canonical-path: /usr/lib/nis/nisopaccess
        \* package: SUNWnisu
        \* version: 11.8.0,REV=2000.01.08.18.17
        \* architecture: i386
        \* source: Solaris 8/x86

        \* canonical-path: /usr/lib/nis/nisopaccess
        \* package: SUNWnisu
        \* version: 11.8.0,REV=2000.10.28.19.07
        \* architecture: i386
        \* source: Trusted Solaris 8/x86

        \* canonical-path: /usr/lib/nis/nisopaccess
        \* package: SUNWnisu
        \* version: 11.8.0,REV=2003.04.03.19.26
        \* architecture: i386
        \* source: Trusted Solaris 8/x86

        \* canonical-path: /usr/lib/nis/nisopaccess
        \* package: SUNWnisu
        \* version: 11.9.0,REV=2002.11.04.02.51
        \* architecture: i386
        \* source: Solaris 9/x86


        \* canonical-path: /usr/lib/nis/nisopaccess
        \* package: SUNWnisu
        \* version: 11.8.0,REV=2000.01.08.18.12
        \* architecture: sparc
        \* source: Solaris 8/SPARC

        \* canonical-path: /usr/lib/nis/nisopaccess
        \* package: SUNWnisu
        \* version: 11.8.0,REV=2000.10.30.04.48
        \* architecture: sparc
        \* source: Trusted Solaris 8/SPARC

        \* canonical-path: /usr/lib/nis/nisopaccess
        \* package: SUNWnisu
        \* version: 11.8.0,REV=2001.09.25.00.12
        \* architecture: sparc
        \* source: Trusted Solaris 8 4/01

        \* canonical-path: /usr/lib/nis/nisopaccess
        \* package: SUNWnisu
        \* version: 11.8.0,REV=2003.04.03.21.27
        \* architecture: sparc
        \* source: Trusted Solaris 8/SPARC

        \* canonical-path: /usr/lib/nis/nisopaccess
        \* package: SUNWnisu
        \* version: 11.9.0,REV=2002.04.06.15.27
        \* architecture: sparc
        \* source: Solaris 9/SPARC

dd928cf7778e19749b28334dfaf503b2 - - 0 match(es)
    Not found in this database.

5af2053863e687464285d4892bcc4b11 - - 2 match(es)

        \* canonical-path: /usr/lib/nis/nispopulate
        \* package: SUNWnisu
        \* version: 11.9.0,REV=2002.11.04.02.51
        \* architecture: i386

        \* source: Solaris 9/x86

        \* canonical-path: /usr/lib/nis/nispopulate
        \* package: SUNWnisu
        \* version: 11.9.0,REV=2002.04.06.15.27
        \* architecture: sparc
        \* source: Solaris 9/SPARC

87e05dc59fd5e25f117313a3160c2c33 - - 0 match(es)
    Not found in this database.

8bdc76f327b86edee2c1dcafef289cb6 - - 0 match(es)
    Not found in this database.

a3d06fea784afe9ce6974cfa87dbe1d6 - - 0 match(es)
    Not found in this database.

63be71e1fb14121e20e95e1369d1485b - - 0 match(es)
    Not found in this database.

8f0fd3abbefd1ae1ef31083a18d59c18 - - 0 match(es)
    Not found in this database.

You will note that a number of files show no matches in the database. Have no fear - this is due to the fact that the tests are being run on a pre-release version of Solaris 10. Once Solaris 10 officially ships, all of the fingerprints will be recorded and should show up here. You will also note that for the positive matches, the source showed up as Solaris 9/SPARC, Solaris 9/x86, Trusted Solaris 8/SPARC, etc. This is because the file is the same on each of those versions of (Trusted) Solaris including Solaris 10. Just to make things interesting, the following example shows how you can automate this using the Solaris Fingerprint Database Companion. In the following example, I will only look for files that do not match any of the records in the database:

# find /usr/lib/nis | bart create -I | grep -v "\^#" | awk '$2 == "F" { print $NF }' > ./md5.list

# cat ./md5.list
ba94af26a1fa9dbb26ba0e2a07d888ec
08f50f2555553710f9eb3225ebc7a04e
1bf5c90088933a61c0b1e9138d52b841
fb4cade13611fb4904f06f26cc51ad8b
00f19fcd403283f0510efadeafac2e66
dd928cf7778e19749b28334dfaf503b2
5af2053863e687464285d4892bcc4b11
87e05dc59fd5e25f117313a3160c2c33
8bdc76f327b86edee2c1dcafef289cb6
a3d06fea784afe9ce6974cfa87dbe1d6
63be71e1fb14121e20e95e1369d1485b
8f0fd3abbefd1ae1ef31083a18d59c18

# sfpC.pl ./md5.list | grep -- "- 0 match"
 ba94af26a1fa9dbb26ba0e2a07d888ec -  - 0 match(es)
 08f50f2555553710f9eb3225ebc7a04e -  - 0 match(es)
 1bf5c90088933a61c0b1e9138d52b841 -  - 0 match(es)
 fb4cade13611fb4904f06f26cc51ad8b -  - 0 match(es)
 dd928cf7778e19749b28334dfaf503b2 -  - 0 match(es)
 87e05dc59fd5e25f117313a3160c2c33 -  - 0 match(es)
 8bdc76f327b86edee2c1dcafef289cb6 -  - 0 match(es)
 a3d06fea784afe9ce6974cfa87dbe1d6 -  - 0 match(es)
 63be71e1fb14121e20e95e1369d1485b -  - 0 match(es)
 8f0fd3abbefd1ae1ef31083a18d59c18 -  - 0 match(es)

While this is a quick and easy way to find files that were not shipped by Sun, it would be nice to have the filename listed in addition to just the fingerprint so that we do not have to manually correlate them later. You can do this very easily by constructing the MD5 fingerprints in a slight different way (which is also readable by the Solaris Fingerprint Database):

# find /usr/lib/nis | bart create -I |\\
awk '$1 ~ /\^\\// && $2 == "F" { printf "MD5 (%s) = %s\\n", $1, $NF; }' > md5.list

# cat ./md5.list
MD5 (/usr/lib/nis/nisaddent) = ba94af26a1fa9dbb26ba0e2a07d888ec
MD5 (/usr/lib/nis/nisauthconf) = 08f50f2555553710f9eb3225ebc7a04e
MD5 (/usr/lib/nis/nisclient) = 1bf5c90088933a61c0b1e9138d52b841
MD5 (/usr/lib/nis/nisctl) = fb4cade13611fb4904f06f26cc51ad8b
MD5 (/usr/lib/nis/nisopaccess) = 00f19fcd403283f0510efadeafac2e66
MD5 (/usr/lib/nis/nisping) = dd928cf7778e19749b28334dfaf503b2
MD5 (/usr/lib/nis/nispopulate) = 5af2053863e687464285d4892bcc4b11
MD5 (/usr/lib/nis/nisserver) = 87e05dc59fd5e25f117313a3160c2c33
MD5 (/usr/lib/nis/nissetup) = 8bdc76f327b86edee2c1dcafef289cb6
MD5 (/usr/lib/nis/nisshowcache) = a3d06fea784afe9ce6974cfa87dbe1d6
MD5 (/usr/lib/nis/nisstat) = 63be71e1fb14121e20e95e1369d1485b
MD5 (/usr/lib/nis/nisupdkeys) = 8f0fd3abbefd1ae1ef31083a18d59c18

# sfpC.pl ./md5.list | grep -- "- 0 match"
 ba94af26a1fa9dbb26ba0e2a07d888ec - (/usr/lib/nis/nisaddent) - 0 match(es)
 08f50f2555553710f9eb3225ebc7a04e - (/usr/lib/nis/nisauthconf) - 0 match(es)
 1bf5c90088933a61c0b1e9138d52b841 - (/usr/lib/nis/nisclient) - 0 match(es)
 fb4cade13611fb4904f06f26cc51ad8b - (/usr/lib/nis/nisctl) - 0 match(es)
 dd928cf7778e19749b28334dfaf503b2 - (/usr/lib/nis/nisping) - 0 match(es)
 87e05dc59fd5e25f117313a3160c2c33 - (/usr/lib/nis/nisserver) - 0 match(es)
 8bdc76f327b86edee2c1dcafef289cb6 - (/usr/lib/nis/nissetup) - 0 match(es)
 a3d06fea784afe9ce6974cfa87dbe1d6 - (/usr/lib/nis/nisshowcache) - 0 match(es)
 63be71e1fb14121e20e95e1369d1485b - (/usr/lib/nis/nisstat) - 0 match(es)
 8f0fd3abbefd1ae1ef31083a18d59c18 - (/usr/lib/nis/nisupdkeys) - 0 match(es)

Using the different MD5 fingerprint format, you can now easily see those files for which a record was not found in the Solaris Fingerprint Database.

Before I stop, I did want to express one note of caution. BART can be used to tell you if a file changed between two sets of snapshots. The Solaris Fingerprint Database can tell you if a file was shipped by Sun. There is still a problem that exists and of which you must be made aware. It is possible for an attacker to replace a valid Solaris binary or library with another from an older (or unpatched) version of the operating system. While the Solaris Fingerprint Database will tell you that this is a genuine Sun binary, it may still not be a binary appropriate for the system. Due to Solaris binary compatibility guarantees, it is possible for an attacker to replace a binary with one from a previous version of the OS that may have been vulnerable in some way.

Another potential issue is that an attacker could have replaced a valid Sun binary with another. In this case, the name reported by the Solaris Fingerprint Database "canonical-path" field will differ from that passed via the MD5 fingerprint.

Both of these issues should raise a big red flag. So what should you do? When you do detect file conflicts using BART and check them out using the Solaris Fingerprint Database, be sure to take a look at the canonical path, package, version and other fields to ensure that they are appropriate for your system. You can also always take a look at the fingerprints associated with any patches you applied. Either way, you should not just let these conflicts slide as they could be an indication of a security incident or at least a change control problem.

Well, it is about time to draw this article to a close. As always, I hope you enjoyed this article and will be able to apply the tips contained within to your environment. Please let me know if you have any suggestions for any future articles. Thank you for allowing me to share this with you. Until next time, take care!

Technorati Tag:

Monday Oct 04, 2004

Solaris 10 Security Net Talk and Live Q&A

FYI... Be sure to check out this Net Talk and get your questions ready for this upcoming live Q&A session on Solaris 10 security!

Glenn

---

Sun Net Talk: Online Seminars for IT Professionals

Let's Talk --> About Security
OS Security: Solaris 10 Breaks New Ground

Keep the bad guys out; let the good guys in. No operating system does
it better than Solaris and with the upcoming release of the Solaris 10
OS, the bad guys might want to think about a new line of work. View  this
Sun Net Talk on Demand to find out how you can better protect your
software environment with the ground-breaking, out-of-the-box security
capabilities of Solaris 10. All viewers will receive early access to a  new
security white paper, discounts on selected security publications and
free security blueprints.

https://see.sun.com/Apps/DCS/mcp? q=STTW1gTFwS$vzG&eventid=652&classcode=SNTA-20040820

Got more security questions? Then register for the Sun Expert Exchange
on October 20th. It's your chance to grill our experts in a live Q&A
forum.

https://see.sun.com/Apps/DCS/mcp? q=STTW1gTFwS$vzG&eventid=652&classcode=SNTA-20040820

If you have any questions or feedback please send an e-mail to:
sunnettalk@sun.com.

Thank you,
Sun Microsystems

----------------------------------------------------------------------- ----
OS Security: Solaris 10 Breaks New Ground
----------------------------------------------------------------------- ----

View Net Talk Now
https://see.sun.com/Apps/DCS/mcp? q=STTW1gTFwS$vzG&eventid=652&classcode=SNTA-20040820

NET TALK SPEAKERS

  \* Graham Lovell
    Senior Director, Solaris Marketing

  \* Mark Thacker
    Product Line Manager, Solaris Security

  \* Paul Sangster
    Senior Security Architect, Solaris Operating System

NET TALK AGENDA

  \* Sun's Approach to Security
  \* Solaris 10 Security Architecture
  \* Trusted Solaris
  \* Certification and Services
  \* Next Steps

View now...

https://see.sun.com/Apps/DCS/mcp? q=STTW1gTFwS$vzG&eventid=652&classcode=SNTA-20040820

----------------------------------------------------------------------------

Ask Questions Later

EXPERT EXCHANGE: October 20th at 10 am PT

After watching the Net Talk, you can get any and all of your remaining
security questions answered at a Sun Expert Exchange on October 20th.
Sign up now for this hour of online Q&A with a panel of Sun's business
and technical experts.


Date: Wednesday, October 20th
Time: 10-11 am PT/1-2 pm ET

LIVE Q&A EXPERTS

  \* Paul Sangster
    Senior Security Architect, Solaris Operating System

  \* Mark Thacker
    Product Line Manager, Solaris Security

  \* Angel Camacho
    Technical Product Manager, Solaris Operating System

  \* Larry Wake
    Product Marketing Manager, Solaris Operating System

  \* Smita Thakur
    Product Line Manager, Solaris Operating System

Sign up now... 

Technorati Tag:

Friday Oct 01, 2004

Automating Solaris 10 File Integrity Checks

Well, after a short hiatus, I am back with what I hope is a very interesting and useful tip for our Solaris 10 user community. Today's tip talks about how you can automate the collection of file integrity information using Solaris Secure Shell, Role-based Access Control, Process Privileges and the new Solaris 10 Basic Auditing and Reporting Tool. This sounds like quite a bit of work, but I can assure that it is simple. Allow me to demonstrate...

New to the Solaris 10 OS is a feature called the Basic Auditing and Reporting Tool or just "BART" for short. BART is intended to provide you with a quick and easy way to collect information on filesystem objects and their attributes so that at a later point in time you can determine if there have been any changes.

BART has two primary modes of operation: create and compare. When run in create mode, BART will collect filesystem object information from a system. You can just collect everything on the system, everything under a specified root directory, just a subset of files or you can specify a more granular policy in what is called a rules file) that can be customized to meet your organization's requirements. What's more is that you can specify the rules to be read from a file or from standard input. The output of a BART run is called a manifest and it is directed to standard output (at which you can redirect it to a file, another program, etc.) The ability to read rules from standard input and produce a manifest on standard output are important points as they factor heavily in the tip that I describe below.

To use BART in compare mode, you need two BART manifests and optionally a rules file that will be used to determine how the comparison is made. The first manifest, called the control, is used as your baseline. The second manifest, called the test, is then compared against the control (in accordance with a set of rules if supplied). In many cases, it is likely that you will use a rules file to help eliminate any noise from your reports so that you can better focus your efforts.

So now that I have given you some background on the Basic Auditing and Reporting Tool, let's dive into the specifics of this tip. For customers with both large and small Solaris deployments, there is a growing need to manage cost and complexity. The goal of this tip is to highlight how the collection of filesystem information using BART can be securely automated across any number of systems (with any number of zones). Through the use of a centralized collection authority, we will be able to collect BART manifests across a network of Solaris 10 systems using strong authentication, least privilege and encryption over the wire. This allows you to then store and compare these manifests on a well-protected system (or zone) to which access can be significantly limited.

I will now describe the steps that you will need to take to implement this tip. Brief descriptions or guidance will be provided as appropriate. As a matter of convention, I will refer to the two systems in this example as client and manager. The client system is the one being examined by BART. The manager is where all of the BART rules and manifests will be stored and from where all connections to client will be made.

The first thing that we will do is create a new user on client whose only purpose is to collect filesystem information and create BART manifests. While for this example, I am only focused on a single client system, this same type of approach could be applied for a network of systems.

# mkdir -p /export/home
# useradd -d /export/home/bartadm -m -s /bin/pfsh bartadm
64 blocks
# passwd -N bartadm
passwd: password information changed for bartadm

Notice that I created the bartadm account as non-login account. This means that this account does not have a Unix login password, but is otherwise able to access the system (by using other authentication mechanisms or through the use of delayed execution mechanisms such as cron(1M)). This is necessary since the default behavior of useradd(1) is to create an account that is locked. You may also notice that this account was created with a profile shell, /bin/pfsh. This was done to allow commands executed by this user to be evaluated by the Solaris Role-based Access Control ("RBAC"") facility to determine if the command will run with altered privileges.

Now that the account has been created, we will create a Secure Shell public key that will be used to access the account. Note that this does not need to be done on the system where you created the user. In fact, I would recommend that you generate the key on manager. This way, you will not need to transfer the private key over any network.

$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/export/home/bartadm/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /export/home/bartadm/.ssh/id_dsa.
Your public key has been saved in /export/home/bartadm/.ssh/id_dsa.pub.
The key fingerprint is:
42:ca:d7:fa:ab:1c:f8:c0:5b:2c:7b:56:28:85:dc:65 bartadm@manager

Once your key-pair has been created, you should copy the public key (id_dsa.pub) from manager to client. As part of this copy, be sure to rename the file id_dsa.pub to authorized_keys Once complete, you should have something like this:

[on manager]

# pwd
/export/home/bartadm/.ssh
# ls -l
total 6
-rw-------   1 bartadm  other        736 Sep 30 23:03 id_dsa
-rw-r--r--   1 bartadm  other        600 Sep 30 23:03 id_dsa.pub

[on client]

# pwd
/export/home/bartadm/.ssh
# ls -l
total 6
-rw-r--r--   1 bartadm  other        640 Oct  1 09:14 authorized_keys

Now, while on client, we will need to make one more change. We must configure Secure Shell to only run a specific command when this public key is used. To do this, we use the command directive. For more information on this capability, see the "authorized_keys File Format" section on sshd(1M). So, at this point, edit the authorized_keys adding the following prefix to the existing public key:

command="/usr/bin/bart create -r -"

This will cause BART to be run in create mode taking a rules file from standard input. This will allow you to specify different BART rules files (as needed) without having to change the configuration of client.

The end result will look something like this (with a different public key):

command="/usr/bin/bart create -r -" ssh-dss AAAAB3NzaC1kc3MAAACBAJ6zG8SJtQVi/Et
OugyktNssLVofLmUepqsh712+D1AObTwRWZwjSH4hE423U3AcfY99u9ZxsdJ0sEpqnnvXmKaym7pMgk
NxMCPoPcnf4mAIcx9IQkpotAiCbCQ+My5lFD4iW4Nxjqh6KwIecEaABcpg2x5nhaX8Bsx0XURO/f+jA
AAAFQCD6dOAM1JunvUeCWNpXoB6tLyLewAAAIAXya1UPijNFIjymsJ0gjQXyCgll8/tORHy2vrloH7v
gh9RJ9YNRWSZZjyRvLlKTd4KFIfcjT43WlVWJKa/A7l14DGntoTS+dRh4MohJXdUjYMvV+OODc1j8V2
p+JWbbHlqDxa+zAuFEskoWNPmBrTnbLNzamIPnQ7ZaqWsbWuePQAAAIEAmqlCaMfuFYWlvDHeak79Fm
xHJjRLqmvRwlPPtkW8XDuF8wn8lj/+glWWY6/VJVtbfgteZLweotdM2wvdfXNqROiU9vvlylOdv29iA
DxsSlPGSrjXkbkNGQXMHTgPQmfbDhmtpnM6occl2R+J8dpDT59zWV7+egNZ0TTV8GNnmng=
gmb@manager

We are in the home stretch now. Next, we will create a RBAC rights profile on client that will allow the bartadm user to run BART with sufficient privileges to collect files across the filesystem. This is done to prevent the bartadm command from running as root. Remember that this account is configured as non-login and its Secure Shell public key is configured to only run the BART command. Even then, you will need possession of the bartadm private key and passphrase (which is stored on the heavily protected manager system). To do this, you will need to add the following lines to the /etc/security/prof_attr and /etc/security/exec_attr files:

# grep "\^File Integrity:" /etc/security/prof_attr
File Integrity:::File Integrity Management:
# grep "\^File Integrity:" /etc/security/exec_attr
File Integrity:solaris:cmd:::/usr/bin/bart:privs=file_dac_read,file_dac_search

Notice that the File Integrity rights profile grants the file_dac_read and file_dac_search privileges. These privileges are needed so that the bartadm user can search directories and read files that normally would not be permitted due to discretionary access controls (Unix permissions, ACLs, etc.) A description of these two privileges can be found using the ppriv(1) command:

# ppriv -l -v file_dac_read
file_dac_read
        Allows a process to read a file or directory whose permission
        bits or ACL do not allow the process read permission.
# ppriv -l -v file_dac_search
file_dac_search
        Allows a process to search a directory whose permission bits or
        ACL do not allow the process search permission.

Lastly, you need to grant the new File Integrity rights profile to the bartadm user. To complete this task, use the follwing command:

# usermod -P "File Integrity" bartadm

This command will add the following line to the /etc/user_attr file:

# grep "\^bartadm:" /etc/user_attr
bartadm::::type=normal;profiles=File Integrity

That was not too bad, right? There are certainly other things that you can do such as limiting access to the bartadm public key by hostname or IP address (for example only allowing access from manager), restricting bartadm access to cron(1M), etc. but at least you now have the basics that you need to get this working. So, let's now verify that everything works as expected from the manager system.

Before we begin, back on manager, I will create a small example BART rules file. This will be used as input to BART on the client passed over a Secure Shell channel that uses public-key authentication to executive a specific command. The output of BART will be displayed to standard output so we can redirect this to a file for later comparison. Here is the sample rules file:

/usr/sbin
CHECK all
This example will only collect information for files under /usr/sbin. When used in comparison mode, all of the collected attributes will be checked. This is just a small and simple example to verify that the functionality works. Once this is achieved, you can then begin to develop more sophisticated policies based on your organization's needs. So, let's try it out (from manager)...

$ cat ./client.rules | ssh -T -l bartadm client
! Version 1.0
! Friday, October 01, 2004 (10:46:56)
# Format:
#fname D size mode acl dirmtime uid gid
#fname P size mode acl mtime uid gid
#fname S size mode acl mtime uid gid
#fname F size mode acl mtime uid gid contents
#fname L size mode acl lnmtime uid gid dest
#fname B size mode acl mtime uid gid devnode
#fname C size mode acl mtime uid gid devnode
/usr/sbin D 4608 40755 user::rwx,group::r-x,mask:r-x,other:r-x 415c6c1d 0 2
/usr/sbin/6to4relay F 9888 100555 user::r-x,group::r-x,mask:r-x,other:r-x 414f3ef2 0 2 5dbc53336307f5caf965e4451abde647
/usr/sbin/acctadm F 28356 100555 user::r-x,group::r-x,mask:r-x,other:r-x 414f3bb4 0 2 ece9d92d00b0c13ed2d56580e3856df7
/usr/sbin/add_drv F 44244 100555 user::r-x,group::r-x,mask:r-x,other:r-x 414f3cda 0 2 10f542c2c228c2a0efdc16bc543d96d6
/usr/sbin/allocate F 18764 104755 user::rwx,group::r-x,mask:r-x,other:r-x 414f3e96 0 2 2e98bb2d02c4e87b875885dfb3838932
/usr/sbin/arp F 9912 100555 user::r-x,group::r-x,mask:r-x,other:r-x 414f3ef2 0 2 203a43e71abc9c3b9ba2a1c38647b285
/usr/sbin/audit F 10140 100555 user::r-x,group::r-x,mask:r-x,other:r-x 414f3e85 0 2 26b6e6241c6a21aab5fc1bebb816f8fc
[... content edited for brevity...]

Looks great, so let's save a two copies to illustrate how to use the compare feature:

$ cat ./client.rules | ssh -T -l bartadm client > ./client.manifest.1
$ cat ./client.rules | ssh -T -l bartadm client > ./client.manifest.2
$ bart compare -r ./client.rules ./client.manifest.1 ./client.manifest.2
$

It should come as no surprise that we get no comparison errors. While this is not overly interesting, it is a very good thing since you know your files have not changed (relative to the baseline - client.manifest.1). As an example, here is a case where the comparison detected two problems:

$ bart compare -r ./client.rules ./client.manifest.1 ./client.manifest.2 /usr/sbin/auditd: acl control:user::r-x,group::r-x,mask:r-x,other:r-x test:user::r-x,group::r-x,mask:r-x,other:rwx contents control:28dd3a3af2fcc103f422993de5b162f3 test:28893a3af2fcc103f422993de5b162f3

In this case, the /usr/sbin/auditd program was modified (contents change) and had its access control list modified - adding write access to "world". Not a very good thing ;-)

Well, that's all for today. I hope you enjoyed this article and find its content useful in helping you and your organizations better leverage Solaris 10. As always, let me know what you think! Take care. Technorati Tag:

Tuesday Sep 28, 2004

Solaris 10 Password History

Today's topic is short and sweet: password history. For those who are not aware, the concept of password history is to prevent users from repeatedly selecting the same (set) of passwords over and over again (within some fixed time window). The actual time window will depend on the configuration of the system.

Often, password history is used in combination with password composition rules and password aging. For example, an organization may prohibit user's from selecting a password that is defined in some dictionary list or one that does not meet some minimum set of composition requirements. Further, the same organization may also mandate that user's must change their password every ninety days (but no sooner than one week after the last successful change). The goal here is to require users to select strong passwords, change them regularly and limit their future reuse. Without password history, what would stop a user from repeatedly selecting the same password (or small set of passwords - or even just rotating between two valid passwords) at each password expiration event?

Password history helps to solve this issue by enforcing a policy that says that a user may not reuse any of the last n passwords (where n is defined by the organization). So, for example, by setting both password history and aging settings appropriately, an organization could prevent the reuse of passwords for a significant period of time.

So, let's talk about specifics. New to Solaris 10 is the HISTORY parameter in the /etc/default/passwd file. This new parameter specifies the number of passwords that will be remembered - and consequently compared against a user's new password to see if it had been used before. By default, password history is disabled. If you want to enable password history then you must uncomment the HISTORY parameter and assign it a value. This value will indicate the number of passwords that the system should remember. This parameter can take values ranging from 0 to 26. For example:

# grep "\^HISTORY=" /etc/default/passwd
HISTORY=10

In this example, password history has been enabled and a user's last ten passwords will be remembered. So, if I user attempts to re-use a password that is in their history, the change will be denied and the user will be presented with the following message:

$ passwd gmb
Enter existing login password:
New Password:
passwd: Password in history list.

Please try again
New Password:

Once password aging has been enabled, it can be disabled by setting the HISTORY parameter to 0 or by commenting it out in the /etc/default/passwd file. Once this is done, all users' prior password history will be discarded at the next password change by any user. Note that this is a very important point. When password history is disabled, the entire password history database will be discarded upon the next password change event by any user on the system.

In my previous posts I have tried to highlight global changes versus settings that can be applied to individual users. In the case of password history, it can only be defined on a global basis. There are no per-user settings for this feature.

Now that I have covered the basics of enabling, configuring and disabling password history, one last question may still be nagging at you - where is the password history database kept? The password history database is stored in the /etc/security/passhistory file. This file is an implementation artifact of the password history feature and is not meant to be modified by end users. This file has the following ownership and permissions:

-r--------   1 root     root          47 Sep 28 22:21 /etc/security/passhistory

Those curious enough to poke around this file will find that it contains a list of users (one per line) as well as their last n password hashes separated by a colon. For example, the above file has the following contents:

# cat /etc/security/passhistory
gmb:TRltRapbB7Eek:l5rXbTq1EJ7bQ:yEB668aaGv5z6:LgbM3LpCsERlA:

What is really cool about how password history is implemented in Solaris 10 is that it will work as you change your default password encryption algorithm using the flexible crypt mechanism (introduced in Solaris 9). For example, after changing my password encryption algorithm from the Solaris default to Blowfish, this is what happens:

# grep "\^HISTORY=" /etc/default/passwd
HISTORY=10

# grep "\^CRYPT_DEFAULT=" /etc/security/policy.conf
CRYPT_DEFAULT=__unix__

# cat /etc/security/passhistory
gmb:aMPK0ug.Syoag:Lp145TNOHmdlM:

# grep "\^CRYPT_DEFAULT=" /etc/security/policy.conf
CRYPT_DEFAULT=2a

# grep "\^2a" /etc/security/crypt.conf
2a      crypt_bsdbf.so.1

# passwd gmb
New Password:
Re-enter new Password:
passwd: password successfully changed for gmb

# cat /etc/security/passhistory
gmb:$2a$04$A.vGapPSCtbmXj3B9hYK..7fkgJqpg3YKXFoOt1T.YLBk0xw5p9E.:aMPK0ug.Syoag:Lp145TNOHmdlM:

First, I verified that I was using the default password encryption algorithm ("__unix__"). I used the passwd(1) command twice (not shown) to define passwords for the gmb account. Those password hashes were recorded in the /etc/security/passhistory file. I then changed the default password encryption algoritm to Blowfish ("2a") and changed the password for the gmb account once more. Each time I changed the password, I used a new, unique password.

Now we are ready for the real test. I will try to select each of the three passwords that are in my password history. Two of the passwords are currently stored in default ("__unix__") format and the other is stored in Blowfish format.

$ passwd gmb
Enter existing login password:
New Password:
passwd: Password in history list.

Please try again
New Password:
passwd: Password in history list.

Please try again New Password:
passwd: Password in history list.
Permission denied

As you can see, in each case, the password was recognized as having been in my password history. So, it doesn't matter if you simply use the default password algorithm or select another. This functionality will still just work. Don't you just love it!

Well, this one ran a little longer than I had originally thought, but I hope that you found it interesting nonetheless. Check back soon for another installment of lesser known and/or publicized security enhancements to the Solaris 10 OS. I still have a bunch lined up for you!

Let me know what you think of this series of articles as well as ideas for future updates. Take care!

Technorati Tag:

Monday Sep 27, 2004

Foundation for Minimal Solaris 10 Systems

The topic for this article is the Solaris 10 Reduced Networking Software Group (also commonly known as the Solaris 10 Reduced Networking Meta Cluster). This software group is new and joins the five existing software groups available in Solaris today: Core, End User, Developer, Entire and Entire + OEM software groups. The Reduced Networking Software Group is positioned as a subset of Core and represents the smallest amount of Solaris that can or should be installed and have a working and supported system. Note that for support reasons, it is not advised to remove packages installed by the Reduced Networking Software Group.

To install the Reduced Networking Software Group, simply select it from the list when doing a graphical installation. If you are using JumpStart, then you should use the cluster keyword with the new value SUNWCrnet. The following is a sample JumpStart profile that uses the Reduced Networking Software Group. This profile was also used to build the system used as an example in this article.

install_type    initial_install
cluster         SUNWCrnet
partitioning    explicit
filesys         rootdisk.s1     768     swap
filesys         rootdisk.s0     free    /
system_type     standalone

During the installation process, you will see messages similar to the following:

Processing profile
        - Selecting cluster (SUNWCrnet)
        - Selecting all disks
        - Configuring boot device
        - Using disk (c0t0d0) for "rootdisk"
        - Configuring swap (c0t0d0s1)
        - Configuring / (c0t0d0s0)

One thing that may draw your attention is the following install-time message:

Verifying space allocation
        - Total software size:  152.67 Mbytes

Yes, it's true - the size of this installation is just a little over 150-Mbytes. Note that this size is based on the build of Solaris 10 that I was using and will certainly change before Solaris 10 is finalized, but I did want to mention it as an example of how small a Solaris installation can be. By leveraging the Reduced Networking Software Group, you are providing yourself with a solid foundation on which to deploy a minimized platform. So, let's see what we have...

# df -k
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/dsk/c0t0d0s0    7929156  164697 7685168     3%    /
/devices                   0       0       0     0%    /devices
ctfs                       0       0       0     0%    /system/contract
proc                       0       0       0     0%    /proc
mnttab                     0       0       0     0%    /etc/mnttab
swap                  956144     224  955920     1%    /etc/svc/volatile
objfs                      0       0       0     0%    /system/object
fd                         0       0       0     0%    /dev/fd
swap                  955928       8  955920     1%    /var/run
swap                  955920       0  955920     0%    /tmp

By the time all is said and done, the installed system is up to 161M. At present, this accounted for about 81 packages. This default configuration includes 28 set-uid programs and 11 set-gid programs. This is all much less than what is typically installed on most systems today. As noted above, this will certainly change before Solaris 10 is finalized, so don't hold me to those exact numbers. :-)

What is actually running on this system by default on this system? To answer this question, we look at the output of ps -aef:

# ps -aef
     UID   PID  PPID   C    STIME TTY         TIME CMD
    root     0     0   0 21:52:19 ?           0:06 sched
    root     1     0   0 21:52:22 ?           0:00 /sbin/init
    root     2     0   0 21:52:22 ?           0:00 pageout
    root     3     0   0 21:52:22 ?           0:01 fsflush
    root   432   376   0 22:31:05 console     0:00 ps -aef
    root     7     1   0 21:52:24 ?           0:03 /lib/svc/bin/svc.startd
    root     9     1   0 21:52:24 ?           0:16 svc.configd
    root   394   385   0 22:00:00 ?           0:00 /usr/lib/saf/ttymon
  daemon   335     1   0 21:53:40 ?           0:00 /usr/sbin/rpcbind
    root   340     1   0 21:53:40 ?           0:00 /usr/sbin/keyserv
  daemon   279     1   0 21:53:27 ?           0:00 /usr/lib/crypto/kcfd
    root   376     7   0 21:59:59 console     0:00 -sh
    root   278     1   0 21:53:26 ?           0:00 /usr/sbin/nscd
    root    79     1   0 21:52:46 ?           0:00 /usr/lib/sysevent/syseventd
    root   411     1   0 22:00:03 ?           0:00 /usr/lib/fm/fmd/fmd
    root   367     1   0 21:59:58 ?           0:00 /usr/lib/utmpd
    root   385     7   0 22:00:00 ?           0:00 /usr/lib/saf/sac -t 300
    root   389     1   0 22:00:00 ?           0:00 /usr/sbin/syslogd
    root   395     1   0 22:00:00 ?           0:00 /usr/lib/inet/inetd start
    root   397     1   0 22:00:00 ?           0:00 /usr/sbin/cron

As you can see, really only the bare minimum. This is also confirmed by our look at those network ports that are in use as reported by netstat -an:

# netstat -an

UDP: IPv4
   Local Address         Remote Address     State
-------------------- -------------------- -------
      \*.111                                 Idle
      \*.\*                                   Unbound
      \*.32772                               Idle
      \*.514                                 Idle
      \*.\*                                   Unbound

TCP: IPv4
   Local Address        Remote Address    Swind Send-Q Rwind Recv-Q  State
-------------------- -------------------- ----- ------ ----- ------ -------
      \*.\*                  \*.\*                0      0 49152      0 IDLE
      \*.111                \*.\*                0      0 49152      0 LISTEN
      \*.\*                  \*.\*                0      0 49152      0 IDLE


TCP: IPv6
   Local Address                     Remote Address                 Swind Send-Q Rwind Recv-Q   State      If
--------------------------------- --------------------------------- ----- ------ ----- ------ ----------- -----
      \*.\*                               \*.\*                             0      0 49152      0 IDLE

SCTP:
        Local Address                   Remote Address          Swind  Send-Q Rwind  Recv-Q StrsI/O  State
------------------------------- ------------------------------- ------ ------ ------ ------ ------- -----------
0.0.0.0                         0.0.0.0                              0      0 102400      0  32/32  CLOSED

Active UNIX domain sockets
Address  Type          Vnode     Conn  Local Addr      Remote Addr
30001307e08 stream-ord 30001292a80 00000000 /var/run/.inetd.uds

As you can see, only a handful of ports are actually open by default on a system installed using the Reduced Networking Software Group. The ports open in the above example belonged to the rpcbind process (ports TCP/111, UDP/111, and UDP/32772) and the syslogd process (UDP/514). If you did not want these services running, you can disable them with the following commands:

# svcadm disable network/rpc/bind
# svcadm disable system/system-log

Alternatively, you could have also configured rpcbind to use TCP Wrappers by running the following commands:

# svccfg
svc:> select network/rpc/bind
svc:/network/rpc/bind> setprop config/enable_tcpwrappers = true
svc:/network/rpc/bind> quit
# svcadm restart network/rpc/bind:default

Certainly, you would then need to configure your TCP Wrappers hosts.allow(4) and hosts.deny(4) files accordingly. For syslogd, you could also have set the LOG_FROM_REMOTE parameter in the /etc/default/syslogd file to NO. This would have caused the syslogd process to not listen for incoming connections from remote hosts.

But I digress...

Now, since only 150-Mbytes of software was installed, it should come as no shock to you that there is a lot of other software that was not installed. This is why the Reduced Networking Software Group is a foundation for minimization. You will need to add any software packages (either manually or by defining them in your JumpStart installation profile) that you need for applications, services, management or support.

For example, let's look for some common programs and services to see what happens:

# echo $PATH
/usr/sbin:/usr/bin
# which telnet
no telnet in /usr/sbin /usr/bin
# which ftp
no ftp in /usr/sbin /usr/bin
# which rcp
no rcp in /usr/sbin /usr/bin
# which rsh
no rsh in /usr/sbin /usr/bin
# which ssh
no ssh in /usr/sbin /usr/bin
# which mount
/usr/sbin/mount
# mount -F nfs -o ro 10.1.1.100:/export/disk1 /mnt
mount: Operation not applicable to FSType nfs
# truss
truss: not found
# snoop
snoop: not found

As you can see, the Reduced Networking Software Group does not come with very much! It is precisely this reason however why it will help customers wishing to build minimal configurations. By providing a solid, core set of packages, customers are free to take an additive approach to building minimal systems by simply adding in those packages that they want or need. This approach is much improved from the typical method employed today that requires users to remove unnecessary software packages - as this approach was prone to error and often raised problems for the supportability of such configurations.

Since I believe that many people will want to have Secure Shell in their default configuration, I did want to provide the JumpStart installation profile entries that would help. If you would like Secure Shell (but do not care about tunnelling X11 connections), then you can use the following profile:

install_type    initial_install
cluster         SUNWCrnet
cluster         SUNWCssh add
package         SUNWgss  add
partitioning    explicit
filesys         rootdisk.s1     768     swap
filesys         rootdisk.s0     free    /
system_type     standalone

Well, that's all for now. Check back soon for another installment of lesser known and/or publicized security enhancements to the Solaris 10 OS. I still have a bunch lined up for you! Let me know what you think of this series of articles as well as ideas for future updates. Take care!

Technorati Tag:

Friday Sep 24, 2004

How to Limit Display of Other User's Processes

This entry is a continuation of my list of lesser known and/or publicized security enhancements to the Solaris 10 OS. In this update, I will be talking about how to restrict the output of the ps(1) command such that users can only see processes that they own. This is a very useful capability especially for ISPs and other organizations that do not want to allow users to see what other users are doing.

This new feature would not have been possible without the introduction of process privileges into the Solaris 10 OS. For a great overview of process privileges, see Casper Dik's blog entry on this topic. Be sure to read his article to get a more in depth understanding of process privileges.

So, before we begin, let's see what the output of ps -aef might look like for an average user (in this case, gmb):

$ ps -aef
     UID   PID  PPID   C    STIME TTY         TIME CMD
    root     0     0   0   Sep 23 ?           0:07 sched
    root     1     0   0   Sep 23 ?           0:01 /sbin/init
    root     2     0   0   Sep 23 ?           0:00 pageout
    root     3     0   0   Sep 23 ?           2:31 fsflush
    root   393     1   0   Sep 23 ?           0:00 /usr/sbin/auditd
    root     7     1   0   Sep 23 ?           0:11 /lib/svc/bin/svc.startd
    root     9     1   0   Sep 23 ?           0:19 svc.configd
    root   176     1   0   Sep 23 ?           0:00 /usr/sbin/syslogd
    root    64     1   0   Sep 23 ?           0:00 /usr/sbin/nscd
  daemon    91     1   0   Sep 23 ?           0:02 kcfd
    root   170     1   0   Sep 23 ?           0:01 /usr/lib/utmpd
     gmb  1795  1792   0 22:17:26 pts/1       0:00 -sh
    root  1527     7   0 00:53:24 console     0:00 /usr/bin/login
    root    82     1   0   Sep 23 ?           0:00 /usr/lib/sysevent/syseventd
   smmsp   334     1   0   Sep 23 ?           0:00 /usr/lib/sendmail -Ac -q15m
  daemon   137     1   0   Sep 23 ?           0:06 /usr/sbin/rpcbind
    root    84     1   0   Sep 23 ?           0:00 /usr/lib/picl/picld
    root  1601  1527   0 07:36:19 console     0:00 -sh
    root   181     1   0   Sep 23 ?           0:04 /usr/lib/inet/inetd start
    root   281     1   0   Sep 23 ?           0:00 /usr/lib/nfs/mountd
    root   187     1   0   Sep 23 ?           0:00 /usr/sbin/cron
    root  1402     1   0 00:26:14 ?           0:00 /usr/lib/ssh/sshd
  daemon   289     1   0   Sep 23 ?           0:00 /usr/lib/nfs/nfsd
  daemon   264     1   0   Sep 23 ?           0:00 /usr/lib/nfs/statd
    root   303     1   0   Sep 23 ?           0:00 /usr/lib/fm/fmd/fmd
  daemon   268     1   0   Sep 23 ?           0:00 /usr/lib/nfs/lockd
    root   291     1   0   Sep 23 ?           0:00 /usr/lib/autofs/automountd
     gmb  1799  1795   0 22:17:28 pts/1       0:00 ps -aef
    root  1789   181   1 22:17:19 ?           0:00 /usr/sbin/in.telnetd
    root  1792  1789   1 22:17:19 pts/1       0:00 login -p -h 10.1.1.100 -d /dev/pts/1
    root   335     1   0   Sep 23 ?           0:06 /usr/lib/sendmail -bd -q15m
  daemon   296     1   0   Sep 23 ?           0:00 /usr/lib/nfs/nfsmapid

As you can see, the gmb user can see not only his processes but also those of the root, daemon, and smmsp accounts. We can change this behavior either globally or on a per-user basis. Just as we discussed in the Solaris 10 Account Lockout entry, we can use user-specific changes to force a subset of users to comply with some policy or use the user-specific changes to make exceptions for those users. The flexibility of this format allows it to be adapted quite easily to the needs of many organizations.

For our first example, we will illustrate how the global change can be made. So do this, we must edit the /etc/security/policy.conf file, uncomment the PRIV_DEFAULT entry and set its value as follows:

PRIV_DEFAULT=basic,!proc_info

For those not familiar with the proc_info privilege, you can find more information about it using the ppriv(1) command:

# ppriv -l -v proc_info
proc_info
        Allows a process to examine the status of processes other
        than those it can send signals to.  Processes which cannot
        be examined cannot be seen in /proc and appear not to exist.

This is all that you need to do to globally configure your Solaris 10 system so that users will only be able to see processes that they own. Note that this will obviously not apply to root who by default has all privileges or to other users or processes that have been explicitly given the proc_info privilege. Regardless, it is still a very quick and effective way to limit what processes users may see.

Returning to the gmb account example, I re-login to the system and again run the ps -aef command, but this time I receive different results:

$  ssh -l gmb sampleHost
gmb@sampleHost's password:
Last login: Fri Sep 24 22:25:18 2004 from 10.1.1.100
Sun Microsystems Inc.   SunOS 5.10      s10_67  May 2004
$ ps -aef
     UID   PID  PPID   C    STIME TTY         TIME CMD
     gmb  1823  1819   0 22:30:17 pts/1       0:00 ps -aef
     gmb  1819  1815   0 22:30:14 pts/1       0:00 -sh
$

As you can see, the gmb user may now only see his own processes. Way cool. Next, to illustrate the per-user configuration ability, I will leave this global configuration in place and use the per-user configuration ability to allow the gmb user to view processes owned by other users. This is just an example of how exceptions can be implemented. The same process could be used to enable this feature for just a user or subset of users on the system.

To accomplish this task, we go back to the user_attr(4) file. In this file, we will modify the existing entry for the gmb user (or create one if one had not already been there). The following example illustrates the change that needs to be made. Specifically you need to add the defaultpriv entry to specify the default list of privileges that will be available to this user. By modifying this parameter, you will change the default set of privileges available to a user (by either adding or removing privileges as needed.) In this case, we are returning the user's default set of privileges to basic from basic,!proc_info.

gmb::::lock_after_retries=no;defaultpriv=basic

So, let's see if this really works. In the following example, we will confirm the configuration of the system, login to the system as the gmb user, and run the ps -aef command to verify that the gmb user can see processes owned by other users.

# grep "\^PRIV_DEFAULT=" /etc/security/policy.conf
PRIV_DEFAULT=basic,!proc_info
# grep "\^gmb:" /etc/user_attr
gmb::::lock_after_retries=no;defaultpriv=basic
# ssh -l gmb localhost
Password:
Last login: Fri Sep 24 22:37:55 2004 from 10.1.1.100
Sun Microsystems Inc.   SunOS 5.10      s10_67  May 2004
$ id -a
uid=100(gmb) gid=1(other) groups=1(other)
$ ps -aef
     UID   PID  PPID   C    STIME TTY         TIME CMD
    root     0     0   0   Sep 23 ?           0:07 sched
    root     1     0   0   Sep 23 ?           0:01 /sbin/init
    root     2     0   0   Sep 23 ?           0:00 pageout
    root     3     0   0   Sep 23 ?           2:33 fsflush
    root   393     1   0   Sep 23 ?           0:00 /usr/sbin/auditd
    root     7     1   0   Sep 23 ?           0:11 /lib/svc/bin/svc.startd
    root     9     1   0   Sep 23 ?           0:19 svc.configd
    root   176     1   0   Sep 23 ?           0:00 /usr/sbin/syslogd
    root    64     1   0   Sep 23 ?           0:00 /usr/sbin/nscd
  daemon    91     1   0   Sep 23 ?           0:02 kcfd
    root   170     1   0   Sep 23 ?           0:01 /usr/lib/utmpd
    root  1900  1402   7 22:42:05 ?           0:02 /usr/lib/ssh/sshd
    root  1527     7   0 00:53:24 console     0:00 /usr/bin/login
    root    82     1   0   Sep 23 ?           0:00 /usr/lib/sysevent/syseventd
   smmsp   334     1   0   Sep 23 ?           0:00 /usr/lib/sendmail -Ac -q15m
  daemon   137     1   0   Sep 23 ?           0:06 /usr/sbin/rpcbind
    root    84     1   0   Sep 23 ?           0:00 /usr/lib/picl/picld
    root  1601  1527   0 07:36:19 console     0:00 -sh
    root   181     1   0   Sep 23 ?           0:04 /usr/lib/inet/inetd start
    root   281     1   0   Sep 23 ?           0:00 /usr/lib/nfs/mountd
    root   187     1   0   Sep 23 ?           0:00 /usr/sbin/cron
    root  1402     1   0 00:26:14 ?           0:00 /usr/lib/ssh/sshd
  daemon   289     1   0   Sep 23 ?           0:00 /usr/lib/nfs/nfsd
  daemon   264     1   0   Sep 23 ?           0:00 /usr/lib/nfs/statd
    root   303     1   0   Sep 23 ?           0:00 /usr/lib/fm/fmd/fmd
  daemon   268     1   0   Sep 23 ?           0:00 /usr/lib/nfs/lockd
    root   291     1   0   Sep 23 ?           0:00 /usr/lib/autofs/automountd
     gmb  1912  1908   0 22:42:12 pts/1       0:00 ps -aef
    root   335     1   0   Sep 23 ?           0:06 /usr/lib/sendmail -bd -q15m
  daemon   296     1   0   Sep 23 ?           0:00 /usr/lib/nfs/nfsmapid
     gmb  1908  1900   0 22:42:10 pts/1       0:00 -sh
    root  1899  1601   6 22:42:05 console     0:02 ssh -l gmb localhost

It worked! That was pretty easy, right? This is just one very small example of how you can use process privileges in your daily lives. I will try to add more interesting examples of practical uses for process privileges in the future.

Before ending, I do want to highlight that while these examples focused on the ps(1) command - other process related commands will also be impacted such as ptree(1), pcred(1), pmap(1), psig(1), etc. Further, as a user running without the proc_info privilege, you will not even be able to see other processes in the /proc directory:

$ id -a
uid=101(foo) gid=1(other) groups=1(other)
$ ppriv $$
1915:   -sh
flags = 
        E: basic,!proc_info
        I: basic,!proc_info
        P: basic,!proc_info
        L: all
$ ls -l /proc
total 4
dr-x--x--x   5 foo      other        832 Sep 24 22:52 1915
dr-x--x--x   5 foo      other        832 Sep 24 22:56 1932

I hope you enjoyed this article and please watch this space for new discussion of Solaris 10 security features. Take care and have a great weekend.

Technorati Tag:

Thursday Sep 23, 2004

Solaris 10 Account Lockout ("Three Strikes!")

The next item of my list of lesser known and/or publicized security enhancements to the Solaris 10 OS is account lockout. Account lockout is the ability of a system or service to administratively lock an account after that account has suffered "n" consecutive failed authentication attempts. Very often "n" is three hence the "three strikes" reference.

Recall from yesterday's entry on non-login and locked accounts that there is in fact a difference. Locked accounts are not able to access any system services whether interactively or through the use of delayed execution mechanisms such as cron(1M). So, when an account is locked out using this capability, only a system administrator is able to re-enable the account, using the passwd(1) command with the "-u" option.

Account lockout can be enabled in one of two ways. The first way will enable account lockout globally for all users. The second method will all more granular control of which users will or will not be subject to account lockout policy. Note that the account lockout capability will only apply to accounts local to the system. We will look at both in a little more detail below.

Before we look at how to enable or disable the account lockout policy, let's first take a look at how you configure the number of consecutive, failed authentication attempts that will serve as your line in the sand. Any number of consecutive, failed attempts beyond the number selected will result in the account being locked. This number is based on the RETRIES parameter in the /etc/default/login file. By default, this parameter is set to 5. You can certainly customize this parameter based on your local needs and policy. By default, the Solaris Security Toolkit will set the RETRIES parameter to 3.

Now that we know how to define how many consecutive, unsuccessful authentication attempts we will allow, let's take a look at how you can enable the account lockout policy globally. This policy can be altered using the LOCK_AFTER_RETRIES variable in the /etc/security/policy.conf file. Just as it sounds, if you set this parameter to YES, then the account lockout policy is enabled for all users on the system (unless there is a user override which we will talk about in a minute). By default, this parameter is set to NO which means that account lockout is not enabled.

So, let's try a simple example. First, I created a test account called gmb. Next, I set the LOCK_AFTER_RETRIES parameter in /etc/security/policy.conf to YES. To see, how this feature works, I attempted to authenticate to a system (and failed) using three different services:(1) TELNET, (2) FTP and (3) RLOGIN. I failed the login attempt for each of these services (in turn) twice with the exception of RLOGIN since after the fifth failed attempt the account was locked. I ran this test from the system's console so that the log messages could be injected into the output stream to give you a better idea of what was happening. Here is the actual log of the test that was run:

# telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '\^]'.
login: gmb
Password:
Login incorrect
login: gmb
Password:
Login incorrect
login: 
Connection to localhost closed by foreign host.
# ftp localhost
Connected to localhost.
220 sampleHost FTP server ready.
Name (localhost:root): gmb
331 Password required for gmb.
Password:
530 Login incorrect.
Login failed.
ftp> user gmb
331 Password required for gmb.
Password:
530 Login incorrect.
Login failed.
ftp> quit 221 Goodbye.
# rlogin -l gmb localhost Password:
Sep 23 23:23:47 sampleHost login: Excessive (5) login failures for gmb: locking account. Login incorrect
login: 

As you can see, after the fifth attempt, the gmb account was locked. This can also be verified by looking at the shadow(4) file entry for that account:

# grep "\^gmb:" /etc/shadow
gmb:\*LK\*R12OfCMPngtJQ:12685::::::5 

You can see that the account has been locked and that a record of the number of failures is available in the last column. From the shadow(4) manual page, the last field (called "flag") stores the failed login count in the low order four bits while reserving the remainder for future use. This means that you can also look at individual shadow(4) entries and see how many consecutive failed authentication attempts have been made per user. For example, you could do the following to see how many users have had failed authentication attempts since their last successful login:

# awk -F: '$NF >= 1 { print; }' /etc/shadow
gmb:\*LK\*R12OfCMPngtJQ:12685::::::5
foo:02YZb5ZaMrcrk:12685::::::2
bar:XF0Ggjq1c6tYQ:12685::::::1
baz:.VxOG4ytNE8es:12685::::::3

If a user who has had failed authentication attempts is finally able to successfully login to the system, that user will be presented with a message like:

# telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '\^]'.
login: baz
Password:
Warning: 3 failed login attempts since last successful login.
Last login: Thu Sep 23 23:36:44 from localhost

This warning message is available for interactive login services (not FTP) and is very helpful in providing warning to users who may not have been responsible for the failed authentication attempts. It is important that you educate your users to not simply ignore these messages as they could be a symptom of an ongoing attack on their account.

Also, note that once a user has successfully authenticated to a system, the failed login count is reset:

# grep "\^baz" /etc/shadow
baz:.VxOG4ytNE8es:12685::::::

Note that the use of alternate authentication mechanisms such as rhosts or Secure Shell public key authentication will not reset the failed login count even on successful login. Should an account be locked however (either administratively or through the account lockout facility), the account would no longer be accessible even when using these alternate authentication methods. For example:

# grep gmb /etc/shadow
gmb:\*LK\*R12OfCMPngtJQ:12685::::::
# rsh -l gmb localhost /bin/finger
account expired

or for Secure Shell...

# ssh -l gmb -i /export/home/gmb/.ssh/id_dsa localhost
Enter passphrase for key '/export/home/gmb/.ssh/id_dsa':
Sep 24 00:34:59 sampleHost sshd[1504]: Failed publickey for gmb from 127.0.0.1 port 32801 ssh2
Password:

The second way in which account lockout can be configured is per-user in the /etc/user_attr file. Each user listed in the /etc/user_attr file can have an attribute defined called lock_after_retries. For a description of the format of this file, see the user_attr(4) manual page. By default, this value is set to no.

To configure account lockout for a specific user, simply add the lock_after_retries attribute with a value of yes. For example, let's assume you have an entry for user gmb:

gmb::::type=normal;profiles=FOO Security Management;roles=secadm

To enable account lockout, you simple change the above line to:

gmb::::type=normal;profiles=FOO Security Management;roles=secadm;lock_after_retries=yes

Let's take another view on this. Let's assume that the account lockout policy has been enabled globally using the method described above. You can then configure some users to be immune to this policy using this user-specific override. For example, if the LOCK_AFTER_RETRIES parameter was set to YES in /etc/security/policy.conf, but you did not want the policy to apply to the gmb account, then you only need to make sure that the /etc/user_attr file contains an entry for the gmb account that sets the lock_after_retries attribute to no as in:

gmb::::lock_after_retries=no

Here is an example of how this works. I will attempt to access the gmb account with an invalid password five times using TELNET. In contrast to the above example, the account should not be locked and no account locked message should be generated. First, let's confirm we have our system configured correctly for this test:

# grep "\^gmb:" /etc/shadow
gmb:h8HsRoqrne1oQ:12685::::::::::
# grep "\^gmb:" /etc/user_attr
gmb::::lock_after_retries=no
# grep "\^LOCK_AFTER_RETRIES=" /etc/security/policy.conf
LOCK_AFTER_RETRIES=YES

Now, let's see if the account actually gets locked after 5 failed authentication attempts.

# telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '\^]'.
login: gmb
Password:
Login incorrect
login: gmb
Password:
Login incorrect
login: gmb
Password:
Login incorrect
login: gmb
Password:
Login incorrect
login: gmb
Password:
Login incorrect
Sep 23 23:51:46 sampleHost login: REPEATED LOGIN FAILURES ON /dev/pts/1 FROM localhost, gmb
Connection to localhost closed by foreign host.
# grep "\^gmb:" /etc/shadow
gmb:h8HsRoqrne1oQ:12685::::::

Just as expected, the gmb account is immune from the account lockout policy that applies to other users on the system. This is in fact what is implemented by default for the root account. That is, even if account lockout is enabled globally (which is not the default), the root account is still immune from being locked out. This is done to prevent a malicious user from locking the root account out of the system. If you would like this policy to apply to the root account, then simply change the value of the lock_after_retries parameter to yes in the /etc/user_attr file.

This concludes another installment. As always, I hope you find this information useful in understanding how some of the new Solaris 10 security enhancements work and how they can be applied to solve real-world problems in your environment.

Technorati Tag:

Tuesday Sep 21, 2004

Managing Non-Login and Locked Solaris Accounts

Today's entry will focus on enhancements to the passwd(1) command to better support the distinction between locked and non-login accounts. Specifically, we will be looking at the new -u and -N options to the passwd(1) command as well as how they relate to the much older -l option. These new capabilities will help administrators obtain better control over how their accounts are accessed and how they can in fact manage those accounts. In the past, some of the interfaces discussed below could only be achieved through manual editing of password files. The addition of these new command line options provides a much safer option for administrators to use.

While the distinction between non-login and locked accounts has existed in Solaris for many years, it became more pronounced in Solaris 9 where the semantics of locked accounts were more rigidly enforced.

Many customers noticed, for example, that locked accounts could no longer execute jobs using cron(1M). This problem was exacerbated by the fact that many commonly referenced security recommendation guides tell users to lock all of the accounts to which interactive access was not needed (which is most of the default accounts). When this was done, cron jobs for accounts such as "sys" (used for collecting system activity records) stopped working. This problem highlighted the intended difference between non-login and locked accounts and the need for additional interfaces to control them.

For those not already aware, a non-login account is one that must exist on the system (to provide a UID for example) but should not be allowed to login to a system interactively. That is, while a non-login account may be able to leverage delayed execution mechanism such as cron(1M), they cannot access the system using login(1), telnet(1) ftp(1), ssh(1), etc. Accounts that are non-login will have the token NP as their password. You can also identify non-login accounts using the passwd(1) command:

# passwd -s daemon
daemon    NL
# grep "\^daemon:" /etc/shadow
daemon:NP:6445::::::

In this case, the daemon account has been configured as a non-login account.

A locked account on the other hand is one that is not permitted to access the system in any way - it is locked. A locked account differs from one marked as non-login in that locked accounts are not permitted to use delayed execution methods like cron(1M). Locked accounts are those whose password string has the prefix \*LK\*. Further, you can identify locked accounts using the passwd(1) command:

# passwd -s listen
listen    LK
# grep "\^listen:" /etc/shadow
listen:\*LK\*:::::::

In this case, the listen account has been locked.

Here is a practical example. In this case, I will add a new account gmb to the system. By default, new accounts created using useradd(1M) are locked. After assigning a new password, I will demonstrate the use and result of the new -N and -u options to the passwd(1) command in addition to the -l option which has been around for ever.

First, let's create a test account called gmb. You will notice that by default the account will be locked.

# useradd -d /export/home/gmb gmb
# passwd -s gmb
gmb       LK

Next, a password will be assigned to the gmb account in the usual way using the passwd(1) command...

# passwd gmb
New Password:
Re-enter new Password:
passwd: password successfully changed for gmb
# passwd -s gmb
gmb       PS
# grep "\^gmb:" /etc/shadow
gmb:Onk28eSYhYJ8s:12683::::::

You will notice that the "passwd -s" command now returns the keyword PS for "password set". If the account did not have a password defined, the keyword NP (for "no password") would have been returned.

Now that we have a password, let's lock the account and see what happens to the password string in /etc/shadow as well as to the output of "passwd -s":

# passwd -l gmb
passwd: password information changed for gmb
# passwd -s gmb
gmb       LK
# grep "\^gmb:" /etc/shadow
gmb:\*LK\*Onk28eSYhYJ8s:12683::::::

You will notice that the account was in fact locked, but what is new in Solaris 10 is that the password string is not replaced with the "\*LK\*" value. Instead, a "\*LK\*" string prefix is prepended to the password so that the original value can be kept if desired. The great thing about this is that it does not depend on the password algorithm used. With the addition of flexible crypt in Solaris 9, you can replace the default crypt algorithm with either others provided by default in Solaris or one of your own and this new locking mechanism will still just work.

To unlock a locked account, you just use the new "-u" option to the passwd(1) command:

# passwd -u gmb
passwd: password information changed for gmb
# passwd -s gmb
gmb       PS
# grep "\^gmb:" /etc/shadow
gmb:Onk28eSYhYJ8s:12683::::::

The account is now unlocked and the "\*LK\*" prefix has been removed from the user's password string. The last thing that we will look at today is how you create a non-login account. To do this, simply use the "-N" option to the password command:

# passwd -N gmb
passwd: password information changed for gmb
# passwd -s gmb
gmb       NL
# grep "\^gmb:" /etc/shadow
gmb:NP:12683::::::

You will notice that the user's original password has been removed and replaced with the string "NP". This account is now a non-login account and the original password has been discarded. You will not be able to login to this account, but the account will be able to make use of delayed execution facilities. To re-enable an account for interactive logins, simply reassign a password to the account using the passwd(1) command.

That's all for this installment. I hope you find this kind of information useful. In future installments, I will continue to highlight some of the lesser known enhancements that contribute to Solaris security in the hopes of raising awareness and their use.

Technorati Tag:

Monday Jul 12, 2004

What happened to JASS?

The Solaris Security Toolkit or just JASS for short is a flexible and extensible collection of scripts that are used to enhance, maintain and audit the platform security posture of the Solaris Operating Environment.

Version 4.0.1 of the Toolkit was released quite some time ago (around February 2004), and I just wanted to provide an update for those that may be interested...

A lot of development and quality assurance work has been put into the next release of the Toolkit. This was done to include more functionality based on customer and SunPS needs as well as to help ensure that changes made by JASS were supportable. A lot of effort also went into a testing cycle that uncovered a number of bugs and inconsistencies that have since been fixed. In all, the next release of the Toolkit should be one of the best ever published.

To give you an idea of some of the changes that have been happening, I will include a few bullet points as a teaser. As always, your feedback is always requested using the methods outlined on the JASS home page.

  • All of the Toolkit software has been updated to allow for localized versions of the Toolkit. At this time however only English is provided. If you are interested in a localized version of the Toolkit, please send us your feedback.
  • The Toolkit includes very preliminary support for the Solaris 10 OS. This means that JASS will run on Solaris 10 (as well as in a zone), but it is not complete nor officially supported at this time. Other Solaris 10 enhancements include support for the new Reduced Networking Meta-Cluster, support for new services added to the OS, use of MD5 fingerprints for file checksums, etc. More changes to support Solaris 10 will follow as that software continues its march to release.
  • The Toolkit includes better support for both Solaris on Intel/AMD as well as Trusted Solaris 8.
  • All of the Toolkit software includes better sanity and consistency checks. This is especially true for command line parsing and several of the JASS helper functions like add_to_manifest.
  • All Toolkit commands provide consistent return values now on exit.
  • Many of the auditing functions were enhanced to support multiple arguments allowing a single command to check multiple items.
  • nddconfig now supports loose checking of settings. It will report either an exact match, a loose match or a failure. This allows sites with stronger ndd configurations to still pass nddconfig audit checks.
  • Column widths are adjustable when using JASS in audit mode with verbosity <= 2.

... and much, much more including many other fixes and enhancements...

The Solaris Security Toolkit development teams looks forward to your feedback concerning what you like, don't like or would like to see included in a future revision of the Toolkit. We hope to have a new release of JASS soon - although we cannot provide a date at this time.

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