Weblogs for dkg

Posted by dkg on Tue 29 Mar 2011 at 08:00
Tags: ,
jrollins and i recently did a bunch of cleanup work on debirf, with the result that debirf 0.30 can now build all the shipped example profiles without error (well, as long as debootstrap --variant=fakechroot is working properly -- apprently that's not the case for fakechroot 2.9 in squeeze right now, which is why i've uploaded a backport of 2.14).

To try to avoid getting into a broken state again, we set up an autobuilder to create the images from the three example profiles (minimal, rescue, and xkiosk) for amd64 systems. The logs for these builds are published (with changes) nightly at:

git://debirf.cmrg.net/debirf-autobuilder-logs
But even better, we are also publishing the auto-generated debirf images themselves. So, for example, if you've got an amd64-capable machine with a decent amount of RAM (512MiB is easily enough), you can download a rescue kernel and image into /boot/debirf/, add a stanza to your bootloader, and be able to reboot to it cleanly, without having to sort out the debirf image creation process yourself.

We're also providing ISOs so people who still use optical media don't have to format their own.

Please be sure to verify the checksums of the files you download. The checksums themselves are signed by the OpenPGP key for Debirf Autobuilder <debirf@cmrg.net>, which i've certified and published to the keyserver network.

What's next? It would be nice to have auto-built images for i386 and other architectures. And if someone has a good idea for a new example profile that we should also be auto-building, please submit a bug to the BTS so we can try to sort it out.

 

Posted by dkg on Wed 16 Mar 2011 at 04:40
I spent part of today looking at packaging Peter Gutmann's CryptLib for debian. My conclusion: it may not be worth my time.

One of the main reasons i wanted to package it for debian is because i would like to see more OpenPGP-compliant free software available to debian users and developers, particularly if the code is GPL-compatible.

Cryptlib makes it quite clear that it intends to be GPL-compatible:

cryptlib is distributed under a dual license that allows free, open-source use under a GPL-compatible license and closed-source use under a standard commercial license.
However, a significant portion of the cryptlib codebase (particularly within the bn/ and crypt/ directories) appears to derive directly from OpenSSL, and it retains Eric Young's copyright and licensing. This licensing retains the so-called "advertising clause" that is generally acknowledged to be deliberately incompatible with the GPL. (A common counterargument for this incompatibility is that OpenSSL should be considered a "System Library" for GPL'ed tools that link against it; whether or not you believe this for tools linked against OpenSSL, this counterargument clearly does not hold for a project that embeds and ships OpenSSL code directly, as CryptLib does)

This does not mean that CryptLib is not free software (it is!), nor does it mean that you cannot link it against GPL'ed code (you can!). However, you probably can't distribute the results of linking CryptLib against any GPL'ed code, because the GPL is incompatible with the OpenSSL license.

The un-distributability of derived GPL-covered works makes the CryptLib package much less appealing to me, since i want to be able to write distributable code that links against useful libraries, and many of the libaries i care about happen to be under the GPL.

I also note that Peter Gutmann and CryptLib Security Software (apparently some sort of company set up to distribute CryptLib) may be in violation of Eric Young's License, which states:

 * 3. All advertising materials mentioning features or use of this software
 *    must display the following acknowledgement:
 *    "This product includes cryptographic software written by
 *     Eric Young (eay@cryptsoft.com)"
 *    The word 'cryptographic' can be left out if the rouines from the library
 *    being used are not cryptographic related :-).
A Google search for Eric Young's name on cryptlib.com yields no hits. I do find his name on page 340 of the Cryptlib manual, but that hardly seems like it covers "All advertising materials mentioning features or use of this software". I suppose it's also possible that CryptLib has negotiated an alternate license with Eric Young that I simply don't know about.

In summary: i think CryptLib could go into debian, but its incorporation of OpenSSL-licensed code makes it less useful than i was hoping it would be.

I have a few other concerns about the package after looking it over in more detail. I suspect these are fixable one way or another, but i haven't sorted them out yet. I'm not sure i'll spend the time to do so based on the licensing issues i sorted out above.

But in case anyone feels inspired, the other concerns i see are:

embedded code copies
In addition to embedded (and slightly-modified) copies of bn/ and crypt/ from OpenSSL, CryptLib contains an embedded copy of zlib. Debian has good reasons for wanting to avoid embedded code copies. I've got it CryptLib building against the system copy of zlib, but the bits copied from OpenSSL seem to be more heavily patched, which might complicate relying on the system version.
executable stack
lintian reports shlib-with-executable-stack for the library after it is built. I don't fully understand what this means or how to fix it, but i suspect it derives from the following set of object files that also have an executable stack:
0 dkg@pip:~/src/cryptlib/cryptlib$ for foo in $(find . -iname '*.o'); do
>  if ! readelf -S "$foo" | grep -q .note.GNU-stack ; then
>   echo "$foo"
>  fi
> done
./shared-obj/desenc.o
./shared-obj/rc5enc.o
./shared-obj/md5asm.o
./shared-obj/castenc.o
./shared-obj/bfenc.o
./shared-obj/rmdasm.o
./shared-obj/sha1asm.o
./shared-obj/bn_asm.o
./shared-obj/rc4enc.o
0 dkg@pip:~/src/cryptlib/cryptlib$ 
They probably all need to be fixed, unless there's a good reason for them to be that way (in which case they need to be documented).
non-PIC code
lintian reports shlib-with-non-pic-code on the library after it is built. I don't fully understand what this means, or how to resolve it cleanly, but i imagine this is just a question of sorting out the details.
Anyone interested in using my packaging attempts as a jumping off point can start with:
git clone git://lair.fifthhorseman.net/~dkg/cryptlib
Oh, and please correct me about anything in this post; I'd be especially happy to hear that my analysis of the licensing issues above is wrong :)

 

Posted by dkg on Mon 7 Mar 2011 at 06:02
Is there a way to access a MySQL database over the network from PHP and be confident that
  • the connection is actually using SSL, and
  • the server's X.509 certificate was successfully verified?

As far as i can tell, when using the stock MySQL bindings, setting MYSQL_CLIENT_SSL is purely advisory (i.e. it won't fail if the server doesn't advertise SSL support). This means it won't defend against an active network attacker performing the equivalent of sslstrip.

Even if MYSQL_CLIENT_SSL was stronger than an advisory flag, i can't seem to come up with a way to tell PHP's basic MySQL bindings the equivalent of the --ssl-ca flag to the mysql client binary. Without being able to configure this, a "man-in-the-middle" should be able to intercept the connection by offering their own certificate on their endpoint, and otherwise relaying the traffic. A client that does not verify the server's identity would be none the wiser.

One option to avoid a MITM attack would be for the server to require client-side certs via the REQUIRE option for a GRANT statement, but the basic MySQL bindings for php don't seem to support that either.

PHP's mysqli bindings (MySQL Improved, i think) feature a command called ssl_set() which appears to allow client-side certificate support. But its documentation isn't clear on how it handles an invalid/expired/revoked server certificate (let alone a server that announces that it doesn't support SSL), and it also mentions:

This function does nothing unless OpenSSL support is enabled.
Given that debian MySQL packages don't use OpenSSL because of licensing incompatibilities with the GPL, i'm left wondering if packages built against yaSSL support this feature. And i'm more than a little bit leery that i have no way of telling whether my configuration request succeeded, or whether this function just happily did nothing because the interpreter got re-built with the wrong flags. Shouldn't the function fail explicitly if it cannot meet the user's request?

Meanwhile, the PDO bindings for MySQL apparently don't support SSL connections at all.

What's going on here? Does no one use MySQL over the network via PHP? Given the number of LAMP-driven data centers, this seems pretty unlikely. Do PHP+MySQL users just not care about privacy or integrity of their data?

Or (please let this be the case) have i just somehow missed the obvious documentation?

 

Posted by dkg on Tue 1 Mar 2011 at 18:32
Tags: , , ,
I used to maintain a membership with IEEE. I no longer do.

The latest nonsense to come from them is a change for the worse in their copyright assignment policy, which i thought was already problematic.

Other engineering societies (IETF, USENIX, etc) continue to do socially relevant, useful work without attempting to control copyright of work contributed to them. This just makes IEEE look like a power- and money-hungry organization, rather than a force for positive advancement of technology.

For shame, IEEE.

I will not consider reinstating my membership unless the organization changes their copyright assignment and publication policy to better reflect the spirit of scientific inquiry and technological advancement they should stand for.

 

Posted by dkg on Sun 16 Jan 2011 at 19:57
Let's say you set up a machine using an encrypted disk with LUKS (debian-installer's partman makes this wonderfully easy!). You choose an initial passphrase, get the machine working, and it's working great. Then, you need to restart it, and realize that (for whatever reason) you've forgotten or lost the passphrase for the volume. oops! (i'm sure this has never happened to you -- let's just pretend it's your less-fortunate friend).

If your system is still running, and you have superuser access to it, you can actually set a new passphrase for the LUKS volume using information that the dm-crypt kernel module has about the in-use mapping. In my examples, i'll imagine that the source volume is /dev/XXX2 and the exported cleartext volume is known by the device-mapper as XXX2_crypt

In the bigger picture, this should serve as a reminder that even though your disk is encrypted, if someone gets live access to the superuser account on a system with the encryption keys loaded, your data is no longer secret.

Before you do any tweaking, you might want to back up your LUKS header, just in case:

0 root@example:~# umask 077
0 root@example:~# cryptsetup luksHeaderBackup /dev/XXX2 --header-backup-file XXX2.luksheader.backup
0 root@example:~# 
Maybe also copy that off the machine, since a copy of the LUKS header stored within its own volume isn't terribly useful for a backup-recovery situation.

You might also be interested in looking at the contents of the LUKS header:

0 root@example:~# cryptsetup luksDump /dev/XXX2
LUKS header information for /dev/XXX2

Version:       	1
Cipher name:   	aes
Cipher mode:   	cbc-essiv:sha256
Hash spec:     	sha1
Payload offset:	2056
MK bits:       	256
MK digest:      93 51 6c 66 ec ce 32 54 6f 6b 52 d1 27 9b 5a 62 6f 6b 52 d1
MK salt:       	b2 ca 20 49 9f 78 49 c2 fe 15 b4 0f 74 11 23 49
               	64 9e 61 bb f2 82 60 47 a5 76 fa a4 24 0e 5a 7e
MK iterations: 	10
UUID:          	052f1da0-21a1-11e0-ac64-0800200c9a66

Key Slot 0: ENABLED
	Iterations:         	218733
	Salt:               	f2 ae 8c 53 48 a5 f0 bf e1 2c 06 5f 5a bd ff d9
	                      	9a 2e d1 49 3a 63 f8 49 82 ed ae 86 7b 7b 7e 76 
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
0 root@example:~# 
Now, the fix: We pull the live "master key" from the running device map, and fill a new luksKeySlot from it (this example uses bash's <() syntax for process substitution -- if you use a different shell, i'm sure you can find a different way to do it):
0 root@example:~# cryptsetup --master-key-file <( 
> dmsetup --showkeys table | awk '/^XXX2_crypt: /{ print $6 }' | tr -d '\n' | perl -e 'print pack("H*", <STDIN>);' 
> ) luksAddKey /dev/XXX2
Enter new passphrase for key slot: abc123
Verify passphrase: abc123
2 root@example:~# 
(note that the luksAddKey invocation above returned an error code of 2 even though it succeeded. I think this is a bug in cryptsetup's return code, not a bug in the password resetting -- it should have returned 0 instead of 2).

You can check to see that a new key slot was enabled by re-running cryptsetup luksDump

And if you really want to double-check before you reboot, you can try enabling a third keyslot using the passphrase you just added, since this would not succeed if your new passphrase failed to unlock any of the existing keyslots:

0 root@example:~# cryptsetup luksAddKey /dev/XXX2
Enter any passphrase: abc123
Enter new passphrase for key slot: anotherpassphrase
Verify passphrase: anotherpassphrase
0 root@example:~# 
You can also get rid of the original keyslot (which you don't know the passphrase to) like this:
0 root@example:~# cryptsetup luksKillSlot /dev/XXX2 0
Enter any remaining LUKS passphrase: abc123
0 root@example:~# 
(the above commands were all demonstrated using debian testing, with cryptsetup 2:1.1.3-4 and dmsetup 2:1.02.48-4)

 

Posted by dkg on Thu 6 Jan 2011 at 05:52
A friend just pointed me to Liberating Knowledge: A Librarian's Manifesto for Change by Barbara Fister, an academic librarian who also happens to write mystery novels.

She has an excellent perspective on the meaning of libraries, and the tradeoffs involved with the current societal trend toward privatizing knowledge through so-called "intellectual property" regulations. In a great critique of the passivity of academia and libraries in the face of attempts at intellectual enclosure by private corporations, she writes:

This uninformed indifference is laying the groundwork for a new tragedy of the commons: a world in which knowledge is turned into intellectual property, monetizied, and made artificially scarce.

She closes with a six-point manifesto that begins:

Liberation bibliography arises out of outrage at the injustice of the current system. It’s not about saving money, it’s about the empowering nature of knowledge and the belief that it shouldn’t be a luxury good for the few.

The article abounds in examples of heinous arrangements in the current system that seem to be accepted as standard procedure, and clear thinking about what the actual tradeoffs are (and how we, as a society, are making them poorly).

If i had one objection, it would be that she neglects to mention increased surveillance as one of the problems that come with privatization of knowledge. Our abilities to read privately and anonymously, and to correspond confidentially are at risk because of these systems of control.

Anyway, I'd love to see more open allegiances between librarians and free software folks; the ideals and struggles are very much in parallel. Go talk to your librarian friends about this stuff today!

 

Posted by dkg on Mon 13 Dec 2010 at 00:17
Someone recently pointed me to some economic/statistical models that were designed for eviews (a proprietary tool).

They were looking for help converting the model into a format that could work with gretl (the Gnu Regression, Econometrics and Time-series Library). I'm afraid i'm an economics dunce, and i have no experience with this stuff. Any pointers?

 

Posted by dkg on Thu 2 Dec 2010 at 09:41
i suspect a lot of people are used to forwarding TCP sockets with SSH -- for example, to connect locally to a mysql daemon that runs only on the loopback interface of a remote machine (this is debian's default mysql-server configuration):
ssh -N -T -oExitOnForwardFailure=yes -L 3306:localhost:3306 remoteuser@mysqlserver.example

But sometimes, the remote service runs on a UNIX-domain socket, not on a TCP socket -- for example, debian's default configuration for postgresql is to have it listen only on a UNIX domain socket in /var/run/postgresql, and use SO_PEERCRED with a simple system account == psql account mapping scheme to authenticate users without needing any extra credentials. This is not quite as simple to forward over ssh, but it's doable as long as socat is installed on both your local host and on the remote postgres server.

Here's one way to do it if $SOCKET_DIR points to the full path of a directory under the user's control (this is all one command, split across lines for easier reading):

socat "UNIX-LISTEN:$SOCKET_DIR/.s.PGSQL.5432,reuseaddr,fork" \
   EXEC:'ssh remoteuser@psqlserver.example socat STDIO UNIX-CONNECT\:/var/run/postgresql/.s.PGSQL.5432'
Then, you'd connect with something like:
psql "user=remoteuser host=$SOCKET_DIR"
Each such psql connection will trigger an ssh connection to be made. Of course, this won't work well if ssh has to prompt for passwords, but you should be using ssh-agent anyway, right?

There are at least a couple nice features of being able to use postgresql from a local client like this:

  • your psql client can load files from your local machine, and can dump/export files to the local machine.
  • your ~/.psql_history stays local, so you can review what you did even when you're offline
  • you can run local RDBMS administrative GUIs like pgadmin3 with minimal network traffic and no extra packages installed on the server.
  • unlike forwarding TCP ports (where any other user account on the machine can hop onto your connection), you can control access to your local UNIX-domain socket with standard filesystem permissions on $SOCKET_DIR.
Of course, postgresql itself already comes with a nice range of high-quality network-capable authentication mechanisms you could use. But many of them (like GSSAPI or X.509 mutual key-based authentication over TLS) require additional infrastructure setup; and you probably already have sshd up and running on that machine -- so why not make use of it?

 

Posted by dkg on Wed 17 Nov 2010 at 23:43
Tags: , ,

i've been on an IPv6 kick recently, getting dual-stack systems up and working for a bunch of folks.

I'd like to make some of these services reachable by IPv6-only clients. this suggests that i need a range of details sorted out, but i think the one piece left for me is the glue records for the nameservice. i use in-bailiwick nameservers for DNS where possible, which means i want mandatory glue records. that is, the primary namserver for example.org is probably something like ns0.example.org, which means that the org nameservers themselves need to store not only the NS record, but an A record that corresponds to the name pointed to by the NS.

But for IPv6-only clients that do their own name resolution, i need AAAA glue records, and i haven't yet found a registrar that will push AAAA glue records for the same names as the existing A glue into the org zone.

Do you know of a registrar that will do this?

I've tried:

dotster
Dotster seems to only allow IPv4 glue to be entered on their Register Nameserver config page (needs a dotster login to see it). They haven't yet yet responded to my query through their support web form about submitting AAAA glue
gandi
gandi at least offers the opportunity to enter AAAA glue, but apparently can't let me have both AAAA and A glue for the same name. A note to their support team got me a response that this is planned for Q1 or Q2 of 2011.

Any suggestions for reasonable registrars that offer this today?

Am i being silly in wanting AAAA and A glue for the same names? i note that the root zone and the org zone both offer A and AAAA records for each of their dual-stack nameservers. You can check for yourself:

 dig @a.root-servers.net ns org
 dig @a.root-servers.net ns .

if i don't go for dual records, i could instead use gandi and go with distinct names for the v6 and v4 servers, like this:

;; QUESTION SECTION:
;example.org.				IN	NS

;; AUTHORITY SECTION:
example.org.      172800	IN	NS	a.ns.example.org.
example.org.      172800	IN	NS	b.ns.example.org.
example.org.      172800	IN	NS	c.ns.example.org.
example.org.      172800	IN	NS	d.ns.example.org.

;; ADDITIONAL SECTION:
a.ns.example.org. 172800	IN	A	192.0.2.3
b.ns.example.org. 172800	IN	A	192.0.2.4
c.ns.example.org. 172800	IN	AAAAA	2001:db8::3
d.ns.example.org. 172800	IN	AAAAA	2001:db8::4

But of course what i really want is this:

;; QUESTION SECTION:
;example.org.				IN	NS

;; AUTHORITY SECTION:
example.org.      172800	IN	NS	a.ns.example.org.
example.org.      172800	IN	NS	b.ns.example.org.

;; ADDITIONAL SECTION:
a.ns.example.org. 172800	IN	A	192.0.2.3
a.ns.example.org. 172800	IN	AAAAA	2001:db8::3
b.ns.example.org. 172800	IN	A	192.0.2.4
b.ns.example.org. 172800	IN	AAAAA	2001:db8::4

My concern about this is if some IPv4-only system gets a list like the first one, and decides to use c.ns.example.org or d.ns.example.org, which doesn't have an A record at all. That would be a silly implementation, of course. but uh, we have a lot of silly implementations of things out there.

Feedback welcome!

 

Posted by dkg on Wed 20 Oct 2010 at 21:31
Tags: none.
Debian NYC will be holding a workshop next week: What's in a Package? will happen at 7:00pm New York time on October 27, 2010. If you're in the New York area, interested in packaging things for debian and related systems, or just want to understand the packages in your system better, you should RSVP and come on out!

This workshop will provide advanced theory useful for people modifying or creating packages. For people modifying packages, you'll learn many typical motifs and about various build systems. For creating packages, you'll be much better prepared to read and understand guides a deep level. However, this is still not a step-by-step guide in "how to build packages", but will get you very close to there.

See you there!