alaux.net

Skype is the most used voip software used accross the world. Unfortunately when you dig a bit about it you may find yourself surprised with its developers' way of understanding the word "privacy". Reports have been made about Skype binaries reading sensitive Linux password files and user personal data. As Skype is the perfect example of closed source application one cannot even know if these statements are true. Moreover, it seems Skype makes heavy use of obfuscation methods. It just so happens an Archer explained this simple way of jailing Skype into a reserved Linux account.

The idea is very simple: create a skype group and a skype user with its own home directory. Then just setup your regular user to launch the skype binary as this user using sudo. If you grant this skype user restricted rw rights, this will elegantly jail this impolite Skype software.

Remote desktop connections with VNC is very useful when you need to help regular users stuck on their desktop environment. Gnome provides vino-server and its client side vinagre as VNC implementations. But vino is not fully secured. The password check between client and server looks OK but once the connection is made, the stream between the two is not encrypted. Using it through internet may be risky so why not tunnel it all through SSH?

Pros and cons

Pros:

• Harden vino authentication
• Encrypt stream between client and server

Cons:

• A little bit geeky I agree but hey you are still reading!

How to procede

First of all we need to install vino an openssh on the server and vinagre and openssh on the client (Debian/Ubuntu users must be careful there: we need OpenSSH server part on the server and on the client side we need both the client and the server part). Archers can run:

On the server side:

$ pacman -Sy vino openssh

On the client side:

$ pacman -Sy vinagre openssh

We are then going to setup the server side: vino. This can be done with vino-preferences: allow connections, and specify a password (this is optional as we will tunnel everything).

On the 'client' side, we need to forward some SSH to our host (here specified as the variable ${REMOTE_HOST}):

$ ssh -C -NL 9999:localhost:5900 ${REMOTE_HOST} &

• -L: paramater for port forwarding from on port 9999 on localhost and forward it to port 5900 to REMOTE_HOST. Port 5900 is the vino default port. Port 9999 can be changed to any port you are allowed to use
• -N do not execute a remote command (ie "you do not get a prompt on the remote machine")
• -C: compress data (optional)

On the client side we can now launch any VNC client and connect to localhost:9999. With vinagre this would be:

$ vinagre ::9999

You now should be prompted for your password if you set one up on the previous step. The client side may also be prompted for a connection authorization depending on what you configured. Click OK and you should see your remote desktop on a window.

Last but not least, let's prevent connections to vino-server on the remote side from other places than localhost. It seems this option used to be available in vino-preferences but it disappeared in the latest versions. We are thus goinf to use dconf-editor to setup this:

$ dconf-editor

Navigate the tree to the leaf desktop/gnome/remote-access and set value network-interface to lo. This network interface is of course the localhost you can see when issuing ifconfig lo.

There. You might need to re-login or at least restart /usr/lib/vino/vino-server for these last options to take effects. Once done you should get your fully secured VNC connection tunneled to SSH.

Note: Do not forget to kill the port forwarding after you are done using vinagre.

For automation, here is a script summarizing the client side:

#!/bin/bash
LOCAL_PORT=9999
REMOTE_HOST=192.168.1.21
REMOTE_PORT=5900

echo "Opening SSH tunnel"
# Do not use '-f' because '&' already forces background
# '-f' disables PID retrieval
ssh -C -NL ${LOCAL_PORT}:localhost:${REMOTE_PORT} ${REMOTE_HOST} &
SSH_PID=$!
echo "Connecting to ${REMOTE_HOST}"
vinagre ::${LOCAL_PORT}
kill ${SSH_PID}

General overview for the impatients

In this article I first use cryptsetup to create a regular crypted partition. It needs to have the Linux users password as key to (un)lock the partition. I then use a pretty neat tool called pam_mount. This PAM module enables volume mounting and decrypting at login.

Pros

• Quite simple to set up and pretty KISS
• Usefulness of encrypted partitions but without the hassle of typing multiple passwords
• Completely transparent for user

Cons

• Using Linux users passwords as uncrypting passphrase may be seen as a flaw in the security of your box because your session password (thus your uncrypting passphrase) is stored in /etc/shadow. This file resides in your root partition which, in this method, must not be crypted. See the ending comment for a "solution".
• Any user password change will need to be "applied" to this setup. ie removing the password from the luks keyring and adding the new one.
• Will only work for 8 different users as all users passwords must be able to unlock the crypted parition and luks only allows 8 different passwords on its keyring.

With these pros and cons, I must say this solution suits me well: a single user on a laptop (with no real sensitive data) who knows how to modify a key on the unlocking keyring when changing the session password. So let's get started.

Warning

• This howto is made for GDM but with few adaptations it should work for any kind of login manager.
• I use pam_mount which is provided in Arch Linux in AUR aka "Not officially supported". Paranoid users should check the PKGBUILD (and the sources ;)).
• For this to work you will have to use the same locking passphrase for your partition as the one used when login to your Linux account.
• In this howto I encrypt my home partition (/dev/sda4) but of course one could unlock/lock any other EXCEPT ROOT.

How to procede

The first step when crypting a partition is to backup your data as this will erase it all on the target partition. The second step beeing to properly erase all data on the parition (why and how to do so).
To create a crypted partition, let's be sure that we have all the tools in that intention:

    % pacman -Qs
    local/cryptsetup 1.3.1-2 [0.50 MB] (base)
        Userspace setup tool for transparent encryption
        of block devices using the Linux 2.6 cryptoapi

Cryptsetup belongs to the "base" group in Arch Linux so you should be fine but otherwise just "pacman -Sy cryptsetup". Now let's load the kernel modules depending on your architecture:

    modprobe dm-crypt aes-i586

or

    modprobe dm-crypt aes-x86_64

We are then going to create a regular crypted partition. I usually use the following command for that purpose but any other cypher, keysize etc would work. This will ask you for the passphrase you want to use in order to crypt/decrypt your partition. As already said, you NEED to specify here the same password as the one for your Linux account. Change /dev/sda4 with your partition:

    cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda4

Also remember that in order for other accounts to still be able to unlock this partition, you need to add all Linux account passwords as keys to unlock the partition. This is made possible through the following command. To be done for all Linux account passwords. Beware that the fist password asked here is the master password you supplied in the previous step:

    cryptsetup luksAddKey /dev/sda4

Let's open the newly created partition:

    cryptsetup luksOpen /dev/sda4 home

You should be able to see the mapped device:

    ls /dev/mapper/home

Create a filesystem on it (such as ReiserFS in this example or any other):

    mkfs.reiserfs /dev/mapper/home

There! We have an encrypted partition. Now let's get it opened/closed and mounted/unmounted at login time.

For that matter we will need pam_mount from AUR that enables volume mounting at login:

    yaourt pam_mount

Add the following line to /etc/fstab (notice the "noauto". We just declare it but ask it not to be mounted. Also be sure to specify the filesystem you used instead of 'reiserfs' if required):

    /dev/mapper/home  /home  reiserfs  defaults,noauto  0  0

Add the following line to /etc/security/pam_mount.conf.xml with the corresponding path:
<pam_mount> ... <volume fstype="crypt" path="/dev/sda4" mountpoint="/home" /> ... </pam_mount>
Add the following lines to /etc/pam.d/gdm (and/or /etc/pam.d/login to perform encryption when on console):

    ...
    auth    optional    pam_mount.so
    ...
    session optional    pam_mount.so
    ...

There! Just reboot and enjoy your fully automated encrypted home opening when you log in. If that fails well... then you can't login so there should not be any complaint ;)

Explanation

At login time, gdm uses pam to authenticate the user. PAM will check all modules we asked it to "activate" when GDM asks for login (/etc/pam.d/gdm). PAM will thus launch pam_mount which opens and then mounts our encrypted partition.

More

As said in the introduction, using Linux users passwords as uncrypting passphrase may be seen as a security hole because your these passwords are stored in /etc/shadow. This file resides in your root partition which in this method must not be crypted. A possible hardening of this is just to use SHA passwords in /etc/shadows.

HTMLUnit est une extension de JUnit qui propose de tester une application live, c'est à dire en permettant au développeur d'exécuter des tests d'application de bout en bout. Ce framework se décrit comme un navigateur web sans interface puisqu'il offre la possibilité d'appeler les éléments HTML de pages et ainsi de simuler une navigation. Le développeur peut donc remplir des formulaires, cocher des checkbox, renseigner des champs et ensuite simuler un clic sur un bouton, un lien ou valider un formulaire.

HTMLUnit peut être directement utilisé comme une extension de JUnit. Pour ce faire, il suffit d'inclure les JARs nécessaires dans le CLASSPATH pour avoir accès aux fonctionnalités de test web. Ci-après un exemple dans lequel on retrouve l'annotation @Test qui témoigne de l'utilisation de JUnit. Celui-ci invoque une page via la classe WebClient et en vérifie le nom ainsi que certains éléments constitutifs.

@Test
public void homePage() throws Exception {
  final WebClient webClient = new WebClient();
  final HtmlPage page =
    webClient.getPage("http://htmlunit.sourceforge.net");
  assertEquals("Welcome", page.getTitleText());

  final String pageAsXml = page.asXml();
  assertTrue(pageAsXml.contains(""));

  final String pageAsText = page.asText();
  assertTrue(pageAsText.contains("Support for HTTP(S)"));
}

À la vue de cet exemple, on comprend les possibilités d'un tel outil : test de disponibilité, test de présence de certains éléments (techniques ou fonctionnels) mais aussi vérification du caractère bien formé d'une page HTML/XML. HTMLUnit pousse la technique jusqu'à simuler un navigateur spécifique. Cette possibilité n'est pas superflue quand on connait le respect très variable de la norme HTML des différents navigateurs du marché.

Le parti pris de HTMLUnit de traiter avec la partie présentation est intéressant car il teste la pile complète de l'application et cela au plus près du résultat visible par l'utilisateur. Cela implique cependant que l'application complète soit démarrée et disponible pour être testée, ce qui peut s'avérer lourd à prendre en charge.
Le framework offre beaucoup de possibilités de tests mais attention à ne pas se perdre à tester trop d'éléments HTML inutiles. Écrire les tests de pages HTML avec ce type d'outil reste fastidieux. Pour y pallier, il existe des outils de plus haut niveau comme JWebUnit, WebDriver ou JSFUnit (voir la suite) qui s'appuient justement sur HTMLUnit.

JSFUnit quant à lui est le concept de test de la partie présentation telle que vue par HTMLUnit (vu au paragraphe précédent) appliqué à JSF.
Les tests JSFUnit sont - comme tous les tests JUnits – des méthodes d'une classe Java. Dans le cas particulier de JSFUnit, il est nécessaire que cette classe hérite de ServletTestCase afin de lui faire prendre en compte la spécificité Servlet de JSF. Une fois les JARs de JSFUnit intégrés au CLASSPATH, il est possible d'utiliser les classes du framework et ainsi de tester les Managed Beans, la navigation de page en page, les composants visuels, les résultats de sortie ainsi que la configuration de l'application. L'exemple suivant du site officiel montre le test de la page de présentation d'une application :

public class JSFUnitTest extends ServletTestCase
{
  public static Test suite()
  {
    return new TestSuite(JSFUnitTest.class);
  }

  public void testInitialPage() throws IOException
  {
    // Send an HTTP request for the initial page
    JSFSession jsfSession = new JSFSession("/index.faces");

    // A JSFClientSession emulates the browser
    // and lets you test HTML
    JSFClientSession client = jsfSession.getJSFClientSession();

    // A JSFServerSession gives you access to JSF
    JSFServerSession server = jsfSession.getJSFServerSession();

    // Test navigation to initial viewID
    assertEquals("/index.jsp", server.getCurrentViewID());

    // Assert that the prompt component
    // is in the component tree and rendered
    UIComponent prompt = server.findComponent("greeting");
    assertTrue(prompt.isRendered());

    // Test a managed bean
    assertEquals("Stan",
                 server.getManagedBeanValue("#{foo.text}")
                 );
  }
}

Afin de pouvoir lancer ces tests, il est nécessaire d'inclure dans le fichier web.xml les lignes suivantes :

<filter>
  <filter-name>
    JSFUnitFilter
  </filter-name>
  <filter-class>
    org.jboss.jsfunit.framework.JSFUnitFilter
  </filter-class>
</filter>

<filter-mapping>
  <filter-name>
    JSFUnitFilter
  </filter-name>
  <servlet-name>
    ServletTestRunner
  </servlet-name>
</filter-mapping>

<filter-mapping>
  <filter-name>
    JSFUnitFilter
  </filter-name>
  <servlet-name>
    ServletRedirector
  </servlet-name>
</filter-mapping>

<servlet>
  <servlet-name>
    ServletRedirector
  </servlet-name>
  <servlet-class>
    org.jboss.jsfunit.framework.JSFUnitServletRedirector
  </servlet-class>
</servlet>

<servlet>
  <servlet-name>
    ServletTestRunner
  </servlet-name>
  <servlet-class>
    org.apache.cactus.server.runner.ServletTestRunner
  </servlet-class>
</servlet>

<servlet-mapping>
  <servlet-name>
    ServletRedirector
  </servlet-name>
  <url-pattern>
    ServletRedirector
  </url-pattern>
</servlet-mapping>

<servlet-mapping>
  <servlet-name>
    ServletTestRunner
  </servlet-name>
  <url-pattern>
    ServletTestRunner
  </url-pattern>
</servlet-mapping>

Une fois l'application déployée, il est possible de lancer les test via une page de celle-ci. Le site officiel donne un exemple en utilisant un rapport Cactus :

De même que HTMLUnit, l'avantage de ce genre de framework est de tester et d'utiliser l'application de bout en bout. On ne teste plus de petites parties mais bien l'application dans sa totalité. Cette aspect a les défauts de ses qualités : il est nécessaire de conserver une application complète démarrée pour pouvoir effectuer les tests.

Les possibilités de tests sont de plus nombreuses. Ce qui peut paraître ici comme un avantage peut aussi constituer un inconvénient au développeur : il peut se retrouver perdu au milieu de pages Jsp qu'il serait tenté de tester dans leur intégralité. En cas d'adoption d'un tel outil, il est donc nécessaire de borner les tests à certains éléments précis, au risque de voir les développeurs se perdre dans des lignes de code de tests inutiles.

JSFUnit étant une extension de HTMLUnit pour JSF, il sera plus adapté pour tester les applications JSF.

Article publié sur LinuxFr dans le cadre de mon activité professionnelle à Linagora.

Dans le domaine du développement, et particulièrement le développement Java, les outils Open Source sont très largement utilisés en entreprise. Quand il s'agit de mettre en place des tests unitaires en Java, le nom de JUnit revient souvent. Même si quelques alternatives ont vu le jour (en particulier TestNG), ce framework reste le leader dans son domaine.

Pour ceux qui utilisent déjà JUnit, voici deux outils complémentaires qui en facilitent l'emploi : DBUnit et Jailer.

DBUnit
DBUnit est une extension de JUnit dont la tâche principale est de gérer des jeux de données qui seront retournés comme s'ils étaient le résultat d'une requête sur la base de données. Le premier avantage est de maintenir l'indépendance du code des tests vis-à-vis de la base de données réelle. Ensuite, DBUnit garantit que tous les tests unitaires retrouveront la base de données dans le même état et non dans l'état dans lequel le test précédent a pu la laisser.

Les jeux de données de DBUnit sont conservés sous forme XML. La première étape à son utilisation est donc de constituer les fichiers XML qui contienent les données (On pourra se référer au paragraphe suivant qui traite d'une méthode d'automatisation de cette étape). Voir ci-après un exemple de fichier XML de données :

<!DOCTYPE dataset SYSTEM "dataset.dtd">
<dataset>
    <table name="TEST_TABLE">
        <column>COL0</column>
        <column>COL1</column>
        <column>COL2</column>
        <row>
            <value>row 0 col 0</value>
            <value>row 0 col 1</value>
            <value>row 0 col 2</value>
        </row>
        <row>
            <null/>
            <value>row 1 col 1</value>
            <null/>
        </row>
    </table>
    <table name="SECOND_TABLE">
        <column>COLUMN0</column>
        <column>COLUMN1</column>
        <row>
            <value>row 0 col 0</value>
            <value>row 0 col 1</value>
        </row>
    </table>
    <table name='EMPTY_TABLE'>
        <column>COLUMN0</column>
        <column>COLUMN1</column>
    </table>
</dataset>

Comme les autres frameworks de test, DBUnit nécessite d'inclure ses JARs dans le CLASSPATH pour accéder aux classes natives. Le codage même d'un test passe ensuite par l'habituel héritage de la classe mère (ici DBTestCase). La première action à entreprendre est d'initialiser les propriétés de la base de données que DBUnit simulera puis d'y attacher le fichier XML de données précédemment créé comme dans l'exemple suivant :

public class SampleTest extends DBTestCase
{
    public SampleTest(String name)
    {
        super( name );
        System.setProperty(
            PropertiesBasedJdbcDatabaseTester
                .DBUNIT_DRIVER_CLASS,
            "org.hsqldb.jdbcDriver");
        System.setProperty(
            PropertiesBasedJdbcDatabaseTester
                .DBUNIT_CONNECTION_URL,
            "jdbc:hsqldb:sample");
        System.setProperty(
            PropertiesBasedJdbcDatabaseTester
                .DBUNIT_USERNAME,
            "sa" );
        System.setProperty(
            PropertiesBasedJdbcDatabaseTester
                .DBUNIT_PASSWORD,
            "");
    }


    protected IDataSet getDataSet() throws Exception
    {
        return new FlatXmlDataSetBuilder().build(
            new FileInputStream("dataset.xml")
        );
    }
}

Outil puissant et offrant une réelle valeur ajoutée, DBUnit devrait avoir sa place dans tous les environnements de tests. L'indépendance et la stabilité qu'il induit par rapport à la couche de persistance est un réel confort et un garant d'exécution correcte des tests. La mise en place est de plus simple. La constitution des fichiers XML peut cependant être fastidieuse et il est conseillé d'utiliser des outils automatiques de génération tels que Jailer.

Jailer
Comme on l'a vu précédemment, il est utile de s'affranchir de la partie persistance quand on teste une application afin de s'assurer du déterminisme des réponses de requêtes (et aussi pour rendre les tests moins consommateurs en ressources). De ce point de vue, des outils comme DBUnit sont des mocks de base de données. Mais écrire les jeux de données de DBUnit peut être fastidieux et il vaut mieux souvent automatiser cette tâche. Dans ce sens, Jailer permet d'extraire des jeux de tests DBUnit cohérents d'une base de données. La cohérence est assurée sur le plan des relations fonctionnelles des données tout en respectant les relations d'intégrité. Les sous-ensembles extraits présentent donc une « vue » pleinement utilisables par les tests et nettoyée des données superflues.

Jailer est une application lourde qu'un développeur lance et connecte à la base de données : Après quelques paramétrages optionnels de plus, Jailer permet la sélection de données choisies comme le montre la capture suivante d'une base exemple d'employés :

Dans la capture précédente issue du site officiel, on a demandé un export SQL mais on peut voir que l'outil permet de créer un fichier XML (au format DBUnit).

Jailer est simple d'emploi et il permet de créer voir d'enrichir des jeux de données au fil des développements très rapidement. Le gain de temps qu'il assure au développeur est conséquent et il lui évite une tâche laborieuse et rébarbative. Allié à DBUnit, Jailer est l'outil parfait pour envisager des tests unitaires de façon sereine. Pas de problème de cohérence ou de déterminisme des données.

Le binôme DBUnit-Jailer apporte la flexibilité et la rapidité de mise en place aux tests unitaires. Pas d'hésitation donc sur ces deux outils : les tests, même s'ils devraient toujours être un passage obligatoire dans un projet informatique ne sont pas une finalité. Tout processus visant à les accélérer ou les faciliter est donc bon à prendre.

Article publié sur LinuxFr dans le cadre de mon activité professionnelle à Linagora.