[Swan-dev] libreswan in debian - Ondřej offered to help (fwd)

[Paul Wouters]

On Mon, 20 Jun 2016, Daniel Kahn Gillmor wrote:

> I've just done one last review and overhaul of libreswan for debian.
> I'm prepared to upload 3.18dr2 into experimental if y'all want.  then we
> get to see what the ftp-masters think about the DES/EAY licensing
> craziness :/

Can we wait a few days? We are working on two important bugfixes that
need to go into 3.18. We will do a 3.18rc1 when we fixed those two. We
really need to get this release out, so it will be very soon.

> https://anonscm.debian.org/git/collab-maint/libreswan.git

Will check.

> Paul, you can probably see a series of not-very-important changes being
> sent as pull requests to upstream github.  If you are OK with them, i'm
> likely to continue making them.

I pulled in two of the three. I need to verify the flex/bison one, as
that one is very sensitive to specific versions of those tools and gcc,
so I need to ensure this still compiles on various other older OSes.

> There are three major changes:
>
> 0) no more libreswan-doc package.  in backchannel discussions with
>    Paul, it sounds like many of the docs were out of date, and i don't
>    think it makes sense to ship them like that.  The binary package
>    ships documentation just fine.

Yes, we killed that for fedora/rhel too.

> 1) no dkms package (and building with USE_KLIPS=false).  I want to
>    start with this package as simple as possible.  We can always make
>    it more complex if there are explicit demands for KLIPS, but much of
>    the upstream documentation suggests that KLIPS support is
>    deprecated, and NETKEY is at least as functional if not moreso.  If
>    we can provide something initially streamlined and simple for debian
>    users, while avoiding supporting complexity over time if there is
>    minimal demand for it, that would be good.

I'm fine with no KLIPS module, as we are moving towards VTI and 3.18 is
the first release that will have it. However, I'd still like to see the
userland compiled with USE_KLIPS=true, so that people can just compile
the kernel code without needing to recompile the userland. Once we are
ready to kill KLIPS, we will likely call it libreswan-4 and kill it off.

Note that some files are used by both, eg kernel_pfkey.c, and we have
not done much testing with USE_KLIPS disabled. So the safer and more
compatible option is to keep it enabled. It will install some of the
supporting tools like "ipsec eroute" and "ipsec tncfg" required for
KLIPS.

> 2) i've moved the NSS database from /etc/ipsec.d to
>    /var/lib/libreswan/nss/ -- this is pretty clearly the most invasive
>    change i've made, and i was initially reluctant to do it.  Then the
>    more i looked at it, the more it seems that this is a database that
>    is going to be modified by the running code over time (e.g. CRLs,
>    OCSP, etc), and it is generally *not* going to be something
>    regularly written or modified by the admin outside of commands
>    provided by libreswan (e.g. "ipsec newhostkey").

It is the right thing, but we werent ready for it for rhel7, so we
didn't do it yet. Although we were thinking of /var/lib/ipsec/ instead
of /var/lib/libreswan/nss/. If you don't want /var/lib/ipsec, can we
at least stick to /var/lib/libreswan and not /var/lib/libreswan/nss ?

>    This change is a large one, and the biggest bits of it are in
>    debian/patches/0006-fix-variant-default-NSS-dir-documentation-and-code.patch
>    This patch is unfortunately not all applicable directly upstream
>    because it includes a bunch of documentation changes. I'm not yet
>    sure how to make the documentation get generated with a replacement
>    from the build options.  i'll try moving foo.xml to foo.xml.in to
>    see whether that works.  if it does, there'll likely be a large-ish
>    pull request coming toward upstream as i look to parameterize
>    mentions of @FINALNSSDIR at .

Andrew did do a couple of commits in the last few days to fixup some of
the hardcoded paths, and also did some fixing with *.in files so we
can have @FOO@ strings in the man pages to get automatically rewritten,.

>    Setting aside the documentation changes, though, there were also
>    some concrete bugs related to having the nss directory not be the
>    default dir.  I'm looking at breaking out the code changes at least
>    for submission upstream as well.  The worst of them is that the
>    config directive ipsecdir is currently used to control both the NSS
>    directory and the directory where pluto will look for:
>
>      * passwd
>      * nsspassword
>      * policies/
>      * cacerts/  (deprecated)
>      * crls/     (deprecated)
>
>    There is no way to explicitly use a distinct NSS directory from a
>    configuration variable without also placing these files somewhere
>    else.  In the debian patch i'm proposing, i've decoupled the NSS
>    directory from the ipsecdir directive, so there is currently no way
>    in ipsec.conf to control the placement of the NSS directory.  Paul,
>    I can propose a patch for such a directive if you'd like it to be
>    modifiable at runtime.

Andrew has been working on fixing the tools for this. I think we might
need to rename the option though. Currently there is --ipsecdir and
--configdir. Possibly we should rename --configdir to --nssdir ?

> Unit Testing
> ------------
>
> Are there any unit tests, or other simple tests that can verify the
> functionality of the pieces of libreswan without setting up a full rig?

The cavp binary does the NIST CAVS testing, but it requires
ikev1_dsa.fax.bz2, ikev1_psk.fax.bz2 and ikev2.fax.bz2. We include those
in the fedora/rhel package and run the test in rpm's %check phase.

pluto also has some startup tests, enum names consistency and some
crypto tests, but we currently don't have a pluto --selftest option
that only runs those and exits. We probably should just add that.

> I'm thinking of simple tests like creating a new NSS directory and
> manipulating it with rsasigkey; or parsing and dumping config files,

The parser can be checked using ipsec readwriteconf. Given a properly
formated input file, it should create the same output file. Some
sorting happens, so you should probably run any example config
manually through readwriteconf, confirm it, and then use that as
the input test file.

You can create newhostkey/rsasigkey tests but you might need current
git instead of 3.18dr2 to get some of the latest fixes Andrew did. but
then I think you can run (sprinkle safe tempdirs)

mkdir /tmp/xxx
ipsec initnss --configdir /tmp/xxx
ipsec newhostkey --configdir /tmp/xxx
ipsec showhostkey --configdir /tmp/xxx --list
psec showhostkey --configdir /tmp/xxx --left --ckaid <ckaid from output above>

> etc.  We're currently disabling the tests because the they look
> overwhelming, i think.  Maybe i've got that wrong?

I'd have to look at what testing you did.

> As one simple example, I notice that i am getting an error even when i
> try to do:
>
> 0 dkg at alice:~$ /usr/sbin/ipsec rsasigkey --configdir sql:$(mktemp -d) 3072
> ipsec rsasigkey: key pair generation failed: "-8037"
> 0 dkg at alice:~$

ipsec rsasigkey --configdir /tmp/xxx 3072 works for me. Possibly you
hadn't initialised the database or Andrew fixed another issue that
is not yet in 3.18dr2 ?

> (also, shouldn't that return a non-zero error code?)

It does for me?

paul at thinkpad:~$ mkdir /tmp/x
paul at thinkpad:~$ /usr/libexec/ipsec/rsasigkey --configdir sql:/tmp/x 3072
ipsec rsasigkey: authentication of "NSS Certificate DB" failed
paul at thinkpad:~$ echo $?
1

> Real World Testing
> ------------------
>
> I'd really like to be able to test this package conclusively and declare
> it functional.  However, i've failed thus far.
>
> I tried in particular to test the opportunistic encryption mode against
> oe.libreswan.org, following the directions here:
>
>  https://libreswan.org/wiki/HOWTO:_Opportunistic_IPsec
>
> I got the big scary NSA eye of sauron at http://oe.libreswan.org/. :/

Those servers are not yet stable, as we are actively working on NAT
support for OE. I'll try to stabilize those servers for you.

> Also "ipsec whack --trafficstatus" produces only "000".

We should suppress those empty lines with only 000. It's a bug.

> Any pointers on what needs doing?  I feel like i shouldn't even need to
> generate an RSA key to do opportunistic mode, but maybe that's what's
> missing?

You should not need to generate a key indeed, as it uses AUTHNULL for
that. We are working on adding multiple AUTH methods (should be done
in the next 1-2 months)

> I'm also happy to take this to the libreswan dev list if you think that
> would be a better way to go about it.

I've CC:ed the list as it does make sense to just discuss it there,

Paul