Forum Linux.noyau Intercepter les syscall

Posté par (page perso) .
Tags : aucun
0
22
juil.
2005
Dans un precedent forum [1], j'avais poser la question sur une solution propre pour logger les syscall d'un processus et de ses fils, ma solution etant plustot crade...
Suite a vos conseil, j'avais opter pour un module noyau, donc je me suis mit a coder, et j'ai finit par obtenir un joli resultat, le module ce load, le programme de log peux lui envoyer les pid a surveiller, lui il renvoie les syscall, et putain qu'est-ce que c'est beau...

Donc tout content je commence a faire quelques test sur les differentes machine ou le programme va devoir etre deployer, et la : le drame...

Ma machine de developpement a un kernel 2.4, pas de probleme. Mais certaines des machine ou je doit deployer l'appli sont en 2.6, et la table des syscall n'est plus exportee dans les nouveau noyaux.

Je reviens donc crier a l'aide, aupres de vous pour des suggestions, car je ne peux pas inclure mon code en dur dans les noyaux des machine, un module ca va, mais une recompilation complete avec reboot de la machine n'est pas envisageable.

Avez-vous des suggestions ou dois-je revenir a ma solution degueulasse ?

[1] http://linuxfr.org/forums/10/9939.html(...)
  • # re

    Posté par . Évalué à 3.

    Le mieux que tu ai à faire dans ce cas, c'est de t'inspire des virtuoses de l'interception de syscall j'ai nommé les auteurs du fameux rootkit Adore !

    Voir:
    http://linuxfr.org/~hideo/4281.html(...)

    Bon courage !
    • [^] # Re: re

      Posté par (page perso) . Évalué à 3.

      le lien n'étant pas (plus) disponible tu peux aussi le récupérer ici : http://packetstorm.linuxsecurity.com/groups/teso/(...)
    • [^] # Re: re

      Posté par (page perso) . Évalué à 1.

      Helas adore n'intercepte pas les syscall.

      Je viens d'y jeter un coup d'oeuil et en fait il ne s'attaque pas directement au syscall, mais il remplace les fonction du vfs par les siennes, ce qui ne resoud pas mon probleme.
      • [^] # Re: re

        Posté par . Évalué à 2.

        regarde http://www.shirka.org/recycled4linux/,(...) je crois qu'il y avait un script perl qui permettait de les extraire a la compilation.
        • [^] # Re: re

          Posté par (page perso) . Évalué à 1.

          Je dois avouer que je ne comprend pas bien ce que tu veux dire par "extraire a la compilation". Les programmes que je dois logger sont deja compilés, de plus je log les syscall qui modifient le fs, donc des syscall ou les parametres sont, la majoritée du temps, dynamique. je ne peux donc pas avoir les infos qui m'interresse au moment de la compilation.

          Je suis quand meme aller voir sur le site de recycled4linux, pour voir comment il surveille le fs, il utilise aussi un module, mais le projet ne semble plus maintenu depuis 1 an, et pour le noyal 2.6, il faut appliquer un patch qui exporte la table des syscall et donc recompiler le noyal...
  • # ptrace ?

    Posté par . Évalué à 1.

    Tu dois pouvoir utiliser l'appel système ptrace.
    (voire la fonction de libc ptrace qui est basée sur le syscall mais plus limitée)

    ptrace permet entre autres d'intercepter tous les appels systèmes d'un processus dont on fournit le pid (en utilisant PTRACE_SYSCALL comme requete)

    ça remplit le cahier des charges non ?

    La page de man pour la fonction de la libc : http://www.linux-france.org/article/man-fr/man2/ptrace-2.html(...)
    Quelques infos sur l'utilisation de ptrace :
    http://www.linuxjournal.com/article/6100(...)

    --
    Vincent
    • [^] # Re: ptrace ?

      Posté par (page perso) . Évalué à 1.

      C'est la solution que j'utilisait avant, le probleme c'est que ce n'est pas franchement propre et portable, pour recuperer les parametres des syscall, il faut aller lire les registre, ce qui veux dire que pour chaque archi il faut ecrire ce code et le tester, hors je n'ai pas access comme je veux a toutes les machines.
      C'est pour ca que j'etait ensuite partit sur un strace, d'autres on deja fait le bouleau alors pourquoi ne pas en profiter... le probleme c'est que c'est super lourd, par rapport au module noyau avec un kernel 2.4, et j'ai plus vraiment envi d'y revenir...
      Mais bon je sens qu'il va faloir que je m'y fasse (quoique je suis en train de me plonger dans les sources du noyal, et ya peut-etre moyen d'intercepter les appels aux fs, plustot que les syscall, si quelqu'un connait un peu le truc ?)
  • # Vilain hack ...

    Posté par . Évalué à 2.

    Dont j'avais eu l'occasion de me pencher sur le code de Sebek[1].
    Sebek fait partie du projet Honeynet et permet de logguer justement tout ce qu'il se passe sur le système.
    Hélas, ce projet est propre à la branche 2.4 de Linux.
    Par contre, dans leurs code, ils n'attaquaient pas directement la table des syscall via la variable exportée sys_call_table[] mais ils allaient la chercher directement en mémoire.
    Voici la fonction chargée de cette tache:

    unsigned long ** get_syscall_table(){
    //----- data structure that holds system call table
    unsigned long **sct;

    unsigned long ptr;
    extern int loops_per_jiffy;

    //----- find the system call table
    sct = NULL;

    for (ptr = (unsigned long)&loops_per_jiffy;
    ptr < (unsigned long)&boot_cpu_data; ptr += sizeof(void *)){

    unsigned long *p;
    p = (unsigned long *)ptr;
    //---- orig ver that looked for sys_exit didnt work on stock
    //---- kerns.
    if (p[__NR_close] == (unsigned long) sys_close){
    sct = (unsigned long **)p;
    break;
    }
    }

    return sct;
    }

    Quand on y réfléchit bien, ce n'est pas bête du tout. En effet, bien que plus exportée, la fameuse sys_call_table[] existe toujours. Et si elle existe toujours, alors elle est calée quelque part en mémoire.
    Attention toutefois, j'ai testé le code de sebek sur un 2.4.30 et celui ci n'ai jamais parvenu à trouver ma table des syscall.
    Pour finir, après avoir modifier le code pour qu'il fonctionne malgré cela, le module à fait paniquer le kernel au bout de 3 ls, donc je pense que ce module n'est pas exploitable en production.
    Sinon, si je me souviens bien, ton but était de logguer les accés aux fichiers ?! Une solution se basant sur le VFS ne pourrait elle pas fonctionner ?

    [1] : http://www.honeynet.org/tools/sebek/(...)
    • [^] # Re: Vilain hack ...

      Posté par (page perso) . Évalué à 2.

      Pour le hack, j'ai essayer et en effet suivant les noyau des fois il trouve, des fois il ne trouve pas... et quand il trouve ce n'est pas tres stable...

      Pour le VFS c'est la piste que je suis en train d'explorer, je vous tiens au courrant.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.