Summary: Before installing the DJBDNS software, installing the documentation to your local system could prove to be an invaluable resource as the installation process moves forward.

In the last article, we installed the daemontools package used by DJBDNS. In this one, we'll continue and install the DJBDNS software itself. But first, let's install the documentation.

Following his desire to do everything differently than the rest of the world[1], DJB distributes his documentation as HTML that will be installed in the /doc directory, instead of man pages. For an explanation about the /doc system, see http://cr.yp.to/slashdoc.html.

# cd /
# mkdir /doc
# chmod 755 /doc
# wget http://cr.yp.to/djbdns/doc.tar.gz
# tar xvzf /doc.tar.gz
# rm doc.tar.gz

The documentation HTML is now installed. The pages are all standalone at this point, so if you'd prefer you can create the HTML index pages to make it easier to navigate through them:

# wget -q -O - http://cr.yp.to/slashdoc/slashdoc-merge | sh

This is simply a shell script to merge all the HTML documentation indexes together and create files in /doc such as 'commands.html', which are easier to peruse. You can view the documentation for DJBDNS with your favorite Web browser, such as:

$ lynx /doc/

or

$ w3m /doc/commands.html

These are all the same Web pages that are available at http://cr.yp.to/. If you have Internet access, then you can skip this part entirely. However, I like to have documentation stored locally as well, just in case.

Now let's install the software itself. Let's make a directory to do our compilation, download and install:

$ mkdir /tmp/src
$ cd /tmp/src
$ wget http://cr.yp.to/djbdns/djbdns-1.05.tar.gz
$ tar xzvf djbdns-1.05.tar.gz
$ rm djbdns-1.05.tar.gz
$ cd djbdns-1.05
$ make

Sit back as you compile for a few minutes. When done, you'll need to install it, this time as root:

# make setup check

The various DJBDNS daemons all run under dedicated non-root accounts. You'll need to create these accounts before the daemons will be able to function. Typically you use the same username and group name as the service itself. Thus, the tinydns service will run under username tinydns and group name tinydns. Use whichever methods you prefer to create these users and groups (useradd / adduser / vi / etc). The accounts we'll be creating are 'tinydns', 'dnscache', 'dnslog', and 'axfrdns', though you may not actually use all of these depending on your setup. An easy way to do this (as root) on a Red Hat system could be:

for acct in tinydns dnscache dnslog axfrdns
do
   groupadd $acct
   useradd -g $acct -s /bin/false -c "DJBDNS $acct user" \
	-M -d /nada $acct
done

At this point, the software is all installed and ready for you to configure. You're going to want to play with this on a non-production system until you get the feel for it as you can't simply install DJBDNS and install BIND during your lunch break[2].

That's the end of this week's security article. However I thought it was a good time for another challenge. One of the members of my local Linux User Group asked for a quick way to delete the first four bytes from a file. This begat a rapid series of emails showing the many, many ways you can do things on Unix systems. Tail, dd, sed, and of course perl all came into play. In the spirit of TMTOWTDI (there's more than one way to do it), I challenge folks on this list to create a file that can strip the first four bytes from the file 'modifyme' in the current working directory. The file may not be an executable, but instead must be one of the following types:

• A man page /usr/share/man/man1/stripfourbytes.1 viewed with 'man stripfourbytes'.
• A postscript file, 'stripfourbytes.ps', viewed with ghostview or ghostscript.
• A LaTeX file stripfourbytes.tex, viewed with 'latex stripfourbytes'
• A PDF file, stripfourbytes.pdf, viewed with xpdf or acroread, etc.
• An image file, viewed with any standard Linux image viewer (eeyes, qiv, xv, etc.)
• Any other non-executable file that you can use to trick a standard Linux program into running arbitrary code. (An attack against grep, for example.)

Some of the above are definitely possible. Others I've heard of folks doing, but have never tried myself. Others I doubt are exploitable at all.

The first or best winner of each category will get a postcard from sunny Seattle from yours truly, and get their name immortalized in a future column. I'll post answer and discussion in a month, so get coding!

NOTES

[1] Some call this stubbornness and ignorance of standards; others call this innovation. Now that I'm used to his system, I lean toward the later.

[2] Though you can if you've done it enough times. And I've had the joy of removing BIND many times now.

Bri Hatch is Chief Hacker at Onsight, Inc. and author of Hacking Linux Exposed and Building Linux VPNs. He's never happier then when he's transitioning new systems away from BIND and other too-often- installed software. Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2002.

This article was first published here in ITworld.com Inc., 118 Turnpike Rd., Southborough, MA 01772  on 23-Jul-2002.