Integrating Solaris 10 BART and the Solaris Fingerprint Database

Thursday Oct 28, 2004

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: OpenSolaris Solaris security

OEM Business Forum with Sun Microsystems

Tuesday Oct 26, 2004

I have been away for a while due to vacation, customer visits and preparation for a few upcoming conferences. I will be back soon with more Solaris 10 Security information and tips. In the meantime, you will be able to catch me this week at the Sun OEM Business Forum being held in Rochester, NY. I will be presenting on the topic of designing and building secure OEM business solutions.

Others speaking at the event include:

• Colin Fowles, Director, Sun OEM Business Office
• Patrick Petschel, Director, Market Development, Nu Horizons Electronics Corp.
• Dr. Bob Sproul, VP & Fellow, Sun Labs of Massachusetts
• David Towne, Manager Sun Compliance Engineering
• Trey Talbott, Client Services Architect
• Gordie Klueber, Technical Architect, CTO Office, Sun Microsystems Labs

You can find more information on this event at:

http://www.nuhorizons.com/sun/

Special thanks to Nu Horizons Electronics, Inc. for sponsoring this event.

2004 Annual Fall Computer Security Symposium -- UNCC

Monday Oct 04, 2004

Security pros to share secrets at UNC Charlotte

As information technology has advanced, it has increasingly become the key to efficient business communication. The spread of such technologies - and the consequent reliance on it - requires a commitment to understand and minimize the threats that could compromise the facility, privacy and integrity of network data.

Leading researchers and practitioners in the fields of information security will delve into these issues and discuss solutions during the Fall Computer Security Symposium at The University of North Carolina at Charlotte. Secret Service agent Tony Marino and Sun Microsystems Chief Security Officer Whitfield Diffie are among those sharing their expertise during the October 13th program in the Cone Center's McKnight Hall. Attending cyber security professionals, including business continuity professionals, IT managers, software developers, systems administrators, information security professionals and policy makers will have the opportunity to question the experts. Registration begins at 8:30 a.m. with sessions running from 9 a.m. to 4:30 p.m.

Other top cyber security leaders to present will be:

• Kent Blossom, Director of Safety and Security Services, IBM
• Al Decker, Director, Security and Privacy Services, EDS
• Tom Fisher, CIO, Qualcomm
• Brad Ipema, Attorney, Wachovia Bank
• Kevin Kealy, Security Scientist, AT&T
• Wynn Mabry, Director, Homeland Security, Mecklenburg County
• Joan Myers, President, North Carolina Electronics and Information Technology Association
• Ed Paradise, Vice President and General Manager, Mobile Wireless Group, Cisco
• Rebecca Whitener, Director, Privacy Services, EDS
• James A. Whittaker, Associate Professor of Computer Science, Florida Institute of Technology

The symposium's sponsors include: UNC Charlotte's College of Information Technology and the university's Charlotte Research Institute, which draw on their extensive research and educational programs in computer security. The College of IT's program was recently redesignated by the U.S. National Security Agency as a Center of Academic Excellence in Information Assurance Education.

In addition to UNC Charlotte, sponsors include the North Carolina Electronics and Information Technology Association, the Information Technology Council of the Charlotte Chamber of Commerce and InfraGard.

For details & registration on this year's symposium, please visit http://www.coit.uncc.edu/symposium/2004/site/index.cfm.

---

To compliment the 2004 Cyber Security Symposium, on Wednesday, October 13th, there will also be a radio broadcast. "Charlotte Talks", a production of WFAE FM 90.7 will host Whitfield Diffie (Sun Microsystems Chief Security Officier), Rebecca Whitener (Director of Privacy for EDS) and Tony Marino (Special Agent for the Secret Service) to address certain questions regarding Identity Theft.

You can listen via the radio or the Internet at FM 90.7.

Common Criteria User's Forum

Monday Oct 04, 2004

The Common Criteria User's Forum will be held this week in Washington, DC. Specifically, the event will begin on Wednesday, October 6th and conculde on Thursday, October 7th. The cost of this event is $100 for non-government employees. For U.S. government employees, the fee is waived.

(From the web site), the goals of the forum are to:

• Recommend practical means to improve the Common Criteria processes and standards to make them a truly viable mechanism toward improving COTS product security for not only the Government, but for all customers.
• Present the opportunity for all parties to express their perspectives on the issues raised and to identify realistic means to resolve them.
• Provide an open forum to discuss and resolve the apparent differences between the views of commercial entities and NIAP.
• Develop a specific plan of action for the recommendations from the NIAP Review and the Task Force Report as well as any additional recommendations developed by the attendees.
• Begin to share Common Criteria experiences as a means of educating all stakeholders.

It looks like it will be both a fun and constructive event. I would encourage anyone interested in the future of the Common Criteria to stop by if you can. I will be moderating a session on day 2 entitled "Common Criteria Requirements for Commercial Users". This session will focus on what is needed to make the Common Critiera more relevant and appropriate for use in the private sector. It should be quite a discussion! If you are able to drop in, please say hello!

I will hopefully be getting back to my list of lesser known and/or publicized security enhancements to the Solaris 10 OS in the next day or so. Until then, thanks for reading and take care!

Solaris 10 Security Net Talk and Live Q&A

Monday Oct 04, 2004

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: OpenSolaris Solaris security

Automating Solaris 10 File Integrity Checks

Friday Oct 01, 2004

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: OpenSolaris Solaris security