Note: This file has moved to notablog.
Last month, my cousin had to start learning Unix in a hurry.
I've been trying to help him - not that I don't have plenty to learn
myself :-) - and ever since, I've been trying to think about what kind
of book I'd write, the book I keep looking for but haven't found.
Well, okay, that book is probably not possible, at least not yet,
though I may yet attempt to write it. The book I *want* is a sort of
step by step walk through the process of setting up and maintaining a
unix system, but at the same time with an emphasis on the questions
and reasoning, not on details. I might yet attempt to write something
like that, but it'd definitely be a long-term process and involve a
lot of interviewing and working with people who know more about it
than I do.
But what I have been thinking about is a sort of "orientation"
book that gives a beginner enough of an idea of what's going on that
they can begin learning for themselves. Unix is the epitome of the
concept of simple principles that when applied together give rise to
elegant complexity. Well, it's the epitome of what happens when that
concept is then left to accrete new tools and gewgaws and gimcracks
for forty years :-).
My idea for the book is to introduce this basic concept and try
to give a quick overview of each of the different dimensions in which
Unix exists, and how they come together, with pointers to further
reference & research. Here's my outline so far:
File System
i/o
streams
the concept of STDIN/STDOUT/STDERR
devices
config files
configuration languages
log files
init files
user files (/etc/passwd, /etc/group, etc...)
~user/.files (.profile, .*rc, etc)
default .files, where they live, how they're usually set up
the user partition vs. the system partition, (/home, /usr, /etc, etc)
the kernel image
configuration management tools
security and access control
Processes and Ports and Protocols
Specific system processes
Process signals
Processes that use internal ports
Environment Variables
Important User Accounts
root
postmaster
?
System admin tools
adduser, usermod
sysadmin programming tools survey (various shells, awk, sed,
make, perl, gcc, etc)
editors survey (vi, emacs and ed)
mail clients
General Notes
kernel
process/shell
user environment
applications - services
applications - user
A Minute In The Life of Linux
(narrative of a linux system starting up, then carrying out a few
typical tasks).
The introduction of the book will have to lay out a few meta-concepts.
The first concept is "This Is Complicated" and there really aren't any shortcuts. While you can give somebody the lay of the land fairly quickly, in practice it just boils down to having to learn lots of little subsystems, specialized languages, file formats, etc. There's no way around that until somebody sits down and tackles unifying all of these.
Personally, I'd love to see something like this; pick a scripting language (my money is on python, though I suspect it's more likely for some perl fanatic to do it, just to prove it can be done :-) and a data format (XML makes the most sense here - I've been using ant, a java/xml based make tool, and it's *so* much easier to understand than makefiles...). Then redesign/rewrite all of the hundreds of little chunks of a given linux distribution using python everywhere another scripting language is used, using XML everywhere you need a config file.
The second concept is abstraction, and layers of abstraction.
The third concept is orthogonality, i.e. the idea that you have different dimensions of complexity, which are not always aligned in a layer-like fashion, but might be at right angles to each other. So, for example, the complexity of a script is probably orthogonal to the complexity of the config file data format that the script uses.
The fifth concept is "shallow complexity". Essentially, some things just _are_ complex. Nothing you try to do is going to change that, they'll always be complex. Often people try to remedy the problem by slapping a GUI on top of the complexity. But you find that you now have just as much complexity, only now it's hidden, it's deep. And deep complexity is much harder to see, learn, and ultimately understand. At least with shallow complexity, you can focus your efforts on dealing with the complexity itself.
A friend is looking for a good security handbook, to hand to his subordinates to give them a basic orientation in security. There are, of course, several massive tomes out there (O'Reilly's firewall book and the classic Unix Security book, not to mention a host of supporting works like Internet Core Protocols).
Again, what's needed is a sort of handbook, a quick bootcamp. Here's my rough outline of what this would cover:
There is, of course, an introduction. The usual stuff; statement subject, purpose, scope, nomenclature and plan of attack. Also some basic concepts that will have to be covered VERY quickly and succinctly to avoid boring the reader and bogging them down in abstractions and vagueness. The key concepts I'm thinking of here are:
There is no such thing as "secure," only "more secure" and "less secure". Your challenge is finding "secure enough." Achieving "secure enough" is always about balancing the tradeoffs - both for yourself and for your attacker. Balancing them for yourself requires balancing the cost and constraints that good security imposes on you against the cost of being cracked, and the need to get things done. Balancing them for your attacker is balancing the cost of cracking your system against the usefulness of that access.
"Security through obscurity" is an old, and very stupid meme in the computer world. "Security through obscurity DOES NOT WORK" is a slightly less old, but much less stupid, meme.
The most harm that the first meme does is when it is used - all too often - to justify not fixing security problems. An even more insidious, recurring problem - still is, to this day, most notably with certain large operating system vendors in Redmond - is that when people discover a security hole and notify the vendor, the vendor's response is to try to ignore it. If the discoverer tries to force the issue, the vendor tries to suppress the discoverer.
Or, as one friend put it, "Because the discoverer is an evil hacker, who is letting other people hack these vulnerable systems, and so must be made to pay for all that damage, or even made to pay for fixing the bug."
Keeping your own profile low is an element of your own security - but these days, that's a lot less useful. Now crackers are looking for people with DSL and cable modems, so they can hijack their box and use it to launch distributed denial of service (DDOS) attacks.
Since security in a network sense is always about controlling protocols going back and forth, we need to give an overview of what these protocols are.
This might also need some elementary discussion of network basics; packets, sockets, ports, hubs, switches, routers, etc.
We assume the reader is familiar with all of these topics, but they may not be familiar with everything in these topics; the goal is to give them a glossary and enough details that they can follow the text and do their own research for in-depth purposes.
Every firewall guide I've ever read says "Now you need to figure out your firewall policy. A firewall policy is blah blah blah. You can set up a rule like foo. You can set up a rule like bar. You can set up a rule like baz." But they only give you, at most, a cursory example or two of a good policy. This section will go into practical discussions of tradeoffs, approaches, when it's best to use which, etc. Focus here is on examples with lots of background, discussion and examination, to give the reader a good grounding in how to compose their own, as well as a good cookbook to steal from.
Examples:
This covers higher level ideas; firewalls, NATting firewalls, transparent firewalls, dead drops, etc. It doesn't necessarily give detailed instructions on how to build them all - since that would include a ton of details specific to the hardware and software used, and lots of unix system administration and maybe even programming. But the idea is to give enough of the concept that a skilled admin/coder could figure out the rest (and a not-so-skilled admin/coder could laboriously work it out).
Security doesn't end when you finish setting up the firewall. Security is an ongoing fact life. This section describes good routine practices, like monitoring network and system activity, regularly analyzing your logs, monitoring bugtraq, skimming CERT advisories (they're usually slower than bugtraq, but you never know), running regular audits, educating users, evaluating new systems and software, planning, etc.
In a sense this is the simplest and also the hardest section of the book, basically a compendium of detailed, specific information about different firewall products and how to use them, how NOT to use them, gotchas to watch out for, known problems, etc.
If this gets written at all, it'll definitely be a monster job of compiling this stuff. There's no way in hell *I* could write it, but with sufficient help from folks knowledgable in the field...
There should probably be a section on tools like COPS, SATAN, Tripwire, etc.