Jonathan Zdziarski's Domain

Examining the unique quality of each new major release of a Microsoft product, I’ve come to ask wonder just how Microsoft manages to organize and keep up with their product release schedule. After much thought and reflection into their products, I believe I’ve finally been able to crack the methodology used in planning and Q/A. The strategy appears to be a four-step hybrid process which I have outlined below.

Something Old
The core of most major releases from Microsoft appear to contain mostly older code from previous releases. This is evidenced by the continuity of many well known bugs reported over the years, which help to ensure a sense of friendly familiarity with their customers. Product continuity is important, so you can’t just go releasing new software unless it is primarily made up of old software.

Something New
A shiny new splash screen, set of buttons, or a new menu option can usually be found to distinguish the old version from the new version. Naturally, something has to be updated in order to warrant a new major release. Since none of the codebase has effectively changed, the skin is crucial to passing off the illusion of a new major software version.

Something Borrowed
As we see by the large number of lawsuits against Microsoft, no new major release would be complete without “borrowing” a concept (or even source code) from another piece of software. Sprinkling the new distribution with one or two stolen ideas from a competing product helps to make it appear innovative and cutting-edge. In fact, in many cases, the borrowing of technology can even lead others to believe that it is the competing company doing the borrowing.

Something Blue
What major Microsoft release would be complete without a blue screen of death upon running the software. So much work has gone into the new release that you can expect there will be a limmited number of bugs that need to be ironed out. Usually, a service pack will be released to fix these blue screens within the first 24 months of the new version’s release, thanks to Microsoft’s speedy update schedule.

There you have it! That wasn’t so hard to figure out, was it?

Table of Contents
Part I: Introduction to Chrooting

• 1.1 What is chrooting?
• 1.2 When is it appropriate to chroot?
• 1.3 Can all daemons be chrooted?
• 1.4 Will chrooting affect my users?
• 1.5 What is entailed in chrooting?

Part II: Requirements gathering

• 2.1 Can we chroot this daemon?
• 2.2 An Introduction to truss, lsof, and ldd
• 2.3 Determining datafile dependencies
• 2.4 Creating a datafile strategy
• 2.5 Determining library dependencies
• 2.6 Finding a good home for the jail

Part III: Setting up a chrooted environment

• 3.1 Creating an empty jail
• 3.2 Copying program and datafiles, configuring cron
• 3.3 Copying libraries
• 3.4 Creating devices
• 3.5 Altering startup scripts
• 3.6 The Final Product
• 3.7 Logging through syslog

Part IV: Advanced Topics

• 4.1 How to tell if you’re chrooted
• 4.2 Breaking out of a chroot()ed cell
• 4.3 Frequent chroot() mistakes

(more…)

If you’re going to allow someone to come in and hack your system, at least make them work for it.

(more…)