![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Before you start
In addition to the machine on which you're reading this tutorial, you need an old Linux installation that you don't mind breaking—preferably with a rescue disk in case something goes wrong. If you have any data you might ever need to return to on that machine (even if you follow this tutorial on a different partition or on a separate drive using a multi-boot setup), you'll need to make and test a full backup of that data before you try any of the techniques described here.
From an installation or support manager's point of view, its capacity for modification is perhaps one of Linux's greatest source of problems; anyone who has been given responsibility for any kind of medium- to large-scale installation has at least looked over the edge of that precipice. Every machine may have been radically tweaked with additional applications, configurations, and installations of unknown software. This series of tutorials is for anyone who has ever wanted to painlessly manage and install such a large-scale Linux installation across an enterprise.
This tutorial expands on the groundwork laid in Part 1, which gave some good reasons for keeping Linux's propensity for customization under control and took the first cautious steps toward locking down a standard Linux distribution to prevent spurious user changes to the baseline installation. Part 2 completes the lockdown process by building a kernel that enforces use of only signed binaries that have been introduced in a controlled way to each machine that you're supporting.
In this tutorial, you learn about some of the management issues and processes that you must build up to maintain a large-scale installation of Linux machines running a kernel specially built to execute only authorized executables, each configured with the basic lockdown processes set out in Part 1. You will see how to manage the cryptographic data needed to maintain such a system in the first place and ultimately prevent the execution of unmanaged executables in your secure environment. By the time you've implemented the measures described in this series, you'll be able to configure an industrial-grade, locked-down Linux distribution that cannot be injected with applications that you have not personally audited and signed off.
This tutorial is written for Linux administrators whose skills and experience
are at an intermediate to advanced level. You should have good familiarity with
Public Key Infrastructure (PKI), especially with respect to GNU Privacy Guard
(GPG), be comfortable with a command-line shell, and possess a working knowledge
of the C programming language. Of course, you must
also have read and understood
Part 1
of this tutorial series.
To follow the steps in this tutorial, you must have
root access on a Linux machine with the ability to
reboot the computer at will and to destroy all the data stored on it. You must
have an installed compilation environment and a way to get your distribution's
Linux kernel sources and headers as well as the tutorial source code from
Part 1.
During the development of this tutorial, I used Ubuntu Linux V6.10 installed from a live installation CD, although except in the finer details, any Linux distribution you're comfortable with should be fine. If you have access to a copy of VMware and don't need to try the hardware and firmware sections of the tutorial, VMware's snapshot utility allows you to experiment more freely, because you can go back in time to a known good state if the Linux installation stops booting at any stage without resorting to a rescue disk to diagnose and repair the problem.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular tutorial tags |
My tutorial tagsSkip to tags list
Popular tutorial tags |
My tutorial tags
