Checking our Amazon affiliates account, it looks like about 70 products were ordered on the day this slashdot review was published. I can't see actual monetary amounts until the items are shipped, unfortunately. But based on last quarter's average of $2.78/item, that means we'll be sending about $200 to the EFF for that day alone.
Also, I'd like to thank Alex Lewin who didn't buy through our links, but wrote:
Your book sounds good, and relevant to what I do (Linux adminstration and development). I'm planning on buying it. Without looking too hard, I found it for $24.91 on Y! Shopping.
The context of this thread is for my proposed
Windows vs Linux Security Challenge which is meant to model what a normal user would need to go through to create a secure install from scratch. Sure, I can set up a very detailed list of packages and specific application configuration for a big web farm and install with kickstart. I could even set up a disk and clone it with 'dd' and a few shell scripts to change IP addresses. But that's not going to help teach new Linux users what the securing process looks like.
So I do not dissagree with you -- your solution is definately optimal for creating lots of good machines -- but the goal was to show how to install and secure one machine in a standalone environment with a set suite of server software.
As to the actual time I'd take to do the install and lockdown, I think 2 hours is plenty, given the proposed packages that must be installed and configured:
Including the (secured) operating system itself, the final server configuration must support (as secure as possible)
A Web Server, preferably with dynamic-content generating capabilities, such as ASP or mod_perl. No documents need be installed, however all default-install documents/programs must be deleted. In other words, every possible request should return a 404.
Anonymous FTP Server (read-only)
Mail Server (able to accept email for itself and send to other Internet machines)
DNS Server (able to act as a primary for 'OS.example.com' and as a cache for the local network)
Firewall rules that allow only the above protocols, and any other packets necessary for system administration and normal functionality. (Inbound SSH, DNS Replies, etc.)
The software I'd probably choose would be Apache (mod_perl), DJB's publicfile for anon FTP access, Postfix for the mail server, and DJBDNS for the DNS server/caching server.
Now that 2 hours includes keeping a log of what I'm doing, or at least explaining it to someone who can keep a good running log, includes download time of updates (like I said, this should be like an end user, so the packages should be out of date on the install CD) and time to go get and consume a grande non-fat extra carmel carmel macchiato from starbucks.
In short, yes, the donation will apply to any books that get credited to our affiliate accounts. You can go through the book links on any of the following sites:
Hacking Linux Exposed
The book that caused yet another "Hacking" vs "Cracking" thread on Slashdot. I apologize.
Building Linux VPNS
A book by Oleg Kolesnikov and I, reviewed on slashdot last year, other reviews here.
Open Source Web Development with LAMP A top-notch web development book by James Lee (co-author of HLE and HLEv2) and Brent Ware. I tech edited this book, and also benifited from it in a user capacity, for example setting up the handler that controls access to the auto linux hacking software.
Going through any of those links will work. If you prefer, you can just send money to the EFF directly and cut out the middle man.
Why not plug your books in your sig? Or indirectly, you could just link to this/. review. Lots of people do it, and I haven't noticed anyone who minds.
In my email program (mutt), I have a perl script pick randomly from ~800 different signatures. (Most new additions seem to be from the "witty comments from my daughter" category.) The script must have some sort of AI in it, because it freqently picks things that are relevant to the text. Having just a static signature for/. seems less interesting. Manually changing it certainly more work than I'm up for.
I don't want folks reading my/. posts and thinking I'm just writing them to have my sig get more notice. I don't want folks seeing my posts and assuming that they has more or less relevance because of the info in the sig. If folks want to see who I am, it's easy enough to click on my home page or/. area.
And I am very very bad at self promotion. Anything I'd write for a sig would sound pompous.
I'm really glad that you're donating money to the EFF. There are just too many people who simply don't put their money where their mouths are.
I don't have the time, energy, or know-how to do what the EFF does. But they seem to fall on the same side of every issue that I do. So I do the best I can - send them cash. Now if only we could fund EFF as well as some corporations fund lackeys on capitol hill.
I make it a rule never to make any public comments about books that could be considered 'competition'. If I were to say they're bad, you'd not know if I were being honest or devious. If I say they're good, then OMH can get on my case for "allowing my name to be associated with competing works, blahblahblah".
Unfortunately, I bet even "complementary" books could be considered "competing" in the minds of lawyers, so I stay away from talking about books that could be considered competition, even if I don't agree. So that's why you won't see me commenting about RWLS, for example, though I will comment about non-RWLS topics in that thread.
However, yes, when writing the joke above (it should be moderated "funny" not "informative, for goodness sake!) I did have a very specific book in mind after which I modeled my list, and of course I can't say what it was.
And no one has guessed my/. password. I don't even know it. I use the terribly insecure 'bookmark this link' method. If anyone guesses it, I'm screwed. Call me lazy, but I prioritize what should be super secret and what's not worth the effort.
I didn't even notice that the price increased until right now. I have nothing to do with the price of the book. I have no idea how they set it. Maybe the higher price means we will make minimum wage for our troubles this time...
In actuality, there are about 200 new pages, since we cut out a lot of older stuff, condensed things that are not as relevant that still deserve a good nod, and put the original three case studies online instead.
Chapter 10 grew to be three chapters all told. Chapter 11 needed to be split because it was too big for both Mail and FTP in one chapter. We covered many new attack methods and tools. Everything grew substantially, in spite of trimming out the old and tightening up what we had.
And we fixed a bunch of errors and added completely new ones.
Everything in HLEv1 is still valid. If you own the first, I'd suggest you compare the contents of the two books to decide if you want it or not. Or browse it at the store. Unfortunately, the sample chapter is again chapter 1, which is one of the least modified chapters, so it doesn't give you the best indication of what's new.
This is my best stab at a response. I am so much not a marketing guy, I'm a geek.
We set up amazon and barnes and noble afilliate accounts. If books (be they HLEv2 or others) get credited to us through that, those are the monies that get donated to EFF. To do that, you need to click on the links on our books page and add it to your cart from their. Amazon also credits books purchased if you came from our site originally, even if you didn't see them on our page.
For the last quarter I think we got $150 from Amazon and about $10 from B&N which we'll be sending to EFF. Not much, but it's a good way to funnel money their way. I particularly like the irony of having Amazon, creators of some pretty questionable patents, paying EFF.
An even better way to support the EFF is for you to find the cheepest copy of HLEv2 you can get at a local book store (save on shipping) and then donate the difference to EFF directly. Or don't get HLEv2 and send the whole schebang to EFF.
No, I'm not affiliated with them, other than being a paying member, but I endorse them. And some day I may need them to defend me, given that HLEv2 can be considered a tool that could be illegal under the DMCA.
Any well-featured Linux distro is not secure unless it ships with everything off, which is seldom the case. This is a big beef of mine, but it's getting better over time. It's an ease-of-use vs security situation. You install Apache, the distro assumes that you want to run it, so it sets up the links in/etc/rc?.d and/etc/init.d so it runs. So, there's no real difference between Linux (speaking generically of all distros) and Windows here.
However the process of hardening them is very different. I bet I can install Debian with minimal packages and achieve all the functionality I claim within an hour or two, with one reboot just to make sure it would come up correctly if it's out in a remote datacenter somewhere.
But that's really no the point - I'd like to see good explanations of what's needed to secure both. It's not just a competition to say Linux is easier/faster to secure (though I suspect that would be the consensus.) It's a way to create more documentation for everyone, Linux and Windows users. In that respect, it's more noble than just a pissing contest.
If I ever got off my butt and tried to actually make the thing happen.
Ok, I don't use sigs or anything to plug my books. I like to be a normal/. person. But in case you're suspicious (you probably have a good future in computer security...) I'll post my/. id to our website so you know it's me.
Yes, HLEv2 is a complete rewrite of the original. Instead of adding new content and updating old things, we decided it'd be much faster for us to scrap everything we had. Instead we have code listings of the following, cut and paste from the original source:
WU-FTPD versions. All of them.
BIND. Only the ones that have had critical bugs. (About half.)
A complete copy of/etc/services, uncommented, in case you don't have your Linux machine around at the time.
A chapter on security problems when writing Pascal code, cribbed from something on USENET from 1983
A complete byte-by-byte deconstruction of an shttp session, explaining exactly how it works. (And yes, I mean shttp, not https)
A copy of the Linux tulip ethernet driver code, for no aparent reason.
We decided that this sort of content would provide the quickest time-to-market without any need to tech edit. By providing 0% useful information, it should be able to be read in whole as fast as you can turn the pages - no reading required. We found that people were not able to read the reviews on slashdot in their entirety, so why should we expect them to read ~700 pages about Linux Security?
I disagree. If the book were filled with "Here's how to break into wu-ftpd version x.y.z, it would be pretty useless. I'd hope that by the time the book was in print, a new version of the software would have been written that fixed the problem. A book that simply lists one crack after another for their own sake is not helpful.
However if you show different types of attacks as a teaching tool -- "Here's how an off-by-one error in OpenSSH caused it to be exploitable" for example -- then you can show different classes of attacks so the reader understands the actual problems that occur in many different software products.
The goal was to show different kinds of vulnerabilities as explanation. Anyone who is still running older buggy software isn't maintaining their system properly. (And yes, we cover how to upgrade packages in great depth.)
On the other hand, sometimes the problem is configuration: I can have a perfectly secure OpenSSH version, but if I ssh to an untrusted host with X11 forwarding on, the X11 server on my client is easily compromised. No new version of OpenSSH will fix this, it's an inherent problem with the all-or-nothing nature of X11. So configuration-based vulnerabilities do stand the test of time.
I'd never just write a book with a list of BIND vulnerabilities that are based on bugs in the source code, but problems with the DNS protocol itself (it's easily spoofable, leading to MITM attacks) are fair game for in depth coverage.
So, version-specific attacks are only covered if they help teach a concept. Configuration-specific attacks are covered if they are likely to stand the test of time. Protocol-related vulnerabilities (FTP bounce attacks/etc) are fair game until the protocol is destroyed with a big huge mallet.
In a recent slashdot post (I forget where) there was a reference to a Customizing Mozilla page that has a bunch of cool tricks to add to your user.prefs, etc. One of the things they noted was the problem with bad Arial fonts being installed on your machine. Here are the relevant snippets:
Various Linux distributions have problems with fonts; in particular,
Arial, used in many web pages, may map to a font that looks blocky
and is smaller than the requested size.
A full discussion is in
bug 46415,
but an easy solution for Redhat users is this:
mv/usr/share/fonts/ISO8859-2/usr/share/fonts.ISO8859-2
and then log out of X and log back in again.
You can always undo this, if necessary, with the command:
Or, add things like this to user.js in your.mozilla/.... directory:
// X font banning: see bug 104075. // Ban all arial fonts, because abiword installs an ugly one // and there doesn't seem to be a good one available:
user_pref("font.x11.rejectfontpattern", "fname=.*arial.*");
// Some alternate forms for rejectfontpattern: //"fname=.*arial.*;scalable=.*;outline_scaled=.*;\ // xdisplay=.*;xdpy=.*;ydpy=.*;xdevice=.*"); // "fname=-zz-abiword.*;scalable=false;outline_scaled =false;"); // Alternately, reject font if accept pattern does not match it: //user_pref("font.x11.acceptfontpattern", ".*");
Set restrictions on a system call level
on
Systrace for Mac OS X
·
· Score: 5, Informative
UML creates a new complete kernel running inside your machine, with it's own/sbin/init process, and the whole schebang. If you want to have apache in here, that's possible, you just need to copy all it's files into the UML's filesystem, set up your host machine to relay the packets in, and other similar setup. Takes a while, but totally doable.
Systrace on the other hand lives inside your normal kernel - you don't run any virtual machines at all. However systrace can decide what system calls a program can use, and if desired limit how they can be called. For example you could say Apache is allowed to create a bound socket to port 80, but no other port. You can say allow it to read files in/var/www/htdocs but nothing else. This means that should some user make a symlink to/etc/passwd, it can't be read. Should someone get Apache to run shellcode, it can't run/bin/sh or open a new network socket for inbound access.
The configuration to do this is rather extensive, but anything that will be expicit must be. See
the sample apache config for example.
Systrace works similarly to other kernel hardening patches, such as GRSecurity or LIDS. LIDS for example can lock down access to the filesystem (read/write/nada) and to root permissions (allow root to read non-root files, dissallow socket binding, etc) but this is different in that the systemcalls themselves have been hooked, not just some common access methods.
But I still degress, the user-land tools and their common-practice installation without fine-grained permissions is what kills many secure systems. All someone needs to do to exploit a system is telnet or ssh with a valid account name and password and the intruder has all the options of the system to their disposal. We have User, Group, Other, what else?
In vanilla 2.2 and 2.4 kernels, you don't have any additional kernel level controls (not counting filesystem controls, such as ext2/ext3's extended attributes, (chattr +i filename to make filename unchangeable, even by root, for example)) but you are effectively correct. However there are user-level tools you can use, such as libsafe and stackguard that can prevent many common attacks such as generic buffer overflows.
However there are various patches to the kernel that can provide much more finely tuned control of software. LIDS, GRSecurity, SELinux, and more can allow you to say exactly what a process can or can not do. By creating good rules for the software you need, you can effectively make root no more special than any other user. Only Apache can bind port 80, and no other port. Only ntpd can change the system time - not even root using 'date'. When you create an explicit list of what can do what (easiest by locking everything down and then adding permissions back in where needed) you will have a machine where a piece of software that is compromised only means it can function as it was built to - it has no new functionality it can abuse.
Now kernel patching is intimidating for many, whic h keeps them from trying these advanced security measures. However a new infrastructure is under development which can make this much simpler to use.
LSM, the Linux Security Module, has been accepted into linux 2.5 kernel, and it allows you to load or unload advanced linux kernel security systems at run time without the need for kernel recompilation. (This requires that an LSM version of the patch exists, which is the case with LIDS, GRSecurity, SELinux and friends.)
As these are more visible, they will become more mainstream. Debian has an SELinux installer, for example, which can let you boot a very secure version without compiling anything on your own.
Advanced linux security is here today if you want it.
Decrease the TTL of the DNS records during the switchover. If your current TTL is a day, then at least one day earlier, change it to, say, 300 (5 minutes). You'll experience a higher DNS query rate during that time, but probably nothing you can't handle. (You'd handle it better if you used DJBDNS though.)
Then when you're done moving a machine, change the IP in DNS. When it seems solid, you put the TTL back to a reasonable (1 day) number.
During the transition, you can also keep a machine at the old IP address and forward the services to the new IP address using tools such as rinetd or xinetd. This assures that you have all traffic going to the correct machine (possibly through the old machine) but that the old IP address is available during the move for clients that have broken DNS resolvers that don't correctly honor DNS TTL values. The rinetd/xinetd purpose machine can easily be a temporary box, such as a laptop - it's not doing any real processing.
If you're also moving your DNS machines, move one a week before the big move, update whois, and make sure everything settles down. Then move the other a day or two after the big move.
Here are my thoughts to show some visually-recognizable Linux features:
X11 forwarding.
Put a machine (server) with no screen on one end of the desk. Put a desktop on the other. Show how easy it is for the desktop to "ssh -X" to the server and run gui programs on the server with the display on the desktop. Explain how useful this would be to have a bunch of very underpowered desktops with a powerful server and still have everyone able to do all their work. And the files are all on the server, making backups easier. etc.
VNC
Similarly, get a very low powered desktop (running linux or windows) and run vncviewer on it, and vncserver on the server. Each person has fast CPU of the server, viewed on piddly clients.
User-Mode-Linux
Show how you can run Linux within Linux to do fun things like test software without the possibility of crashing your actual machine, run suspicious applications in a sandbox-like environment.
I have been in almost exactly the same position you find yourself. Mike Trojnara, who was (and again is) the developer of Stunnel fell off the face of the Internet for a while back in 2000, and there were several problems that I discovered in the code during his absense. The machine running it was no longer under his control, and eventually dissapeared alltogether, so I took all my archives and started creating new versions. To make it obvious I'd taken over, aside from being blatant about it on the mailing list (which was still working) I labeled my versions differently - 3.8p1 instead of 3.9, for example. Eventually Mike found his way back onto the net, and I promptly and happily handed the developer's sword back to him. His next version was build directly from my latest version (though he later removed the 'goto' I put in there just because I could.)
I had always planned on giving it back to him if he wanted it (I wasn't comfortable developing crypto code here in the US at the time - my rights were still very vaguely defined at the time) so in my experience it went off without a hitch, and there was no fork, just a smooth transition from one to the other.
If you want to continue maintaining it, and are releasing it under the GPL (which I assume you must), there's no reason the original author can't fork off yours or maintain his older branch separately.
I'd say make every effort to reach the original author, and if you don't get anywhere, start maintaining it. You have every legal right, and even the moral right when Open Source code stagnates.
I've taught several C and C++ classes, and used the Deitel & Deitel books because they were the best teaching books that I could find at the time. While some folks can swear by them, others will swear at them. I think they are perfect for 50% of the people out there, and the others will have a harder time because of them.
I've never had a large enough sample size to determine what kind of person will find these books helpful or hurtful.
Personally, I learned C from other people's source code and the man pages. Sure took a long time to learn how pointers worked...
There are plenty of us who write because it's fun, because we like sharing knowledge, and who are not millionaires. I loose money for each book I write because writing pays off I'm writing, which earns piddly royaltees, instead of doing real security/sysadmin work. And worse, you aren't getting paid anything while you're doing the writing, only after you're done.
And I don't think you'll find many authors who want to get rid of libraries. Publishing houses, now that's possible. But don't blame the ones who do the grunt work. (Smacks of the artist vs MPAA/RIAA situation, eh?)
And as to the 'used books are killing our business' angle, baloney. If someone reads one of my books and doesn't think it's worth keeping, by all means they should get rid of it. I never sell off old books, but I do give them away to friends a lot. Or my newer trend, when I have a book I consider crap then I'll write one that I'd want to read.
What you're looking to do is become a 'benevolent dictator' much like Linus is to the Linux kernel. That's an admirable goal, and one that works fairly well if you're up to the task.
Clearly defining the goal of the project is important. Take cURL for example. It is made to snag URLs and shoot the results to STDOUT. It has all the options you could need to support authentication, posting, etc. In fact, the majority of the code is in the library, not the command line utility itself.
Now folks say "Hey, let's make it a GUI application!" but the current maintainers say no, it's a library and a command line tool. However they've been saying that from day one. They clearly define what it is and isn't. It is not a wget replacement, and they don't want it to be. Folks will understand when there is consistency in the answers.
I myself briefly maintained Stunnel (stunnel.org) because the author was offline for six months and there were security issues that needed to be addressed. I didn't want it to be a fork, because I wanted to hand ownership back to the original author once he returned, and that's exactly what happened. He'd done a great job incorporating things that most folks needed.
That said, many people had visions beyond what Mike was willing to incorporate into the official version. Instead of dropping those patches on the floor, I've made them available at the website, so folks can apply them if desired. Thus there is still one consistant main version, but no problems if folks want different versions - just apply the patches.
You must be willing to listen and decide when you're wrong, and when the suggestions go against 'the plan.'
I've written two books, Hacking Linux Exposed and Building Linux VPNs. I have no problems with folks buying the book used. If someone feels that the book didn't do what they needed, then by all means they should sell it to someone else. It was a failure on my part, and I only hope that the next person gets more use out of it.
What I am curious about is the frequent selling of 'collectors editions' of my books. I know we've never had any sort of collectors edition, the only thing that I could see being terribly collectable would be a signed copy. Since I've always included the name of the person who owned it as part of the signature, it's more personal than just a sig. Do folks really want a book that's signed that starts with 'To someoneelse:...' on it? I sure wouldn't.
We have a section about when a VPN is not what you need, and these are the exact kind of examples when a VPN is unnecessary overkill.
As a side note, if you use '-g', make sure you have iptables/ipchains/hosts.{allow|deny} rulesets enabled to make sure that only authorized machines can use the gateway. Otherwise anyone in the world can use your encrypted tunnel.
Slashdot Mirror
Checking our Amazon affiliates account, it looks like about 70 products were ordered on the day this slashdot review was published. I can't see actual monetary amounts until the items are shipped, unfortunately. But based on last quarter's average of $2.78/item, that means we'll be sending about $200 to the EFF for that day alone.
Also, I'd like to thank Alex Lewin who didn't buy through our links, but wrote:
That's the spirit, guys!
So I do not dissagree with you -- your solution is definately optimal for creating lots of good machines -- but the goal was to show how to install and secure one machine in a standalone environment with a set suite of server software.
As to the actual time I'd take to do the install and lockdown, I think 2 hours is plenty, given the proposed packages that must be installed and configured:
Including the (secured) operating system itself, the final server configuration must support (as secure as possible)
- A Web Server, preferably with dynamic-content generating capabilities, such as ASP or mod_perl. No documents need be installed, however all default-install documents/programs must be deleted. In other words, every possible request should return a 404.
- Anonymous FTP Server (read-only)
- Mail Server (able to accept email for itself and send to other Internet machines)
- DNS Server (able to act as a primary for 'OS.example.com' and as a cache for the local network)
- Firewall rules that allow only the above protocols, and any other packets necessary for system administration and normal functionality. (Inbound SSH, DNS Replies, etc.)
The software I'd probably choose would be Apache (mod_perl), DJB's publicfile for anon FTP access, Postfix for the mail server, and DJBDNS for the DNS server/caching server.Now that 2 hours includes keeping a log of what I'm doing, or at least explaining it to someone who can keep a good running log, includes download time of updates (like I said, this should be like an end user, so the packages should be out of date on the install CD) and time to go get and consume a grande non-fat extra carmel carmel macchiato from starbucks.
In short, yes, the donation will apply to any books that get credited to our affiliate accounts. You can go through the book links on any of the following sites:
The book that caused yet another "Hacking" vs "Cracking" thread on Slashdot. I apologize.
A book by Oleg Kolesnikov and I, reviewed on slashdot last year, other reviews here.
James and my company.
A top-notch web development book by James Lee (co-author of HLE and HLEv2) and Brent Ware. I tech edited this book, and also benifited from it in a user capacity, for example setting up the handler that controls access to the auto linux hacking software.
Going through any of those links will work. If you prefer, you can just send money to the EFF directly and cut out the middle man.
In my email program (mutt), I have a perl script pick randomly from ~800 different signatures. (Most new additions seem to be from the "witty comments from my daughter" category.) The script must have some sort of AI in it, because it freqently picks things that are relevant to the text. Having just a static signature for /. seems less interesting. Manually changing it certainly more work than I'm up for.
I don't want folks reading my /. posts and thinking I'm just writing them to have my sig get more notice. I don't want folks seeing my posts and assuming that they has more or less relevance because of the info in the sig. If folks want to see who I am, it's easy enough to click on my home page or /. area.
And I am very very bad at self promotion. Anything I'd write for a sig would sound pompous.
I'm really glad that you're donating money to the EFF. There are just too many people who simply don't put their money where their mouths are.
I don't have the time, energy, or know-how to do what the EFF does. But they seem to fall on the same side of every issue that I do. So I do the best I can - send them cash. Now if only we could fund EFF as well as some corporations fund lackeys on capitol hill.
Unfortunately, I bet even "complementary" books could be considered "competing" in the minds of lawyers, so I stay away from talking about books that could be considered competition, even if I don't agree. So that's why you won't see me commenting about RWLS, for example, though I will comment about non-RWLS topics in that thread.
However, yes, when writing the joke above (it should be moderated "funny" not "informative, for goodness sake!) I did have a very specific book in mind after which I modeled my list, and of course I can't say what it was.
And no one has guessed my /. password. I don't even know it. I use the terribly insecure 'bookmark this link' method. If anyone guesses it, I'm screwed. Call me lazy, but I prioritize what should be super secret and what's not worth the effort.
In actuality, there are about 200 new pages, since we cut out a lot of older stuff, condensed things that are not as relevant that still deserve a good nod, and put the original three case studies online instead.
Chapter 10 grew to be three chapters all told. Chapter 11 needed to be split because it was too big for both Mail and FTP in one chapter. We covered many new attack methods and tools. Everything grew substantially, in spite of trimming out the old and tightening up what we had.
And we fixed a bunch of errors and added completely new ones.
Everything in HLEv1 is still valid. If you own the first, I'd suggest you compare the contents of the two books to decide if you want it or not. Or browse it at the store. Unfortunately, the sample chapter is again chapter 1, which is one of the least modified chapters, so it doesn't give you the best indication of what's new.
This is my best stab at a response. I am so much not a marketing guy, I'm a geek.
For the last quarter I think we got $150 from Amazon and about $10 from B&N which we'll be sending to EFF. Not much, but it's a good way to funnel money their way. I particularly like the irony of having Amazon, creators of some pretty questionable patents, paying EFF.
An even better way to support the EFF is for you to find the cheepest copy of HLEv2 you can get at a local book store (save on shipping) and then donate the difference to EFF directly. Or don't get HLEv2 and send the whole schebang to EFF.
Become an EFF member or donate at www.eff.org.
No, I'm not affiliated with them, other than being a paying member, but I endorse them. And some day I may need them to defend me, given that HLEv2 can be considered a tool that could be illegal under the DMCA.
However the process of hardening them is very different. I bet I can install Debian with minimal packages and achieve all the functionality I claim within an hour or two, with one reboot just to make sure it would come up correctly if it's out in a remote datacenter somewhere.
But that's really no the point - I'd like to see good explanations of what's needed to secure both. It's not just a competition to say Linux is easier /faster to secure (though I suspect that would be the consensus.) It's a way to create more documentation for everyone, Linux and Windows users. In that respect, it's more noble than just a pissing contest.
If I ever got off my butt and tried to actually make the thing happen.
Ok, I don't use sigs or anything to plug my books. I like to be a normal /. person. But in case you're suspicious (you probably have a good future in computer security...) I'll post my /. id to our website so you know it's me.
We decided that this sort of content would provide the quickest time-to-market without any need to tech edit. By providing 0% useful information, it should be able to be read in whole as fast as you can turn the pages - no reading required. We found that people were not able to read the reviews on slashdot in their entirety, so why should we expect them to read ~700 pages about Linux Security?
For a quick bulleted list:
The only exceptions to this rule are the front and back cover, on which we were either overruled, or gave up the good fight.
However if you show different types of attacks as a teaching tool -- "Here's how an off-by-one error in OpenSSH caused it to be exploitable" for example -- then you can show different classes of attacks so the reader understands the actual problems that occur in many different software products.
The goal was to show different kinds of vulnerabilities as explanation. Anyone who is still running older buggy software isn't maintaining their system properly. (And yes, we cover how to upgrade packages in great depth.)
On the other hand, sometimes the problem is configuration: I can have a perfectly secure OpenSSH version, but if I ssh to an untrusted host with X11 forwarding on, the X11 server on my client is easily compromised. No new version of OpenSSH will fix this, it's an inherent problem with the all-or-nothing nature of X11. So configuration-based vulnerabilities do stand the test of time.
I'd never just write a book with a list of BIND vulnerabilities that are based on bugs in the source code, but problems with the DNS protocol itself (it's easily spoofable, leading to MITM attacks) are fair game for in depth coverage.
So, version-specific attacks are only covered if they help teach a concept. Configuration-specific attacks are covered if they are likely to stand the test of time. Protocol-related vulnerabilities (FTP bounce attacks/etc) are fair game until the protocol is destroyed with a big huge mallet.
Systrace on the other hand lives inside your normal kernel - you don't run any virtual machines at all. However systrace can decide what system calls a program can use, and if desired limit how they can be called. For example you could say Apache is allowed to create a bound socket to port 80, but no other port. You can say allow it to read files in /var/www/htdocs but nothing else. This means that should some user make a symlink to /etc/passwd, it can't be read. Should someone get Apache to run shellcode, it can't run /bin/sh or open a new network socket for inbound access.
The configuration to do this is rather extensive, but anything that will be expicit must be. See the sample apache config for example.
Systrace works similarly to other kernel hardening patches, such as GRSecurity or LIDS. LIDS for example can lock down access to the filesystem (read/write/nada) and to root permissions (allow root to read non-root files, dissallow socket binding, etc) but this is different in that the systemcalls themselves have been hooked, not just some common access methods.
In vanilla 2.2 and 2.4 kernels, you don't have any additional kernel level controls (not counting filesystem controls, such as ext2/ext3's extended attributes, (chattr +i filename to make filename unchangeable, even by root, for example)) but you are effectively correct. However there are user-level tools you can use, such as libsafe and stackguard that can prevent many common attacks such as generic buffer overflows.
However there are various patches to the kernel that can provide much more finely tuned control of software. LIDS, GRSecurity, SELinux, and more can allow you to say exactly what a process can or can not do. By creating good rules for the software you need, you can effectively make root no more special than any other user. Only Apache can bind port 80, and no other port. Only ntpd can change the system time - not even root using 'date'. When you create an explicit list of what can do what (easiest by locking everything down and then adding permissions back in where needed) you will have a machine where a piece of software that is compromised only means it can function as it was built to - it has no new functionality it can abuse.
Now kernel patching is intimidating for many, whic h keeps them from trying these advanced security measures. However a new infrastructure is under development which can make this much simpler to use. LSM, the Linux Security Module, has been accepted into linux 2.5 kernel, and it allows you to load or unload advanced linux kernel security systems at run time without the need for kernel recompilation. (This requires that an LSM version of the patch exists, which is the case with LIDS, GRSecurity, SELinux and friends.)
As these are more visible, they will become more mainstream. Debian has an SELinux installer, for example, which can let you boot a very secure version without compiling anything on your own.
Advanced linux security is here today if you want it.
Then when you're done moving a machine, change the IP in DNS. When it seems solid, you put the TTL back to a reasonable (1 day) number.
During the transition, you can also keep a machine at the old IP address and forward the services to the new IP address using tools such as rinetd or xinetd. This assures that you have all traffic going to the correct machine (possibly through the old machine) but that the old IP address is available during the move for clients that have broken DNS resolvers that don't correctly honor DNS TTL values. The rinetd/xinetd purpose machine can easily be a temporary box, such as a laptop - it's not doing any real processing.
If you're also moving your DNS machines, move one a week before the big move, update whois, and make sure everything settles down. Then move the other a day or two after the big move.
Put a machine (server) with no screen on one end of the desk. Put a desktop on the other. Show how easy it is for the desktop to "ssh -X" to the server and run gui programs on the server with the display on the desktop. Explain how useful this would be to have a bunch of very underpowered desktops with a powerful server and still have everyone able to do all their work. And the files are all on the server, making backups easier. etc.
Similarly, get a very low powered desktop (running linux or windows) and run vncviewer on it, and vncserver on the server. Each person has fast CPU of the server, viewed on piddly clients.
Show how you can run Linux within Linux to do fun things like test software without the possibility of crashing your actual machine, run suspicious applications in a sandbox-like environment.
I have been in almost exactly the same position you find yourself. Mike Trojnara, who was (and again is) the developer of Stunnel fell off the face of the Internet for a while back in 2000, and there were several problems that I discovered in the code during his absense. The machine running it was no longer under his control, and eventually dissapeared alltogether, so I took all my archives and started creating new versions. To make it obvious I'd taken over, aside from being blatant about it on the mailing list (which was still working) I labeled my versions differently - 3.8p1 instead of 3.9, for example. Eventually Mike found his way back onto the net, and I promptly and happily handed the developer's sword back to him. His next version was build directly from my latest version (though he later removed the 'goto' I put in there just because I could.)
I had always planned on giving it back to him if he wanted it (I wasn't comfortable developing crypto code here in the US at the time - my rights were still very vaguely defined at the time) so in my experience it went off without a hitch, and there was no fork, just a smooth transition from one to the other.
If you want to continue maintaining it, and are releasing it under the GPL (which I assume you must), there's no reason the original author can't fork off yours or maintain his older branch separately.
I'd say make every effort to reach the original author, and if you don't get anywhere, start maintaining it. You have every legal right, and even the moral right when Open Source code stagnates.
I've never had a large enough sample size to determine what kind of person will find these books helpful or hurtful.
Personally, I learned C from other people's source code and the man pages. Sure took a long time to learn how pointers worked...
And I don't think you'll find many authors who want to get rid of libraries. Publishing houses, now that's possible. But don't blame the ones who do the grunt work. (Smacks of the artist vs MPAA/RIAA situation, eh?)
And as to the 'used books are killing our business' angle, baloney. If someone reads one of my books and doesn't think it's worth keeping, by all means they should get rid of it. I never sell off old books, but I do give them away to friends a lot. Or my newer trend, when I have a book I consider crap then I'll write one that I'd want to read.
It's much more rewarding.
Even if it doesn't pay squat.
Clearly defining the goal of the project is important. Take cURL for example. It is made to snag URLs and shoot the results to STDOUT. It has all the options you could need to support authentication, posting, etc. In fact, the majority of the code is in the library, not the command line utility itself.
Now folks say "Hey, let's make it a GUI application!" but the current maintainers say no, it's a library and a command line tool. However they've been saying that from day one. They clearly define what it is and isn't. It is not a wget replacement, and they don't want it to be. Folks will understand when there is consistency in the answers.
I myself briefly maintained Stunnel (stunnel.org) because the author was offline for six months and there were security issues that needed to be addressed. I didn't want it to be a fork, because I wanted to hand ownership back to the original author once he returned, and that's exactly what happened. He'd done a great job incorporating things that most folks needed.
That said, many people had visions beyond what Mike was willing to incorporate into the official version. Instead of dropping those patches on the floor, I've made them available at the website, so folks can apply them if desired. Thus there is still one consistant main version, but no problems if folks want different versions - just apply the patches.
You must be willing to listen and decide when you're wrong, and when the suggestions go against 'the plan.'
Good luck, and may you enjoy walking that line.
--
www.buildinglinuxvpns.net
Yeah, I did preview, and still I fouled up the subject. Need more sleep, I guess.
What I am curious about is the frequent selling of 'collectors editions' of my books. I know we've never had any sort of collectors edition, the only thing that I could see being terribly collectable would be a signed copy. Since I've always included the name of the person who owned it as part of the signature, it's more personal than just a sig. Do folks really want a book that's signed that starts with 'To someoneelse: ...' on it? I sure wouldn't.
Ummm, we cover cIPe in the book. Would be a pretty crappy job if we hadn't.
As a side note, if you use '-g', make sure you have iptables/ipchains/hosts.{allow|deny} rulesets enabled to make sure that only authorized machines can use the gateway. Otherwise anyone in the world can use your encrypted tunnel.