Thursday, February 13, 2014

Introducing Cockpit

Gave a talk at DevConf in Brno about the project a bunch of us have been working on: Cockpit. It's a UI for Linux Servers. Currently in the prototype stage...

Hopefully there'll be a video of the talk available soon. You can try out the Cockpit prototype in Fedora like so:

 # yum install --enablerepo=updates-testing cockpit
 # setenforce 0 # issue 200
 # systemctl enable cockpit-ws.socket
 $ xdg-open http://localhost:21064

Don't run this on a system you care about (yet). Sorry about the certificate warning. Groan ... I know ... working on that.

Needless to say I'm excited about where this is going...

Friday, August 16, 2013

More secure with less "security"

At GUADEC in Brno, I gave a talk about usability and security prompts.

The video and slides is now online. I'm really impressed with how fast the videos became available this time around.

Tuesday, December 18, 2012

git-coverage: Useful code coverage

I've sorta dabbled in using code coverage off and on, but it never really grabbed me as super useful and fit well within my workflow.

When hacking on open source I want to try out patches, run tests against them, whether automatic unit tests or manually diddling things during testing. What I'm really interested is whether I tested out all the bits of the patch.

Traditional coverage tools tell you about the coverage of the whole project, which you then have to update and dig through to see if your changes were covered. I really don't care about the code coverage of entire projects. This is especially true if I'm just a contributor of a few patches. I want to see the coverage of the stuff I just changed.

Anyhooo ... after much ongoing grumpiness ... I put together git-coverage which is a git plugin which you can use to look at a patch and see which code paths have been run. Basically you use it exactly like you would git diff but it highlights the code in the diff that didn't have coverage. Works with Python, C and C++ code so far.

To use with C or C++ code, you need to build the project using gcc's --coverage info. Something like this:

$ CFLAGS='--coverage' ./configure ...
$ make clean all

Next you make some modifications to the code, rebuild, and run the tests or code. Now the following command will tell you which of your changes were covered.

$ git coverage

Any lines that start with an exclam have no coverage. They're highlighted in red if you have git coloring enabled. If there's no output from the above command, then all lines have coverage. Similar to how if nothing has changed, diff will output nothing.

If you've already checked in your code then you would use the following command to test the coverage of the last commit, similar to how you might use git diff to show the last commit.

$ git coverage HEAD~1

Or you can test coverage of the last N patches by doing stuff like:

$ git coverage HEAD~3..

Normally git-coverage tries to check the coverage of lines surrounding the changes. If you want to suppress this, you just pass in diff options to narrow the diff down:

$ git coverage --unified=0

To install git-coverage put it somewhere in your path. You might use:

$ git clone git://
$ cd git-coverage
$ ln -s $PWD/git-coverage ~/.local/bin

To use with Python code, install the python-coverage package, and run your code or tests like this:

$ # Yup, python-coverage has a rather bold command name.
$ coverage run /path/to/python-code args ...
$ git coverage

Anyway, maybe this'll help someone. It's an itch I've had for some time.

BTW, Phillip put some code into gnome-common which you can use to add --enable-code-coverage to your configure script, and optionally get full coverage reports for the project. Obviously also works with git-coverage.

Friday, August 3, 2012

How to create an Active Directory domain to test against

Many interested people want to help test the Active Directory work and bug fixes we've been doing. But sadly there's no public Active Directory servers that I know of. So here's how to setup a virtual machine with your own Active Directory. It's not that hard.

1. Preparation

  • Each Active Directory has a unique domain name. Choose one. You can choose a subdomain of a domain you own, or one that's completely made up. I chose borg.thewalter.lan
  • Download the evaluation edition of Windows 2008 R2 Enterprise server. Click the Get Started button at that link to download it. The evaluation edition is valid for 180 days. You should end up with an ISO file named something like: 7601.17514.101119-1850_x64fre_server_eval_en-us-GRMSXEVAL_EN_DVD.iso
  • We'll be using virt-manager in this tutorial, so install virt-manager, libvirtd, qemu and all their dependencies.

2. Create a virtual network

  • The Active Directory server will need a static IP address. The default virtual network configured by libvirtd does not have any space for a static IP address, so we need to create a new virtual network.
  • Start virt-manager and make sure you're connected to the localhost (QEMU) connection.
  • Click on localhost (QEMU) and choose Edit > Connection Details from the menu.
  • Choose the Virtual Networks tab in the dialog that pops up and click the add button.
  • Use settings like:
    Network Name: ad
    Enable DHCP: checked
  • Notice that we left some space between the start of the netblock and the first DHCP allocated address. Actually virt-manager does this by default for added virtual networks like this one.
  • You probably want to Forward (via NAT) to your physical network. That makes it easier to activate windows later and get updates.
  • Complete the wizard and you're done.

3. Create a new virtual machine

  • In the main virt-manager window, click the create button in the toolbar to create a new virtual machine.
  • Type the domain name you chose above as the virtual machine Name.
  • Choose Local install media and when prompted select the ISO image you downloaded above as the install media.
  • Set OS type to Windows, and Version to Microsoft Windows Server 2008.
  • 512 MB of memory is enough, 1 CPU is enough. Feel free to set these higher if you like.
  • Create a new virtual disk with at least 10 GB of disk space.
  • On the last page of the Create a new virtual machine dialog, expand the Advanced options section and choose the network you created above.
  • Complete the dialog and the virtual machine should be created. Then the Windows install should begin.

4. Windows Server install

  • Choose whatever keyboard and language you want on the first dialog of the install.
  • On the next page choose Install now.
  • A list of types of Windows Server installs should show up. Choose Windows Server 2008 R2 Standard (Full Installation) and go to the next page.
  • Read and accept the license.
  • Choose Custom (advanced) when prompted how to install Windows.
  • Select the disk to install Windows on. There should only be one choice which is the virtual disk you configured when you created the virtual machine.
  • Windows Server will proceed to install, and will reboot a couple times in the process.
  • Once the system is ready, you will be prompted to change the Administrator password. This is actually setting the password for the first time. This is the password for the Administrator account on the server itself, not the administrator of the Active Directory domain, which you'll set later. You can use the same password for both, since this is a test install.
  • If all goes well you should be logged into your new server at this point. A bunch of helpful windows will pop up, but you don't need to do anything with them.

5. Set the IP address

  • An Active Directory server acts as an LDAP and DNS server, and needs a static IP address.
  • Click Start > Network, and then click the Change adapter settings link in the window that comes up. Another window should appear.
  • Right click on the Local Area Connection item and choose Properties in the menu.
  • Click on the Internet Protocol Version 4 (TCP/IPv4) item and then click the Properties button. A dialog for setting the addresses comes up.
  • Choose Use the following IP address. Then set the relevant fields. The settings here are based on the virtual network you created above, if you used a different netblock then modify as appropriate:
    IP Address192.168.12.10
    Subnet mask255.255.255.0
    Default gateway192.168.12.1
    Preferred DNS Server:
  • Click OK or Close in the various dialogs to complete things.

6. Set the machine name

  • An Active Directory server should have a well known DNS name, you don't need to set it in DNS, but just name the server appropriately and then Active Directory will do the rest.
  • Click Start > Computer, and a window should come up.
  • In the left pane of the window, there's an item called Computer. Right click on it and choose Properties from the menu. Another window should show up.
  • Click Change Settings, and a dialog will come up.
  • In the Computer Name tab click the Change... button, which displays another dialog.
  • Set DC as the Computer name or another name of your choice. Don't worry about the Member of Domain or Workgroup stuff yet.
  • Click OK and/or Close to complete the changes. You'll be prompted to restart, so go ahead and do that.

7. Setting up Active Directory

  • Click Start > Run and type DCPROMO in the dialog that comes up.
  • A progress window will come up which explains about installing some components. This takes a while.
  • A wizard will eventually show up. Click through the introduction and warnings.
  • Choose Create a new domain in a new forest.
  • On the next page enter the domain you chose earlier, like borg.thewalter.lan
  • Choose the Forest functional level. You can choose whichever one you like. Choosing 2008 R2 is a decent choice. You can test against various Active Directory servers with different levels to simulate different domains you might encounter in the wild.
  • Make sure DNS Server is chosen on the next page.
  • Once you complete that, a dialog will come up warning you about how the DNS delegation cannot be created. We'll do that manually below, so this is nothing to worry about. Choose Yes.
  • Leave the default paths for database and log files.
  • Choose a domain Administrator password. Logically this is different from the local server Administrator account you set the password for above. But you can use the same password to keep things simple.
  • Review the selections if you're interested, and then click Next to complete things.
  • Wait for a while for installation and configuration, Finish. 
  • You'll need to Restart Now.
  • The reboot after installing Active Directory will take a while as it does a bunch of stuff on the first boot.

8. Setup DNS to work with Active Directory

  • Back on your linux box you'll want to be able to connect to Active Directory. To do this you need to setup DNS. Active Directory comes with its own DNS server, you just need to tell your local host where it is. To do this we'll install a local caching name server.
  • Install bind. If you're on Fedora you can use a command like: 
    # yum install caching-nameserver
  • After the install completes, edit /etc/named.conf and add the following line to your main options section:
    forwarders {; /* ... or the address of your ISP DNS server */ };
  • And add this to the end of /etc/named.conf. Modify for your domain name or server static IP address assigned above:
    zone "borg.thewalter.lan" {
            type stub;
            masters {; };
  • Restart the named service with: # systemctl restart named.service
  • Before configuring your host to use the local caching nameserver, test it with commands like:
    # host borg.thewalter.lan
    # host dc.borg.thewalter.lan
    # host
  • Once you know it's working, use nm-connection-editor to edit your connection. Choose your connection, and on the IPv4 Settings tab, choose Automatic (DHCP) addresses only. Now set as the DNS servers.
  • You should now be able to test you local server with commands like:
    # host borg.thewalter.lan
    # host dc.borg.thewalter.lan
    # host

9. Test the Active Directory domain works

  • On your host linux box you should now be able to get a kerberos ticket.
  • If you have a custom configured /etc/krb5.conf, you may need to remove or move it. There is no real need for this file with a modern kerberos domain like Active Directory.
  • Run this command. Make sure the domain is upper case here:
    $ kinit Administrator@BORG.THEWALTER.LAN
  • You'll be prompted for the domain Administrator password. The one you typed in the Setting up Active Directory step above.
  • If successful kinit will show no output. You can use the klist command to see your ticket.
That's it. You're done. 

You can add additional Active Directory users via the Active Directory Users and Computers tool in the Administrative Tools section of the Start menu in the Windows Server virtual machine.

You may be prompted to Activate your Windows install. You won't need any special information or keys or anything. Just go ahead with it. The install you have is valid for 180 days, and will say in the lower left corner how long you have left.

Friday, June 15, 2012

Kerberos and Active Directory Logins

Ray and I and some others have been working on making it easy to use Kerberos single sign on with GNOME 3.6. The feature itself isn't super revolutionary. You sign in with your realm login (eg: your Active Directory user name and password) and then you can go on and use other services with that same kerberos sign in.

You could already do this, but setting it up was hard ... and setting it up so it couldn't be trivially hacked was even harder. If you just use pam_krb5 without 'enrolling' your machine an attacker can log in as anyone (woooooo). ... and keeping it running without breaking down on you was even harder than that, especially for mobile environments.

So I've been working a lot on making this easy to setup; auto discovering the domain/realm, its settings and as much information as possible. Last week some user visible changes landed into gnome-control-center so here are some screenies.

You'll notice the new Enterprise Login mode of the Add account dialog:

It lets you add users from an Active Directory domain or FreeIPA (soon) realm, and perhaps others in the future.  Any domains we already know about are in the drop down. If this is the first time you're using the feature, we try and automatically discover the domain from your DHCP DNS domain name. We automatically discover what kind of realm/domain we're dealing with, all the other settings, and whether it's valid or not.

Login details for the user are typed in, and then we bonk the Add button:

We try to be intelligent about validation and give good feedback:



If the domain requires administrative credentials to enroll the local machine, then we prompt for those. Active Directory on Windows 2003 and later don't require admin creds by default. FreeIPA does.

And voila, the user is added. Only the users specifically added should be able to log in; there's actually a bit of work to do on that, but that's the plan. If an admin wants to enable any domain user to log in on the machine, then they can enroll the machine using the command line or admin tools. Both are supported, just not both in gnome-control-center.

Here I added two users, Fry and Leela. Not sure why one of them showed up with their full name and the other not. Something to fix...

Under the hood a the enrollment in realms is managed by a small DBus on-demand system service called realmd. realmd can also be driven using command line tools, which expose additional options.

It was important to me to make sure that the diagnostics are clear. So many of these tools throw up cryptic error messages without anywhere to go to figure out 'Why?'. So we try hard to have user visible error messages, and then very clear diagnostic output on the console when performing these operations, that looks like:

 * Looking up our DHCP domain
 * Searching for kerberos SRV records for domain:
 * Searching for sub zone on domain:
 * Found AD style DNS records on domain
 * Successfully discovered realm: AD.THEWALTER.LAN

Hmmm, what else ... Ray's been working on other parts of this: fixing the user accounts panel so it makes sense for non-local users. And making sure that the Kerberos tickets we get at login are correctly renewed and reauthenticated.


These guys. Props to the SSSD guys. They've been working hard to make that daemon the perfect client for Kerberos/IPA/AD. It's a modern clean implementation, and makes stuff like using your domain login when not attached to the domain really reliable and easy.

No mo' NTP Time Syncing

I've been running around the kerberos stack trying to fix issues that cause configuration problems, fragility or just plain nastiness. For example:

For decades now kerberos implementations have pretty much required you to sync your time up with the kerberos server. It makes you roll your eyes that a security protocol relies so much on time for security, when the syncing of that time is almost always insecure. But oh well.

Anyway, for the good news. 15 years ago these guys figured out how to do kerberos without time syncing. And bit by bit their ideas have made it into kerberos implementations, but nobody new about it because the there were tons of fiddly bits that made assumptions about time syncing. I did a few last patches to sort out some issues, which have been accepted by MIT Kerberos.

Anyway, that was long enough, there's lots more, but it's starting to get boring ...

Lots of patches are being merged as we speak, but if you want to test this stuff out right now, ping me on IRC #gnome-os on gimpnet, and I'll help you get started.

Oh and see you at GUADEC.

Friday, October 28, 2011

VMWare Player on Fedora 16

I have some VMWare VM's I've been using here and there. I probably should convert them to Virtual Box, but I've had a rough time getting that working as well.

So ... every time you upgrade the kernel, VMWare barfs because kernel headers have changed. Usually I look around for patches to the VMWare sources, but this time there were none I could find, so I figured it was my turn.

This simple patch makes VMWare Player 4.0.0 work with Linux 3.1.0. At least it seems to work. What I did to patch it in:

$ mkdir /tmp/vmware
$ cd /tmp/vmware
$ wget
$ tar -xvf /usr/lib/vmware/modules/source/vmnet.tar
$ patch -p0 < vmnet-4.0.0-linux-3.1.0.patch
$ sudo cp /usr/lib/vmware/modules/source/vmnet.tar /usr/lib/vmware/modules/source/vmnet.tar.bak
$ sudo tar -cvf /usr/lib/vmware/modules/source/vmnet.tar vmnet-only

And then run vmplayer and let it do its install thing. It says that the services fail to start (systemd incompatibility), but it works regardless.

Note: If you try this and it doesn't work for you (or makes your doggy sad), don't complain to me. Complain to VMWare.

Monday, October 17, 2011

Redesigning the Seahorse Experience

As part of the work on getting smart cards into Seahorse, there's some design work that needs to be done to make the new functionality usable. In particular, the overarching design goal is that Seahorse isn't a tool we expect users to "learn". Actions should follow mostly from the passwords and keys that have been accumulated.

So I've been working on the experience a bit. Some concepts:

  • When most user's arrive, they should see their personal passwords, and keys or certificates if they have any listed. In this mode we combine items from all the various places these things are stored.
  • The user sees a certificate regardless of it's on a smart card, Gnome Keyring, or in NSS's store.
  • Each item should have an icon, and text describing what it is.
  • By default only 'personal' passwords and keys are shown. Those belonging to the user. So things like Trusted Root CA's don't litter the combined listing. This is easily changed on the 'View' menu.
  • The list is easily filterable by typing in the box.
  • We make sure to unlock the default password keyring when seahorse is started. Normally it's unlocked already, but just in case.
A screenshot (the toolbar needs some work): 

So the experience starts off really straight forward, no need to clutter things with where these items are coming from. If the user has a smart card inserted, the certificates and keys on the smart card will also show up there.

In order to see and manage stuff related to where the keys come from, the user chooses 'View | Places' from the menu. A sidebar appears, which supports the following concepts:

  • Click on a place to view items from a that 'place'.
  • See which keyrings exist, delete, change master passwords etc.
  • See smart cards that are inserted.

A screenshot (the places need some tweaking):

Something I've also been playing with is an easy to use multiple selection. For example I'd like the user to be able to select multiple places (let's say all the password keyrings), and see their items together.

I wanted to do something where check boxes are shown to the right of each 'place' when the Alt-key is depressed. The user then would click those checkboxes to select multiple places, and show their items together. Once one box is checked, all check boxes remain visible. This fits in with the concept of showing keyboard mnemonics when Alt is pressed, and also GNOME seems to be using a show-advanced-shortcuts-on-Alt-key concept here and there, and I thought this would fit nicely. However, sadly the window manager grabs the mouse when Alt is held down, for the purpose of full window drags, so I had to think of something else.

What I came up with was that a check box is shown next to a place when that place is selected and focused. If the user clicks that check box, then all the check boxes next to the other places become visible, and more than one can be selected. As long as one is checked, all the check boxes are visible. Works well enough, and should work with touch devices as a bonus. But I'm not as satisfied as I would have been with the Alt concept.

Of course this is an advanced feature, and not necessarily something that needs to be super 'beautiful' but none the less it was interesting to try out these alternatives.

There's lots more design work that needs to be done. For example, I'd also like to integrate the new control center style 'Unlock' button in a way that makes sense. It gets complicated because there's more than one thing to unlock (ie: smart cards, password keyrings, etc.)

Most of this is done in such a way that the pieces can be reused elsewhere in other apps as well. Available right now in the seahorse refactor branch and depends on an up to date build of the Gcr library. Hopefully I'll be merging this into seahorse master soon.

Oh, and thanks to NLnet for sponsoring Collabora to work on the Seahorse smart card support.