Colors of Noise

agx@sigxcpu.org

Entries from June 2008.

mount by label with Debian Installer
28th June 2008

The nice thing about d-i is that it's even more flexible then one thinks. Usually an autopartitioning recipe looks like:

500 10000 1000000 ext3
method{ format }
format{ }
use_filesystem{ }
filesystem{ ext3 }
mountpoint{ / } .

But what if you want a to set a filesystem label. That's easy:

500 10000 1000000 ext3
method{ format }
format{ }
use_filesystem{ }
label{ root }
filesystem{ ext3 }
mountpoint{ / } .

This sets the label root on the ext3 filesystem that will be mounted as /. You can set any variable here and the text between the curly braces ends up in $<partition>/<var> ready for partman to pick it up. See partman-auto-recipe for the full details.

The label allows to mount the filesystem by it's label instead of it's device name, so /etc/fstab looks like:

 LABEL=root /     ext3  defaults,errors=remount-ro,relatime 0 1
 LABEL=home /home ext3  defaults,relatime,user_xattr        0 2

Very handy if you insert partitions later which would change the numbering or work with partimage snapshots that should work on PATA and SATA. However this currently isn't supported by d-i since it can only create filesystem labels but can't write them to /etc/fstab. With the patches from #488321 and #488322 this can be done with:

500 10000 1000000 ext3
method{ format }
format{ }
use_filesystem{ }
label{ root }
labeled_mount{ }
filesystem{ ext3 }
mountpoint{ / } .

You also need to fixup mount since it will otherwise segfault during d-i's initial deboostrap run (#488312). Now support for labels on swap devides needs to be added to d-i.

Tags: debian.
PKINIT: Kerberos v5 with Smart Cards
22nd June 2008

Using Kerberos for single sign on is a nice thing but one feels uncomfortable that only a password grants access to all services. One can use smart cards and public key cryptography to achieve Two factor authenticaton which makes things considerably safer. In Kerberos terms this is called pkinit. To get there, several steps are necessary:

  1. Creating the PKI
  2. Setting up the KDC
  3. Setting up the user part
  4. Putting things on the smart card

The step below assume you already have a working Heimdal Kerberos setup in a realm named MS20.NIX and are using Debian.

Creating the PKI

If you don't already have certificates hxtool is the simplest thing to create them:

Create the Certificate Authority (CA):

$ hxtool issue-certificate --self-signed --issue-ca --generate-key=rsa --subject="CN=CA,DC=ms20,DC=nix" --lifetime=10years --certificate="FILE:ca.pem"

Create the KDCs certificate:

$ hxtool issue-certificate --ca-certificate=FILE:ca.pem --generate-key=rsa --type="pkinit-kdc" --pk-init-principal="krbtgt/MS20.NIX@MS20.NIX" --subject="uid=kdc,DC=ms20,DC=nix" --certificate="FILE:kdc.pem"

Create the Certificate for a User agx@MS20.NIX:

$ hxtool issue-certificate --ca-certificate=FILE:ca.pem --generate-key=rsa --type="pkinit-client" --pk-init-principal="agx@MS20.NIX" --subject="uid=agx,DC=ms20,DC=nix" --certificate="FILE:user.pem"

In the above setup, hxtool puts the certificate and the private key into one file, so extract the lines between:

-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----

from ca.pem, store it away in ca.key ant put it at a save location, remove these lines from ca.pem then. Don't put ca.key on the KDC - you only need it to create new certificates. The resulting ca.pem is the save to copy around.

Note: unfortunately hxtool is currently missing from the heimdal-clients Debian package. You can aplly the patch from #487119 and rebuild the package.

Setting up the KDC

You need to enable pkinit in /etc/heimdal-kdc/kdc.conf and tell the KDC where to find it's own identity (pkinit_identity) as well as the trust anchors (pkinit_anchors). For simplicity we use our new CA as the only trust anchor so only certificates signed by this ca are valid for the KDC:

enable-pkinit = yes
pkinit_identity = FILE:/etc/heimdal-kdc/pkinit/kdc.pem
pkinit_anchors = FILE:/etc/heimdal-kdc/pkinit/ca.pem
# don't allow proxy certificates
pkinit_allow_proxy_certificate = false
pkinit_win2k_require_binding = yes

Copy ca.pem and kdc.pem to the above locations. Make sure kdc.pem is only readable by root since it contains a private key.

Setting up the user part

The client needs to know about our CA too since it needs to identify the KDC. This is setup in /etc/krb5.conf:

[libdefaults]
pkinit_anchors = FILE:/etc/ssl/certs/ca.pem

Copy ca.pem to the above location. Also copy user.pem to ~ and split out the private key part into a separate file user.key (the steps are the same as explained for the CA above). You can the test your installation with:

 $ cd ~
 $ kinit -C FILE:user.pem,user.key agx@MS20.NIX
 $ klist

 Credentials cache: FILE:/tmp/krb5cc_0
    Principal: agx@MS20.NIX

   Issued           Expires          Principal
 Jun 20 14:52:27  Jun 21 00:52:27  krbtgt/MS20.NIX@MS20.NIX

Putting things onto the smart card:

First Install opensc and make sure your smart card is recognized:

 $ opensc-tool -n
 CardOS M4 

I used an empty Aladdin eToken Pro which I wiped completely before adding the keys:

 $ pkcs15-init -E
 $ pkcs15-init -C -p pkcs15+onepin
 $ pkcs15-init --store-private-key user.key --auth-id 01 
 $ pkcs15-init --store-certificate user.pem --auth-id 01 
 # Lets see if it worked:
 $ kinit -C PKCS11:/usr/lib/opensc/opensc-pkcs11.so agx@MS20.NIX

 Credentials cache: FILE:/tmp/krb5cc_0
    Principal: agx@MS20.NIX

   Issued           Expires          Principal
 Jun 20 14:52:27  Jun 21 00:52:27  krbtgt/MS20.NIX@MS20.NIX

That's it. The steps above are quiet terse but this should get you started. Libpam-krb5 has pkinit support so you can use this during logon.

Tags: single-sign-on.
Apple Calendarser with Name Service Switch directory backend
22nd June 2008

Apple's Calendarserver uses a file based XML backend by default. This has the disadvantage that new users must be added manually and groups can't be maintained dynamically - the calendarserver needs to be restarted.

Therefore we added a simple Name Service Switch based directory service to the Debian packages - it's best to use 1.2.dfsg-4 or newer. Using this, all users known to the system via getent passwd can have calendars and group calendars can be maintained as simple groups of users. Where your system gets it's user and group information from can be configured via /etc/nsswitch.conf e.g.:

 passwd: files ldap
 group:  files ldap

looks up users and groups in /etc/{passwd,groups} and using ldap via libnss-ldap. For more details use man nsswitch.conf. All of this can be configured dynamically without the need to restart calendarserver.

Calendarserver Configuration

To enable the NSS backend in calendarserver comment out the XML File Directory Service via <!-- ... --> in /etc/caldavd/caldavd.plist then add the NSS one. This example has all the parameters you can set:

<!-- NSS directory service -->
<key>DirectoryService</key>
<dict>
    <key>type</key>
    <string>twistedcaldav.directory.nss.NssDirectoryService</string>
<key>params</key>
<dict>
    <key>realmName</key>
    <string>Your Realm</string>

    <!-- Don't treat user ids smaller than firstValidUid as calendarserver users -->
    <key>firstValidUid</key>
    <integer>1000</integer>
    <!-- Don't treat user ids larger than lastValidUid as calendarserver users -->
    <key>lastValidUid</key>
    <integer>65533</integer>

    <!-- Groups starting with this prefix are considered calendarserver groups -->
    <key>groupPrefix</key>
    <string>caldavd-</string>

    <!-- Don't treat group ids smaller than firstValidGid as calendarserver groups -->
    <key>firstValidGid</key>
    <integer>1000</integer>
    <!-- Don't treat group ids larger than lastValidGid as calendarserver groups -->
    <key>lastValidGid</key>
    <integer>65533</integer>
    <!-- use username@mailDomain as calender user mail addresses -->
    <key>mailDomain</key>
    <string>example.com</string>
    </dict>
 </dict>

The firstValidUid and lastValidUid parameters allow you to specify which users have calendars. By default uids in the range [1000,65533] are being used. This way system users like lp, mail, news backup and nobody are excluded.

Shared calendars are represented by groups of users. The group name must start with groupPrefix to avoid collisions with system users - the default is caldavd-. The members of these groups are allowed to read/write the calendar. The firstValidGid, lastValidGid have the same meaning as the uid ones above but since you already specified a prefix you normally can simply omit them.

The mailDomain parameter can be used to specify a default mail domain. In the exmaple above a user foo ends up with mail address of foo@example.com - this information is used by some clients for free busy lists and invitations.

The values above - except for the realmName and mailDomain - are the defaults build into calendarserver, so if these suite your needs you can simply skip them:

<!-- NSS directory service -->
<key>DirectoryService</key>
<dict>
    <key>type</key>
         <string>twistedcaldav.directory.nss.NssDirectoryService</string>
    <key>params</key>
    <dict>
        <key>realmName</key>
        <string>sigxcpu.org</string>

        <key>mailDomain</key>
        <string>sigxcpu.org</string>
    </dict>
 </dict>

After changing this don't forget to restart calendarserver using /etc/init.d/calendarserver restart.

Adding users and groups

Using the configuration above all users in the range [firstValidUid,lastValidUid] readily have a calendar to access at:

http://localhost:8008/calendars/users/<user>/calendar

Adding a new user is now as easy as adduser <newuser>. The calendar get's created once the user tries to access his calendar for the first time. To add a shared calendar at:

http://localhost:8008/calendars/groups/test/calendar

simply do a addgroup caldavd-test. Then simply add users to this group: adduser test <user>. To see which users can access this particular shared calendar you can use:

getent group caldav-test

and to see all shared calendars use:

getent group | grep ^caldavd-

To see which calendars a user can access look at the output of id.

Note that {add,del}{user,group} manipluate users and groups in /etc/passwd and /etc/group only. If you're using other name service switch backends like ldap or postgresql you can use the corresponding tools instead.

Limitations

User authentication currently only works using Kerberos. This is the recommended form of authentication anyways. Let me know if you have problems setting this up.

Tags: groupware, single-sign-on.
Howto wipe an Aladdin eToken you forgot the PIN for
20th June 2008

Mostly since I always forgot how to do this (this solution requires MS Windows):

Once done pkcs15-init from opensc works as expected.

Tags: single-sign-on.
krb5-auth-dialog: experimental dbus interface
13th June 2008

When you don't have a valid TGT thunderbird/icedove (2.0.0.14), and evolution (2.22.2) just fail if your SMTP/IMAP/Caldav server only allows for GSSAPI authentication. While thunderbird tells you to turn off secure authentication - brilliant idea, evolution just says "error while refereshing folder" in the status bar - quiet user friendly.

Therefore I added a simple dbus interface to krb5-auth-dialog so that these applications can ask it to acquire the TGT for them. Thanks to the dbus glib bindings the code an application that want's a ticket needs to use is as simple as:

#include "krb5-auth-dialog-dbus-client-glue.h"
...
proxy = dbus_g_proxy_new_for_name_owner (connection,
                                    "org.gnome.KrbAuthDialog",
                                    "/org/gnome/KrbAuthProvider",
                                    "org.gnome.KrbAuthProvider",
                                    &error);
org_gnome_KrbAuthProvider_acquire_tgt(proxy, "me@EXAMPLE.COM", &success, &error);
if (success)
     printf("Acquired TGT for %s\n", principal);

Currently you can only request a TGT for a principal krbt-auth-dialog knows about (either your username in the default realm or the one you set via gconf) since we don't do principal switching within krb5-auth-dialog yet. But this should do the trick already for most usage cases. A full example application is in helpers/krb5-auth-helper.c. This can readily be used in shell scripts:

cat <<EOF >evo-krb5
#!/bin/sh -e
krb5-auth-helper me@EXAMPLE.COM && evolution

Since the dialog only pops up if you don't have a valid TGT already the password dialog will only get into your way when needed. It would be nicer if those applications would use this interface directly now that it's there.

As usual you can clone from:

git clone http://honk.sigxcpu.org/git/krb5-auth-dialog.git

Make sure you build the dbus branch: git checkout --track -b dbus origin/dbus mkdir build && cd build && ../autogen.sh && make && sudo make install

Tags: single-sign-on.
git-buildpackage 0.4.31
12th June 2008

Nothing earth shaking in this release:

''--git-tag-only'' allows you to create a tag without having to build the whole project again - useful for large packages. You can either clone from:

git clone http://honk.sigxcpu.org/git/git-buildpackage.git/

or fetch the package from the Debian Archive once it went through the new queue. The updated documentation is available here

Tags: debian, git.
another krb5-auth-dialog update
8th June 2008

Krb5-auth-dialog now uses the GtkSecureEntry widget taken entirely from GPG's Pinentry. This nice widget uses the memory methods from secmem (also in Pinentry) and removes potentially dangerous methods such as copy and paste. This should make typing your password into krb5-auth-dialog a lot safer. You can clone from:

git clone http://honk.sigxcpu.org/git/krb5-auth-dialog.git

Hopefully GtkSecureEntry gets split out of Pinentry so it can be easier used by others (#485056).

Tags: single-sign-on.
krb5-auth-dialog updates
6th June 2008

krb5-auth-dialog (a simple app that monitors Kerberos tickets) now has a tray icon. This allows you to refresh your TGT or destroy the ticket cache any time you want. It also gives visual feedback on the state of your ticket and uses libnotify to notify about expiry/refresh.

valid ticket ticket expired

It interfaces with gconf to store the default principal, the time of the first password prompt and the trayicon's visibility:

gconftool-2 --type=string --set /apps/krb5-auth-dialog/principal "principal@YOUR.REALM"
gconftool-2 --type=int --set /apps/krb5-auth-dialog/prompt_minutes 30
gconftool-2 --type=bool --set /apps/krb5-auth-dialog/show_trayicon false

So overall it behaves more or less like a regular gnome application now. You can use:

git clone http://honk.sigxcpu.org/git/krb5-auth-dialog.git

to get the current version. The code is based on krb5-auth-dialog from Gnome SVN. I hope to get the above changes integrated there soon.

Tags: single-sign-on.

RSS Feed