OSS

Reading about the “Vulnerability Discovery and Remediation Open Source Hardening Project”—a security audit funded by the Department of Homeland Security to regularly review popular open source software (this article has more information)—got me thinking.

The article that sparked my thinking discussed how a critical flaw had been discovered in the X Window System.  This flaw was described as one of the most serious flaws uncovered to date.  The flaw was corrected quickly, as is typical of most open source projects, but it wasn’t really the flaw itself or the quick response to the flaw that really got to me.  Instead, it was the fact that someone was even able to search for such flaws.

The war-cry for open source proponents has always been, “Our software is more secure because more people have seen the code and reviewed it.”  Until now, I wasn’t so sure about that argument; after all, how many people were like me?  People who loved the projects, supported them in whatever way they could, but aren’t developers?  An ordinary guy like me can’t contribute anything significant to an open source project because I don’t know C, C++, C#, Java, Objective-C, or anything else.  The fact that I could review the code, until now, didn’t really do me any good.  Or so I thought.

Perhaps I’m just coming late to the party.  Perhaps it’s the involvement of the government, using my tax dollars, that has driven the idea home.  Either way, now I see that the very right to review the source code is what makes open source projects so powerful in comparison with closed source software.  As this DHS-sponsored project pores over millions of lines of code to find obscure bugs like the one described above, everyone (even Windows users) benefits.  As security flaws, buffer overflows, etc., are corrected in software packages such as Apache (which runs the majority of web sites on the Internet, last I checked), FreeBSD, the Linux kernel, MySQL, the Internet and our own private networks become more secure, more protected, and less likely to be used in attacks against others.  This is what the open source proponents have been so excited about, and why support for open source software is so strong.

This doesn’t mean that open source projects are automatically “more secure,” nor does it mean that we should all eschew all forms of commercial software in favor of open source equivalents.  But it does mean that we do need to strongly consider open source equivalents, especially the high-profile ones, when developing solutions for customers.  In my opinion, it would be a disservice otherwise.

Mark one up for cross-platform standards:  the OpenDocument format, an XML-based file format originally derived from work on OpenOffice.org (and Sun’s StarOffice) has been officially approved as an ISO standard.

There are numerous announcements of the approval—this eWeek article, which initially alerted me; this press release at the OpenOffice.org web site; and this blog entry by Andy Updegrove, a participant in the standardization committees.

Of course, Microsoft continues to push its Open XML format as an alternative to ODF.  The push for ODF was never really about taking power away from Microsoft, though; it was really about moving documents and records and information into a format that isn’t controlled by a single vendor.  With ODF as an ISO/IEC standard (and likely to see much broader adoption now as a result), organizations don’t have to worry about changes in file formats suddenly wreaking havoc with years of accumulated documents.  If the application(s) they use with ODF are Microsoft Office, StarOffice, KOffice, or OpenOffice, who cares?  It’s not really about the application, it’s about the data.

I’m happy to report that CentOS 4.3 appears to run just fine on ESX Server 2.5.3.  I built a CentOS server in the lab today for additional testing on the Linux-AD integration instructions with Windows Server 2003 R2, and found that CentOS appears to run just fine.

The virtual machine configuration was specified as a single CPU (I haven’t tested it with Virtual SMP) with the vlance virtual NIC and the LSI Logic SCSI adapter.

In the past I experienced problems with time synchronization inside CentOS when running as a virtual machine (described here and here).  As I have not yet had the time to test time synchronization, I don’t know if the problem will crop up again.

UPDATE:  An updated version of these instructions has been posted.

The integration of (what was formerly called) Services for UNIX into Windows Server 2003 R2 also brought some other changes.  To accommodate those changes, I’ve updated my Linux-AD integration instructions (the previous instructions are here for pre-R2 versions of Windows).  If you need to integrate Linux systems for authentication into Active Directory with Windows Server 2003 R2, these instructions should get you there.

Overall, the instructions are very similar to the instructions for pre-R2 versions of Windows.

Preparing Active Directory (One-Time)

Based on what I’ve seen so far, it appears as if a partial RFC 2307-compliant schema is included by default with Windows Server 2003 R2.  This means that it is no longer necessary to extend the schema to include attributes such as uid, gid, login shell, etc.  However, while the schema does appear to be present by default, you must install the “Server for NIS” component on at least one domain controller in order to be able to actually set those attributes (and it will be necessary to set the attributes before logins from Linux will work).

You’ll also need to create an account in Active Directory that will be used to bind to Active Directory for LDAP queries.  This account does not need any special privileges; in fact, making the account a member of Domain Guests and not a member of Domain Users is perfectly fine.

Preparing Active Directory (Each User)

Each Active Directory account that will authenticate via Linux must be configured with a UID and other UNIX attributes.  This is accomplished via the new “UNIX Attributes” tab on the properties dialog box of a user account.  Installing the “Server for NIS” component enables this, as mentioned previously.

After all the user accounts have been configured, then we are ready to perform the additional tasks within Active Directory and on the Linux server that will enable the authentication.

Preparing Active Directory (Each Server)

For each Linux-based server that will be authenticating against Active Directory, follow the steps below.

1. Create a computer account in Active Directory.  When creating the computer account, be sure to specify that this account may be used by a pre-Windows 2000–based computer.
2. Use the following command at a command prompt to configure the new computer account:

   ktpass -princ host/fqdn@REALM -mapuser DOMAIN\name$
   -crypto DES-CBC-MD5 -pass password -ptype KRB5_NT_PRINCIPAL
   -out filename

   Of course, you’ll need to substitute the appropriate values for “fqdn” (the fully-qualified domain name of the computer), “REALM” (the DNS name of your Active Directory domain in UPPERCASE), “DOMAIN” (the NetBIOS name of your Active Directory domain), “password” (the password that will be set for the new computer account), and “filename” (the keytab that will be generated and must be copied over to the Linux computer).

If you need to rebuild the Linux server for whatever reason, you’ll need to delete the computer account you created and repeat this process.

Preparing Each Linux Server

Follow the steps below to configure the Linux server for authentication against Active Directory.

1. Make sure that the appropriate Kerberos libraries, OpenLDAP, pam_krb5, and nss_ldap are installed.  If they are not installed, install them.
2. Be sure that time is being properly synchronized between Active Directory and the Linux server in question.  Kerberos requires time synchronization.
3. Edit the krb5.conf file to look something like this, substituting your actual host names and domain names where appropriate:

   [logging]
    default = FILE:/var/log/krb5libs.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log
   
   [libdefaults]
    default_realm = EXAMPLE.COM
    dns_lookup_realm = true
    dns_lookup_kdc = true
   
   [realms]
    EXAMPLE.COM = {
     kdc = host.example.com:88
     admin_server = host.example.com:749
     default_domain = example.com
    }
   
   [domain_realm]
    .example.com = EXAMPLE.COM
    example.com = EXAMPLE.COM
   
   [kdc]
    profile = /var/kerberos/krb5kdc/kdc.conf
   
   [appdefaults]
    pam = {
      debug = false
      ticket_lifetime = 36000
      renew_lifetime = 36000
      forwardable = true
      krb4_convert = false
    }

4. Edit the /etc/ldap.conf file to look something like this, substituting the appropriate host names, domain names, account names, and distinguished names (DNs) where appropriate.

   host 10.10.10.10
   base dc=example,dc=com
   uri ldap://server.example.com/
   binddn ldap@example.com
   bindpw adldapbindpw
   scope sub
   ssl no
   nss_base_passwd dc=example,dc=com?sub
   nss_base_shadow dc=example,dc=com?sub
   nss_base_group dc=example,dc=com?sub
   nss_map_objectclass posixAccount user
   nss_map_objectclass shadowAccount user
   nss_map_objectclass posixGroup group
   nss_map_attribute gecos name
   nss_map_attribute homeDirectory unixHomeDirectory
   nss_map_attribute uniqueMember member

5. Securely copy the file created using the ktpass.exe utility above to the Linux server in question, placing it in the /etc directory as krb5.keytab.  (SFTP or SCP are excellent candidates for this.)
6. Configure PAM (this varies according to Linux distributions) to use pam_krb5 for authentication.  Many modern distributions use a stacking mechanism whereby one file can be modified and those changes will applied to all the various PAM-aware services.  For example, in Red Hat-based distributions, the system-auth file is referenced by most other PAM-aware services.
7. Edit the /etc/nsswitch.conf file to include “ldap” as a lookup source for passwd, shadow, and groups.

That should be it.  Once you do that, you should be able to use kinit from a Linux shell prompt (for example, “kinit aduser”) and generate a valid Kerberos ticket for the specified Active Directory account.

At this point, any PAM-aware service that is configured to use the stacked system file (such as the system-auth configuration on Red Hat-based distributions) will use Active Directory for authentication.  Note, however, that unless you also add the pam_mkhomedir.so module in the PAM configuration, home directories will have to be created manually for any Active Directory account that may log on to that server.  (I generally recommend the use of pam_mkhomedir.so in this situation.)

This configuration was tested on Red Hat Linux 9.0 as well as CentOS 4.3.

As most readers probably already know, the proposed CheckPoint-Sourcefire acquisition deal died last week.  I’m of two minds about the failed deal.  Part of me is disappointed that the deal did not go through, and part of me is relieved.

The part of me that is sorry to see the deal fall through was hoping to see CheckPoint’s products be invigorated through the addition of technologies developed by Sourcefire.  CheckPoint’s firewall products had been top-notch, at least in the past, but they seem to have been slipping recently and the competition has been catching up and, in some cases, passing them by.  The addition of some new, exciting technology from Sourcefire may have reinvigorated the company and launched them ahead of the competition.  By the same token, the addition of extra resources (money, developers, expertise) from CheckPoint to Sourcefire may have also paid off for them, and would have (hopefully) trickled down into Snort.

At the same time, I shared the concerns of many others that Snort would have eventually lost its open source status under the direction of the CheckPoint corporate umbrella.  Snort’s primary developer, Marty Roesch, assured the open source community that this wouldn’t happen, but no one can truly tell what the future holds.  CheckPoint would certainly have lost a great deal of goodwill in the IT and security communities had such a thing happened, but many times corporations don’t care about that.

Both companies indicate that they will continue to work together, so let’s hope that the proposed benefits of this now-failed merger may still come to fruition in some form.

There’s a rumor floating around that Mac OS X 10.5 (code-named “Leopard”) will include a virtualization engine similar to that provided by VMware.  This will allow x86-based Macs running Leopard to also run Microsoft Windows and Linux on the same hardware, providing a deadly triple-play combo.

According to this article (thanks to virtualization.info for the pointer!), sources are indicating that Apple will include virtualization support in Leopard.  These rumors are supported by a patent application last year which danced around the idea of running multiple operating systems but did not specifically mention virtualization.

Now, it would be tremendously cool (and not to mention very helpful) to be able to run Windows or Linux on an x86-based Macintosh.  But will this virtualization be “full virtualization,” allowing the use of other operating systems simultaneously (such as provided by VMware), or “paravirtualization,” the ability to partition the hardware so that it supports multiple instances of the same OS (such as that provided by Virtuozzo/OpenVZ or Xen)?  I’m personally hoping for the former, and the growth of open source projects such as Q are a ray of light in that direction.  Hopefully, Apple’s support for virtualization (if such really exists) will bolster those types of efforts, not hamper them.

One of the key features in Tiger that I was looking forward to was Spotlight.  I know, I know—lots of users have complained about Spotlight’s background indexing and its impact on performance, and there’s a lot of chatter on various forums and in the newsgroups about disabling Spotlight.  I, on the other hand, was interested in having all my stuff indexed by Spotlight so that I could take advantage of the indexes (indices?) in native Mac applications such as Mail (via Smart Mailboxes), Finder (via Smart Folders), Address Book (via Smart Groups), so on and so forth.

However, Spotlight was exhibiting some strange weirdness.  I don’t know if it was related to Spotlight having already built the index prior to applications being installed, or if it was due to the fact that some of the Spotlight importers weren’t being “picked up” by Spotlight.  In either case, the search results weren’t quite right.

So, in true geek fashion, I set out to find out why.  My first stop?  The terminal, to trot out some Unix commands that manipulate Spotlight.  First, I looked up some information on mdutil, and found that I can reset the Spotlight index using this command:

mdutil -E “path/to/volume”

I didn’t want Spotlight indexing my external Firewire hard drive or my iPod, so I added them as exclusions using the Spotlight preference pane in System Preferences, then issued the following commands:

mdutil -E /Volumes/Maxtor
mdutil -E /Volumes/iPod
mdutil -E /

This reset the Spotlight index.  However, I still wasn’t convinced that all was well.  I turned next to mdimport, another Unix command, and found that you can force Spotlight to tell you which importers were installed and recognized.  Using “mdimport -L”, I found that only the importers found in /System/Library/Spotlight or in an application bundle were actually being recognized.  However, there were some importers found in /Library/Spotlight that were not being recognized.  I copied one of these importers over to /System/Library/Spotlight, and “mdimport -L” showed it as being recognized.  I copied the remaining importers over.  Another problem resolved—now all the importers were being recognized.

However, these importers hadn’t been used when the index was being rebuilt, and now i needed a way to tell Spotlight to update itself with these new importers.  Another look at the man page for mdimport showed another switch that would be useful.  So I ran these commands to fix the problem:

mdimport -r “path/to/importer”

I gave Spotlight a little bit of time to update itself, then issued a quick Spotlight query for some text I knew would be buried inside a Microsoft Office document.  The results included the document(s) I expected, which told me that things appeared to be working much better.

The only thing not working (not yet, anyway), was the del.icious Spotlight Importer (to search del.icio.us bookmarks via Spotlight).  Still need to work on that one a bit.

My favorite Mac OS X virtual desktop manager, Virtue, has found new life with a new owner.  After stalled development, Virtue is progressing on, now with full Tiger compatibility and soon to have a Universal binary so that Intel-based Mac owners can use it as well.

I wrote about virtual desktop managers on Mac OS X a while back; at that time, I was using a program called Desktop Manager and was experimenting with Virtue.  The more I used Virtue, the more I grew to like it, and was very disappointed to learn that the project had apparently been abandoned and was not undergoing further development.  Of particular concern was the fact that it had not been updated for reliable operation under “Tiger,” the latest Mac OS X version, and I was (at the time) preparing for an upgrade to Tiger.

I have since upgraded to Tiger (I’ll post a blog entry about that soon), and was preparing to go back to Desktop Manager—which did work under Tiger—when I came across an obscure comment in a blog entry that indicated a new version of Virtue had been released.  Really?  I rushed over the Virtue Sourceforge site, but sadly…no changes.  A more comprehensive Google search turned up Tony Arnold’s weblog, where development of Virtue continues.  Hurray!

After a quick download, install, and tweak of the preferences, I’m once again back up and running with Virtue after my Tiger upgrade.  If you’re running Tiger and looking for a good virtual desktop application, look no further.

There’s been a bit of an Asterisk convergence recently, or at least for me.  I’ve come across a couple of articles that share one thing in common:  the open source Asterisk VoIP PBX software.  From wireless routers to virtual machines, Asterisk is making some noise.

First, there was this article from Nerd Vittles about a prebuilt Asterisk@Home virtual machine (instead to be used with the free VMware Player, but conceivably also usable with the upcoming free VMware Server) available from vmwarez.com.  For all of us who’ve thought about experimenting with Asterisk, now we have no more excuses.  With a prebuilt VM that has already taken the tedium from building an Asterisk PBX, now all we have to do is load it up and start tinkering.  (Nerd Vittles also has a great article on the setup of Asterisk@Home 2.5.)

(Note:  Asterisk@Home is a project that combines Asterisk with the base operating system—CentOS 4.2—and a number of associated applications for easy installation and deployment.)

Then, I find this article from NewsForge about Asterisk@Home running on OpenWrt.  OpenWrt is a Linux distribution designed for wireless routers; specifically, the Linksys WRT54 series.  It’s cool enough being able to load a full Linux distribution onto a wireless router, but it’s even cooler being able to turn that wireless router into an open source VoIP PBX as well.  What will they think of next?

Remember me pining for virtualization on Apple’s new Intel-based Macs?  That day has drawn much, much closer with the release of Universal binaries of Q, a Mac OS X port of QEMU.

It’s still an “unstable” build, but with Universal binaries available for Q, we now have the option of running x86 operating systems on an x86-based Apple with Mac OS X as the host.  Sweet!  This will probably be one of the very first things I try once I get my hands on a new MacBook Pro; unfortunately, my budget being what it is (i.e., too limited for a new MacBook Pro right now), that will have to wait.  But that’s OK, as it will give the excellent Q project more time to mature and develop.