Exploiter les résultats de l'audit

Dans le premier article j'ai mentionné très succinctement une commande qui permet de lire les logs d'audit en temps réel. Et finalement la consultation de ces logs est sans doute la chose la plus intéressante. Personne n'a envie d'activer l'audit sur une machine pour le simple plaisir de remplir son disque dur. Tout ceci doit avoir une raison d'être : pouvoir ensuite (ou en temps réel) exploiter les logs d'auditd.
Comme précisé par défaut dans le fichier audit_control, la taille maximale d'un fichier de log d'audit est 2Mo, et les anciens fichiers sont supprimés pour que le volume total ne dépasse pas 10 Mo :

filesz:2M
expire-after:10M

Il existe plusieurs options intéressantes pour expire-after que je vous laisse découvrir dans le man audit_control. Sachez seulement qu'en fonction de ce que vous choisirez de surveiller, vous allez devoir modifier ces paramètres. Sur une machine assez sollicitée, 10 Mo de log peuvent représenter moins d'une heure d'audit. Si vous avez besoin d'enquêter sur un événement de la veille, il vous sera alors impossible d'en retrouver la trace.

Il y a deux moyens immédiats d'exploiter les logs d'audit. Vous pouvez soit les suivre en direct comme je l'ai montré dans le premier article via la commande praudit /dev/auditpipe, soit les étudier a posteriori. C'est sans doute cette option qui sera le plus souvent utilisée. Vous pouvez ainsi utiliser praudit pour lire les fichiers de logs enregistrés dans /var/audit/.
Comme les logs d'audit peuvent grossir très vite, et qu'on cherche souvent l'aiguille dans la meule de foin, il est bon de pouvoir réduire les logs à ce que l'on cherche avant de les afficher. C'est le rôle de la commande auditreduce. Cette commande permet de filtrer les logs selon une série de critères tels que la date, le ou les flags d'évènement (fc, ex, ...), l'UID, le ou les évènements précis (tels qu'ils sont répertoriés dans le fichier audit_event), et d'autres encore.
auditreduce s'utilise sous la forme générale suivante :

auditreduce paramètres fichiers_de_log | praudit

Comme les logs sont binaires, il est impératif de les traduire via praudit.
Sur Mac OS X, voici un exemple de ce que l'on peut obtenir avec la configuration par défaut d'auditd. Je cherche ici tous les événements pour l'UID réelle patpro ayant eu lieu après le 5 juin 2011 à 12h. Je fais cette recherche dans le fichier de log ouvert par auditd.

# auditreduce -a 2011060512 -r patpro /var/audit/current | praudit
header,68,11,logout - local,0,Sun Jun  5 15:47:35 2011, + 877 msec
subject,patpro,root,patpro,patpro,patpro,10485,10485,0,0.0.0.0
return,success,0
trailer,68
header,68,11,logout - local,0,Sun Jun  5 15:57:05 2011, + 718 msec
subject,patpro,root,patpro,patpro,patpro,10948,10948,0,0.0.0.0
return,success,0
trailer,68

Ces deux évènements correspondent à la fermeture d'une fenêtre de terminal. On voit que chacun d'eux commence par "header" et termine par "trailer". Je ne vais pas couvrir l'intégralité des champs d'un enregistrement de log d'audit, il y a beaucoup trop de possibilités. Reportez-vous au man audit.log pour le détail. Ceux qui ont un intérêt sinon universel, au moins relativement général, sont subject qui décrit le sujet qui a généré les évènements, path qui décrit le chemin du fichier concerné, et return qui indique si l'opération a réussi ou non.
Le champ subject contient les UID et GID (audit UID, effective UID et GID, real UID et GID), le PID, et le port et l'IP de la machine connectée.
Le champ path donne par exemple le chemin d'un exécutable lancé, ou le chemin d'un fichier créé/modifié/détruit.
Le champ return indique success ou failure.

Voici un second exemple, pour un serveur Apache sur Mac OS X, lancé via l'utilitaire setaudit :

header,127,11,execve(2),0,Wed Jun  1 14:50:44 2011, + 667 msec
exec arg,ls
path,/bin/ls
path,/bin/ls
attribute,100555,root,wheel,234881026,24767,0
subject,_www,_www,_www,_www,_www,26696,100031,0,0.0.0.0
return,success,0
trailer,127
header,131,11,open(2) - write,creat,trunc,0,Wed Jun  1 14:50:44 2011, + 735 msec
argument,3,0x1a4,mode
argument,2,0x601,flags
path,/Users/patpro/Sites/testFile.txt
subject,_www,_www,_www,_www,_www,26694,100031,0,0.0.0.0
return,failure : Permission denied,4294967295
trailer,131

La requête http s'est faite sur la machine locale (http://localhost/...) vers un fichier PHP dont le code exécute la commande system("ls"); puis tente d'écrire un fichier testFile.txt.
Le premier évènement enregistré montre le lancement de la commande ls, avec succès. Le second évènement montre la tentative d'écriture du fichier testFile.txt qui échoue.
Cet exemple montre donc clairement comment les logs d'audit peuvent permettre, par exemple, de remonter la trace d'une compromission d'un serveur web. Notez que si j'avais lancé le serveur web normalement, sans utiliser setaudit, la ligne subject aurait indiqué subject,patpro,_www,_www,_www,_www..., patpro étant l'UID suivi par auditd. Il aurait donc fallu que le fichier audit_user indique les flags ex et fc pour le login patpro, sans quoi les évènements pour le serveur web n'auraient pas été enregistrés.

auditreduce permet de filtrer les évènements selon un critère beaucoup plus fin que le simple flag (fc, fd, ex, ...). Il vous autorise à différencier chaque évènement avec la granularité du fichier audit_event. Si vous avez eu la curiosité d'ouvrir ce fichier, vous savez qu'il contient plus de 600 lignes de ce genre :

0:AUE_NULL:indir system call:no
1:AUE_EXIT:exit(2):pc
2:AUE_FORK:fork(2):pc
3:AUE_OPEN:open(2) - attr only:fa
4:AUE_CREAT:creat(2):fc
5:AUE_LINK:link(2):fc
6:AUE_UNLINK:unlink(2):fd
7:AUE_EXEC:exec(2):pc,ex
8:AUE_CHDIR:chdir(2):pc
9:AUE_MKNOD:mknod(2):fc

La nomenclature est simple. Chaque colonne est séparée des autres par ":". La première donne le numéro de référence d'un événement, la seconde donne son nom, la troisième le nom de la fonction correspondante, avec éventuellement un complément d'information, et la dernière indique le ou les flags correspondants.
Sur les 10 lignes citées au dessus, vous notez qu'il y a déjà 4 évènements correspondants au flag pc, et 3 au flag fc. Donc si on se contente de faire un filtrage sur pc ou fc, on peut remontrer beaucoup trop d'évènements par rapport à ce que l'on cherche vraiment. Par ailleurs, dans certains cas, un même évènement peut correspondre à plusieurs flags contradictoires. Par exemple :

75:AUE_OPEN_RTC:open(2) - read,creat,trunc:fc,fd,fr,fa,fm

Cet évènement peut être détecté si on souhaite suivre les flags fc, fd, fr, fa ou fm !
C'est ici qu'intervient le contenu de la ligne header des logs d'audit. En effet, l'entête indique clairement l'évènement qui est capturé. Par exemple open(2) - write,creat,trunc. Il suffit alors de chercher son nom dans le fichier audit_event pour pouvoir s'en servir de clé de filtrage :

grep 'open(2) - write,creat,trunc' /etc/security/audit_event
79:AUE_OPEN_WTC:open(2) - write,creat,trunc:fc,fd,fw,fa,fm

Il est alors possible d'utiliser AUE_OPEN_WTC comme ceci pour obtenir en sortie une sélection parfaite des évènements qu'on recherche :

auditreduce -m AUE_OPEN_WTC -r www -o file=".*/bd/.*" /var/audit/current | praudit

Cette commande permet de trouver tous les évènements AUE_OPEN_WTC pour l'utilisateur www qui ont eu pour cible des fichiers dont le chemin contient la chaîne "/bd/" dans le fichier de log d'audit courant.
Il ne vous reste plus qu'à essayer par vous même !

Bibliographie sommaire

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit-config.html
https://ssl.apple.com/support/security/commoncriteria/CommonCriteriaAdminGuide.pdf
man auditreduce
man auditd
man audit_user
man audit_control
man audit_event
man audit.log
http://forums.freebsd.org/showthread.php?t=23716

Configuration : quid des utilisateurs comme www ?

J'expliquais précédemment que le système d'audit ne peut suivre un utilisateur que si ce dernier se connecte à la machine (par ssh par exemple), et que quelques soient les ruses utilisées (su, sudo...) c'est toujours l'UID réelle de l'utilisateur qui est suivie.

À cause de cela, il est totalement impossible de traquer des évènements appartenant à des utilisateurs qui ne peuvent pas se connecter au système. Ainsi, une ligne comme celle-ci dans audit_user ne permettra de traquer aucun évènement :

# pour freebsd remplacer _www par www
_www:fc,fd,ex:

Il serait pourtant très intéressant de savoir ce que fait Apache dans votre dos, parfois sous la direction de méchants pirates.
De nos jours, La plupart des serveurs utilisent des protocoles comme l'HTTP qui permettent aux utilisateurs d'accéder aux ressources sans être authentifiés au niveau du système. Les utilisateurs en question n'existent d'ailleurs pas au niveau du système. Néanmoins, les applications web permettent de faire énormément de choses via les langages comme le PHP, y compris d'interagir avec le système, en lançant des commandes, en créant des fichiers, etc.

Si on souhaite qu'auditd puisse contrôler les actions de www, il faut recourir à un artifice. Attention tout de même, ce qui suit est plus proche d'un hack que d'une méthode vraiment propre, et je ne peux pas garantir son fonctionnement correct dans un environnement de production.

En premier lieu il faut installer un programme spécifique, qui va permettre de forcer auditd à suivre les actions pour une UID donnée, sans que l'utilisateur correspondant ait besoin de se connecter à la machine.

curl -LO http://www.freebsd.org/~csjp/setaudit.c
cc -o setaudit -lbsm setaudit.c 

Cela vous donne, si tout se passe bien, le binaire setaudit, que l'on va utiliser sous cette forme :

setaudit -a UID_WWW -m FLAGS /programme/de/lancement/d/apache

Pour suivre les évènements d'exécution de commande sous respectivement FreeBSD et Mac OS X, cela donnera :

setaudit -a www -m ex /usr/local/etc/rc.d/apache22 restart
setaudit -a _www -m ex /usr/sbin/apachectl restart

Ainsi, toutes les commandes lancées par Apache (donc sous l'UID www) sont enregistrées par auditd.
Comme le masque des évènements (les flags de l'argument -m) décrit ce que l'on doit suivre, il est même inutile de renseigner le fichier audit_user.

Pour résumer :

• Si vous souhaitez que l'audit suive les utilisateurs qui se connectent à la machine, vous pouvez régler les classes d'évènements qui seront soumises à l'audit pour l'ensemble des utilisateurs dans le fichier audit_control, et gérer les cas particuliers dans audit_user.
• Si vous souhaitez que l'audit suive des UID "interne", pour traquer tout signe de compromission sur un serveur web, un serveur de mail, etc. il faudra recourir à setaudit pour activer l'audit au moment du lancement du service correspondant.
• Faites attention à la liste de flags que vous choisissez. Le volume des logs d'audit peut grossir très rapidement.

Troisième partie de l'article ->

Activation du système d'audit
Configuration
Configuration : quid des utilisateurs comme www ?
Exploiter les résultats de l'audit

Activation du système d'audit

Sous FreeBSD 7 et 8, le noyau est déjà compilé avec options AUDIT, il ne reste donc qu'à lancer le démon auditd en ajoutant la ligne suivante au fichier /etc/rc.conf :

auditd_enable="YES"

puis en lançant le démon à la main :

sudo /etc/rc.d/auditd start

Sous Mac OS X 10.6, auditd est lancé d'office par launchd, il n'y a rien à faire.

Configuration

Une fois lancé, le système d'audit va enregistrer très peu d'évènements par défaut. Il convient donc de faire quelques réglages en fonction de ce que l'on cherche à accomplir.
Les fichiers de configuration d'auditd se trouvent dans le répertoire /etc/security où seul root peut écrire.

• audit_class : décrit les différentes classes d'évènements qu'il est possible de surveiller. Il est sage de ne pas éditer ce fichier.
• audit_control : lisible seulement par root, ce fichier défini la politique d'audit par défaut.
• audit_event : le grand frère de audit_class, on ne le modifie pas.
• audit_user : le fichier de réglages par utilisateur. Il complète audit_control et n'est lisible que par root.
• audit_warn : un fichier exécutable qui est lancé quand auditd manque de place sur le disque pour écrire les logs.

Pour un usage courant, seuls les fichiers audit_control et audit_user sont intéressants. La première chose à faire est d'aller lire leur page man respective.

Par défaut, le contenu du fichier audit_control est le suivant :

dir:/var/audit
flags:lo,aa
minfree:5
naflags:lo,aa
policy:cnt,argv
filesz:2M
expire-after:10M

Avec ces valeurs, auditd ne va répertorier que les évènements des classes "lo" (login/logout) et "aa" (authentification/autorisation). Et il va le faire pour l'ensemble des utilisateurs.
Attention : après avoir lu le man audit_control, vous serez peut être tenté d'ajouter le champs "host" pour compléter la configuration. N'en faites rien. Cela peut perturber les outils utilisateur et rendre l'exploitation des résultats hasardeuse, voire impossible.
Le contenu de audit_user quant à lui nous permet de préciser des flags en se basant sur le login des utilisateurs. Par défaut, le fichier audit_user contient :

root:lo:no

C'est à dire que, quelque soit la liste des flags audit_control, les évènements de la classe "lo" seront suivis pour l'utilisateur root, et les évènements de la classe "no" (invalides) ne seront jamais suivis.
Vous pouvez immédiatement vérifier que votre système d'audit fonctionne en lisant en direct les évènements qu'il enregistre. Il suffit pour cela de taper la commande suivante en root (ou via sudo) :

# praudit /dev/auditpipe

Utilisez alors une autre fenêtre de terminal pour gérer des traces. Sous Mac OS X vous pouvez faire un sudo, ou simplement fermer la fenêtre de terminal, par exemple. Vous pourrez alors lire des choses comme cela :

header,104,11,user authentication,0,Wed Jun  1 14:53:39 2011, + 965 msec
subject,root,root,wheel,root,wheel,26712,0,0,0.0.0.0
text,Authentication for user <patpro>
return,success,0
trailer,104
header,68,11,logout - local,0,Wed Jun  1 15:36:12 2011, + 554 msec
subject,patpro,root,patpro,patpro,patpro,28079,28079,0,0.0.0.0
return,success,0
trailer,68

Nous en reparlerons dans le dernier article de la série.

Faites bien attention aux flags que vous allez régler. Dans certains cas, le nombre d'évènements enregistrés par le système d'audit peut être extrêmement élevé. Par défaut peu de choses sont soumises à l'audit, si bien qu'en 18 mois sur une station de travail, le contenu de /var/audit représente moins de 10 Mo. A contrario, sur un serveur web assez actif, où les classes d'audit sont "fd,^fc,ex:no,fc", on dépasse les 43 Mo en a peine 4 heures d'audit.

Il faut bien comprendre que l'activation de l'audit pour un utilisateur ne se produit qu'au moment de la première connexion de l'utilisateur au système. Prenons un exemple. Le fichier audit_user contient :

root:lo:no
patpro:fc,fd,ex:

Donc pour l'utilisateur patpro, les créations, ouvertures, suppression de fichier, ou exécutions de programmes doivent être suivis. Cet utilisateur a une crontab qui tourne toutes les nuits et télécharge un fichier. Pourtant, auditd ne capturera aucun de ces évènements tant que l'utilisateur patpro ne se sera pas connecté à la machine, alors même que de nombreux évènements correspondants aux critères de l'audit se produisent.
Dès que l'utilisateur patpro se sera connecté à la machine, auditd se mettra à enregistrer toutes les actions correspondant aux classes fc, fd et ex exécutées sous l'UID patpro. Cet audit se poursuivra même après la déconnexion de l'utilisateur.
Par ailleurs, l'UID qui est traquée par auditd n'est pas l'UID apparente, mais l'UID d'origine de l'utilisateur. Si je me connecte en tant que patpro, et que je fais un su - ou un sudo -Es, je deviens root dans le shell (UID apparente), mais je reste patpro aux yeux d'auditd.
Nous verrons dans un second article pourquoi ces deux contraintes sont importantes. D'ici là, vous pouvez approfondir les aspects simples de la configuration en lisant ces différents documents :

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit-config.html
https://ssl.apple.com/support/security/commoncriteria/CommonCriteriaAdminGuide.pdf

Deuxième partie ->

192.168.0.15 -> 54.42.0.48
192.168.0.20 -> 54.42.0.43
192.168.1.15 -> 54.42.1.56
192.168.1.20 -> 54.42.1.43

En me basant sur un exemple de script Perl utilisant IP::Anonymous, j'ai créé un script qui permet en plus de rendre anonyme les adresses email, les message-IDs, et les noms de machines. Ainsi, et à condition de rester en IPv4, le script final permet de rendre totalement anonyme des logs Postfix :

   1: #!/usr/bin/perl -wT
   2:
   3: # script brodé à partir d'un exemple
   4: # trouvé en ligne sur le forum CPAN
   5: # http://cpanforum.com/posts/1304
   6:
   7: # à utiliser sous la forme :
   8: # logs_anonymes.pl fichier.log > sortie_anonyme.log
   9:
  10: use strict;
  11: $|=1;
  12:
  13: use IP::Anonymous;
  14: use Digest::MD5;
  15:
  16: # 32 integers entre 0 et 255 (jot -r 32 0 255)
  17: my @key = (135,229,13,26,29,84,46,37,231,95,211,
  18:            196,243,11,87,5,23,217,173,214,66,241,
  19:            164,67,132,149,161,151,114,137,238,75);
  20:
  21: my $obj = new IP::Anonymous(@key);
  22: my $md5 = Digest::MD5->new;
  23:
  24: # seed pour le md5
  25: my $seed = '766326241f69b1244792587f556d02b8';
  26:
  27: while(defined(my $line=<>)) {
  28:     chomp $line;
  29:     # les IP
  30:     if($line =~ /\d{1,3}(?:\.\d{1,3}){3}/) {
  31:         $line =~
  32:             s/(\d{1,3}(?:\.\d{1,3}){3})/$obj->anonymize($1)/eg;
  33:     }
  34:     # les adresses email et messageID
  35:     if($line =~ /[=< ][^@ ]*@/) {
  36:         $line =~
  37:             s/([=< ])([^@=< ]*@)/$1.$md5->add($seed)->add($2)->hexdigest."@"/eg;
  38:     }
  39:     # les hostnames
  40:     if($line =~ /([=< @])(([a-zA-Z0-9]***TRONQUÉ***|ZW)/i ) {
  41:         $line =~
  42:             s/([=< @])((?:(?:[a-zA-Z0-9]***TRONQUÉ***|ZW)/$1.$md5->add($seed)->add($2)->hexdigest.".".$3.".".$4/egi;
  43:     }
  44:     # suppression des HELO
  45:     if($line =~ /(helo=<[^>]*>)/i ) {
  46:         $line =~
  47:             s/(helo=<[^>]*>)//gi;
  48:     }
  49:
  50:     print $line."\n";
  51: }

Attention : certaines lignes du script ci-dessus sont tronquées volontairement. Cliquez ici pour obtenir le code du script fonctionnel : logs_anonymes.pl.

Pour utiliser ce script, il vous faudra installer IP::Anonymous, comme ceci par exemple :

$ sudo cpan
cpan[1]> install IP::Anonymous

Il vous faudra aussi personnaliser le contenu de @key (lignes 17 à 19), en utilisant par exemple la commande jot pour générer une liste de 32 entiers aléatoires compris entre 0 et 255 :

$ jot -r -s , 32 0 255

@key doit être gardée secrète, donc votre script devra être lisible seulement par vous.
Pour finir il faudra personnaliser le contenu de $seed (ligne 25), en saisissant la chaîne de caractères qui vous plait.
Aux lignes 40 et 42 figure une liste quasi complète des TLD, obtenue auprès de l'IANA.

Pour utiliser le script, que vous aurez rendu exécutable, il suffit de l'invoquer comme cela :

$ /chemin/de/logs_anonymes.pl fichier.log > sortie_anonyme.log

Testé sous Mac OS X 10.6 et FreeBSD 8.

Enjoy.

Mais si les disques durs sont connectés non pas à la carte mère directement, mais à une carte RAID, la chose se complique. En effet, le système ne sait pas qui est ad4 (ou ad6, ou toute autre appellation interne). Le système ne voit que la carte RAID.

Disons que nous sommes sur un bon système (FreeBSD), avec une bonne carte RAID (3Ware) utilisant le pilote twa. Cette carte sera donc vue du système sous le nom interne /dev/twa0 (0 car c'est la première carte de ce type dans la machine).
L'outil smartctl permet d'accéder au S.M.A.R.T. des disques durs au travers de la carte RAID par des requêtes comme :

smartctl -a /dev/twa0 -d 3ware,0  # 1er disque branché sur la carte
smartctl -a /dev/twa0 -d 3ware,1  # 2nd disque branché sur la carte
...

Comme le plugin hddtemp_smartctl de Munin utilise smartctl aussi, il ne reste plus qu'à lui faire comprendre la syntaxe. On ne doit plus lire les données S.M.A.R.T. de /dev/ad4, /dev/ad6… mais celles de /dev/twa0 -d 3ware,0, /dev/twa0 -d 3ware,1…
Il faut éditer le fichier plugins.conf de Munin, en créant une section [hddtemp_smartctl] dans la quelle :

1. on crée des disques durs "virtuels"
2. on rattache chacun de ces disques à notre carte twa0
3. on précise le type de chaque disque dur (3Ware,0, 3Ware,1…)

Voici ce que cela donne pour une carte 3Ware twa0, à la quelle sont connectés quatre disques durs que l'on décide de nommer tout à fait arbitrairement hd0 à hd3 :

[hddtemp_smartctl]
env.smartctl /usr/local/sbin/smartctl
env.drives hd0 hd1 hd2 hd3
env.dev_hd0 twa0
env.dev_hd1 twa0
env.dev_hd2 twa0
env.dev_hd3 twa0
env.type_hd0 3ware,0
env.type_hd1 3ware,1
env.type_hd2 3ware,2
env.type_hd3 3ware,3

J'insiste bien sur le fait que les noms hdx sont des abstractions arbitraires, utilisées pour mettre en relation un "dev" et un "type". On pourrait mettre "toto", "titi"… cela marcherait de la même manière.
Cela donne finalement quelque chose comme ça :

Les photographes Grand-Bretons viennent donc de monter une campagne pour manifester leur amour de la photographie, et leur volonté de ne pas se laisser faire par des comportements liberticides et souvent même illégaux de la police anglaise.

Pendant ce temps, les témoignages d'abus se multiplient :
Heavy-handed policing against photographers caught on video
Another video journalist stopped at Greek protest
The photograph that terrorized London
Innocent photographer or terrorist?
You Can't Picture This
radio for back up
Sex pictures shock!

Et ça arrive en France :
Deux photographes et une quarantaine de clowns au poste après le défilé du 14 juillet
…

• aide mobilité site:SuperJob.fr - Google Search
• Grosse Cochonne sans culotte - xXx

Inutile de vous faire un dessin. Dans votre navigateur vous êtes libre à tout moment d'effacer votre historique. Dans Slife, vous ne pouvez pas le faire. Si vous avez oublié d'activer le mode "Privé" avant de chercher un nouveau job, ou d'aller mater quelques paires de fesses au nez et à la barbe de votre employeur, vous êtes cuits.
Bien sûr, il y aura toujours un petit malin pour aller éditer la base de données de Slife à la main. Mais ce n'est pas le genre d'acrobatie à la portée du premier venu. Je vais néanmoins donner la marche à suivre. Notez bien : j'ai bien sûr testé cette manipulation, mais je ne peux pas garantir qu'elle est inoffensive sur le long terme. Il n'est pas complètement exclu que cela crée des problèmes de cohérence des données dans Slife.
Comme on s'y serait attendu, Slife stocke ses données dans une base de données SQLite (en tout cas sous Mac OS X). SQLite est un moteur de bases de données SQL, léger et rapide. Contrairement à MySQL ou autre, vous n'avez pas besoin qu'un serveur tourne en permanence pour accéder aux données. C'est aussi ce moteur qui est utilisé par Spotlight.
Il est possible de rentrer dans des bases de données SQLite directement avec les outils fournis dans Mac OS X. Il faut pour cela lancer l'application Terminal, et taper au prompt :

sqlite3 "Library/Application Support/Slife/db20.slife"

ce qui retourne :

SQLite version 3.4.0
Enter ".help" for instructions
sqlite>

On peut ensuite taper :

.databases

ce qui doit donner quelque chose de ce genre, modulo votre nom d'utilisateur :

seq  name             file
---  ---------------  ----------------------------------------------------------
0    main             /Users/patpro/Library/Application Support/Slife/db20.slife

Posons maintenant que vous souhaitiez supprimer tous les événements enregistrés dont le titre contient SuperJob.fr, car vous ne voulez pas que votre patron soupçonne que vous préparez votre départ.
La première étape pour ne pas faire de bêtise c'est de quitter Slife car être deux (Slife et vous) en train d'éditer la base de données au même instant pourrait être fâcheux. Après avoir quitté Slife, faites une copie de sauvegarde du fichier db20.slife.
La seconde étape consiste à afficher sans les détruire les événements ciblés. On utilise pour cela l'instruction SQL SELECT. Au prompt sqlite> tapez :

SELECT * FROM ZITEMRECORDED WHERE ZNAME LIKE "%SuperJob.fr%";

Après validation, vous allez obtenir un listing de tous les enregistrements qui contiennent "SuperJob.fr" dans le titre :

10|2478|1|2008|7|10|30|34.0|Safari||aide mobilité site:SuperJob.fr - Google Search
10|2479|2|2008|7|10|30|8.0|Safari||SuperJob.fr, numéro 1 de l’emploi en ligne
10|2480|1|2008|7|10|30|9.0|Safari||Bulletin Officiel de SuperJob.fr n° 2002-2

Lisez bien tous les titres pour vérifier que vous n'allez pas supprimer des événements qui ne devraient pas l'être.
Si c'est bon, vous pouvez lancer le DELETE :

DELETE FROM ZITEMRECORDED WHERE ZNAME LIKE "%SuperJob.fr%";

Vous pouvez, à l'issue de ce DELETE, refaire le SELECT pour vérifier qu'il ne reste rien. Mais il n'y a aucune raison qu'un enregistrement ait échappé au DELETE.

Ensuite, vous quittez SQLite en tapant au prompt .quit, puis vous pouvez relancer Slife et vérifier que les enregistrements incriminants ont disparu.

Pour ceux qui sont désespérément allergiques au terminal, il existe une paire de clients graphiques pour accéder à des bases SQLite. J'ai testé rapidement SQLite Database Browser 1.3, et à première vue il donne satisfaction. Néanmoins il est compilé pour PowerPC uniquement. Je ne saurai garantir son fonctionnement sur plateforme Intel.

Slife 2.0 est une application pleine de promesses, et d'une apparente simplicité. En réalité, elle est plus complexe à prendre en main que son interface pourrait le faire penser. Par ailleurs, il faut le souligner dès maintenant, il lui manque des fonctions importantes, voire essentielles, pour s'adapter à nos manières de travailler.

Slife vous permet de suivre l'utilisation de presque toutes vos applications, de vos documents, et votre utilisation d'internet. Par défaut, l'historique est conservé un an, et la mise à jour se fait toutes les cinq secondes. Slife permet en plus de suivre l'utilisation de votre machine sous la forme d'activités, définies par vous. Chaque activité que vous créez peut regrouper des applications, des documents, et des URL. Je peux, par exemple, définir une activité "Mail", pour la quelle je ne vais suivre que l'utilisation de l'application Mail. Je peux aussi créer une activité "Lecture des news", pour la quelle je vais suivre l'utilisation de mon agrégateur RSS, de mon lecteur de newsgroups, et de l'URL http://news.google.fr/.

C'est dès maintenant que les premières limitations de Slife se font sentir. Il est impossible de tracker l'utilisation d'une même application dans deux activités différentes. Par exemple, vous développez du code PHP dans BBEdit. Vous souhaitez savoir combien de temps au total vous passer à coder, et combien de temps en particulier vous passez sur un projet donné de développement. Il faudra malheureusement choisir l'un ou l'autre, car activer le suivi de BBEdit dans la seconde activité, le désactivera dans la première.

De même, il est possible de suivre votre temps de travail sur un document d'après son nom, mais pas d'après le nom du dossier parent. Donc malheureusement, si les documents de deux projets portent le même nom (flyer.psd, index.php, ...) il sera impossible de les distinguer. Il est par contre possible de suivre l'utilisation des documents en précisant seulement une partie du nom. Si vous avez l'habitude de nommer vos documents avec un identifiant de projet (flyer_8652.psd, template_8652.ai, bat_8652.pdf...), il est alors très simple de créer une activité qui va tracker votre travail sur ces documents. Il suffit de définir une activité pour ce projet numéro 8652, et d'y associer un document "8652". Slife va suivre tous les documents que vous éditez et dont le nom contient "8652", quelque soit l'application utilisée.

Le tracking des documents d'un même dossier dans le cadre d'une activité est une fonction à l'étude chez Slifelabs, car de nombreux utilisateurs la réclament. Néanmoins, aucune date de disponibilité n'est annoncée, et toutes les ressources de Slifelabs ont été dédiées au portage vers Windows de la version 2 du logiciel.

En terme d'ergonomie, Slife est capable du meilleur comme du pire, malheureusement. Le meilleur, c'est le menu qui permet à tout moment, et dans toutes les applications d'ajouter le document ou l'application de premier plan à une des activités existantes. Il est possible aussi d'entrer dans un mode "privé", qui interrompt le tracking. Le pire, ce sont les différentes fenêtres de l'application, qui ne supportent pas le glisser-déposer, qui manquent de menus contextuels, voire même de cohérence.
Par ailleurs, notez bien que la fenêtre d'édition des activités est une fenêtre trompeuse. La liste des documents et URL est une liste globale. Si vous supprimez ou modifiez un document de cette liste, il sera supprimé ou modifié dans toutes les activités.

Slife propose en plus un mode connecté, Slife Teams, pour suivre le travail de plusieurs collaborateurs via une interface web. Cette option n'est actuellement accessible qu'après inscription auprès de Slifelabs. Si je suis retenu pour tester Slife Team, je ferais un second article.

Pour conclure, Slife est une application pleine de potentiel, mais encore très immature. Elle mérite qu'on lui porte de l'intérêt et qu'on fasse des retours enthousiastes à ses développeurs, mais son déploiement dans un contexte où les workflows sont bien rodés ne sera pas toujours possible. J'espère que les principales limitations seront abolies par les versions suivantes. Néanmoins, si vous n'êtes pas intéressés par le tracking d'activités complexes, Slife vous suffira largement.

Pour :

• gratuite
• (très) faible consommation de resources
• prise en main rapide
• développeurs à l'écoute, via les forum de slifelabs

Contre :

• pas de tracking pour les dossiers
• pas de tracking pour certaines applications (UT2004 par exemple)
• interface vraiment perfectible

Tout le programme de la "Freedom not Fear Edition France" est sur le site de l'association humanrights21.org.

Les dérives commerciales sont bien sûres évidentes, la déclinaison du moteur sous la forme TinEye Music en est un parfait exemple, mais ne boudons pas notre plaisir. Il n'y a pas de mauvaises technologies, il n'y a que de mauvais usages.