Log in

FreeBSD device nodes and chroots - Tony Finch

dotatfanf wrote
on 16th August 2012 at 15:54
Previous Entry Share Next Entry

FreeBSD device nodes and chroots

I run a toy nameserver on my FreeBSD workstation, mainly for experimenting with DNSSEC. I run it in a chroot, which I had set up in the traditional way using mknod. This appeared to work OK.

This week I have been trying out BIND 9.9.2b1, which introduces support for ECDSA signatures. One of its promising attributes is an ECDSAP256SHA256 signature is about a half of the size of 1024 bit RSASHA1 signature:

    fanf2.ucam.org. 3600 IN RRSIG SOA 5 3 3600 (
                            20120915135936 20120816125936 35583 fanf2.ucam.org.
                                /JknR85zQNZ2YOYJ4QL9HIy1uEuoirpa1fDfr8I= )
    fanf2.ucam.org. 3600 IN RRSIG SOA 13 3 3600 (
                            20120915135936 20120816125936 36584 fanf2.ucam.org.
                                GerFX/C+Pcqecx1rXsZLwWGDJvQ7q7ch8fryt+ImuA== )

When I first tried to sign a zone with ECDSA, named logged a rather uninformative pair of error messages:

    15-Aug-2012 19:56:31.969 general: error: 
                             zone fanf2.ucam.org/IN:
                             update_sigs:add_sigs -> sign failure
    15-Aug-2012 19:56:31.970 general: error:
                             zone fanf2.ucam.org/IN:
                             sign_apex:update_sigs -> sign failure

I was unable to reproduce this error with a much simpler name server configuration on another machine. I hacked around to trace where the error came from, and it turned out to be inside OpenSSL's ECDSA_do_sign() routine.

One of the notable differences between RSA and DSA is that DSA requires random numbers to create a signature. BIND requires random numbers for lots of other things at run time, including for hard-to-guess query IDs and source port numbers. So I had thought the /dev/random setup in my chroot was working. However, while debugging my ECDSA problem I noticed BIND logging an error at startup:

    Aug 15 20:07:56 black named[13450]: 
                    could not open entropy source /dev/random: unexpected error
    Aug 15 20:07:56 black named[13450]: 
                    using pre-chroot entropy source /dev/random

I then had to learn the correct way to set up device nodes in a chroot on FreeBSD:

	# $T is the chroot directory
	mount -t devfs devfs $T/dev
	# the default ruleset is immutable, so create a new one
	devfs -m $T/dev ruleset 1
	# only a small selection of devices should be visible
	devfs -m $T/dev rule add path random unhide
	devfs -m $T/dev rule add path urandom unhide
	# make it so
	devfs -m $T/dev rule applyset

Having fixed that, BIND cheerfully signed the zone with ECDSA. Evidently BIND is clever enough to recover from a badly set up chroot, but OpenSSL isn't, presumably because it does not try to open /dev/random until the last moment.

(Leave a comment)
Date:2012-08-16 15:15 (UTC)
FreeBSD doesn't have bind mounts?
(Reply) (Thread)
Date:2012-08-16 15:21 (UTC)
There is mount_nullfs but it only works on directories.
(Reply) (Parent) (Thread)
Date:2012-08-17 15:12 (UTC)
The default rulesets will do what you want if you apply ruleset 1 and 2:

[root@cheddar ~]# mkdir -p test/dev
[root@cheddar ~]# mount -t devfs devfs /root/test/dev
[root@cheddar ~]# devfs -m /root/test/dev rule -s 1 applyset
[root@cheddar ~]# devfs -m /root/test/dev rule -s 2 applyset
[root@cheddar ~]# ls test/dev
null random urandom zero
[root@cheddar ~]#

I think that adding it to /etc/fstab and putting "devfs_set_rulesets='/chroot/dev=devfsrules_unhide_basic'" in /etc/rc.conf would give you persistance. (Or add your custom ruleset to /etc/devfs.rules and specify it in rc.conf instead). However, I'm not rebooting to see if I'm right =)
(Reply) (Thread)
Date:2012-08-17 17:52 (UTC)
Are you using raw chroot, or a jail?
(Reply) (Thread)
Date:2012-08-17 18:21 (UTC)
Just a chroot. The main cause of this problem was that I was trying to use a cross-platform rc script, which lacked the necessary FreeBSDisms.
(Reply) (Parent) (Thread)

(Leave a comment)

Powered by LiveJournal.com