Journal Seccomp, une sandbox intégrée au noyau Linux…

44
4
mai
2014

Sommaire

Problématique

Utilisez-vous pour vos développements professionnels ou privés une solution d'intégration continue à la Jenkins ? Un tel logiciel permet d'accélérer le développement du code en le testant plus régulièrement, en le soumettant automatiquement à des tests unitaires.

Mais que se passe-t-il si un vilain© soumet du code dangereux pour votre système d'intégration continue ? Si votre logiciel d'intégration continue se contente de compiler du code, vous pensez qu'il est protégé ? Quid d'une faille dans votre compilateur, ou d'un problème à l'exécution d'un test unitaire ?
Vous vous retrouveriez alors avec un composant clé de votre infrastructure de développement corrompu, avec toutes les conséquences que cela peut avoir…

À mon travail, par paranoïa, j'ai cherché comment faire pour pouvoir, à l'intégration du code, exécuter des tests sur nos projets Perl tout en restant protégé des vilains…

Comment faire…

J'ai précisé le langage utilisé, Perl.
Perl a plusieurs particularités qui le rendent délicat à «sécuriser» dans un tel cadre :
- il a été prouvé qu'on ne peut pas parser du code, rendant impossible toute analyse statique exhaustive (pour ceux que cela intéresse http://www.perlmonks.org/?node_id=663393),
- même le plus simple contrôle par l'interpréteur (perl -c) permet une exécution arbitraire de code à l'aide des blocs BEGIN.

Il faut donc se pencher sur un système de Sandbox.
La sandbox intégrée à perl, le module Safe, ne nous aide pas à exécuter du «vrai» code : il ne pourra pas restreindre d'éventuelles manipulations via un module perl écrit en C par exemple.
Tapons donc plus bas niveau : le noyau et la technologie utilisée par Google Chrome depuis peu sous Linux : seccomp.

Qu'est-ce-que seccomp ?

Seccomp permet de filtrer les appels systèmes d'un processus au niveau du noyau.
La première version de cette technologie, introduite en 2005 dans le noyau 2.6.12, était très primitive : une fois passé en mode «sécurisé», un process ne pouvait plus exécuter qu'exit, read, write et sigreturn. Le strict minimum requis pour par exemple un cluster de calcul, mais largement insuffisant pour des applications complètes.
La seconde version fut introduite dans le noyau 3.5 en juillet 2012 : seccomp-bpf. Un programme va envoyer au noyau un filtre BPF à appliquer sur les appels systèmes, et activer ensuite ce filtre.
Ainsi, seuls les appels systèmes requis d'un logiciel peuvent être exécutés, toute tentative d'aller plus loin étant bloquée. Plus intéressant encore : les filtres peuvent être enchaînés, d'autres programmes exécutés avec leur propre restriction…
Bien entendu, un tel filtre ne serait pas suffisant s'il ne permettait pas de filtrer également les paramètres passés aux appels système. Néanmoins, seules les valeurs directes peuvent être filtrées. Or une chaîne de caractère est passée par pointeur. Il faut donc avoir recours à un système plus complexe si l'on souhaite filtrer finement les fichiers ouverts. Mais on peut filtrer les droits, ça me suffit :)

Utilisons seccomp-bpf

Seccomp-bpf nécessite d'écrire du bytecode BPF, de l'envoyer au noyau par un prctl… C'est pénible. Une librairie a donc été écrite pour simplifier tout ça : http://sourceforge.net/projects/libseccomp/

Hello world

Nous allons pour le moment écrire un hello world, et le protéger des vilains…

#include <stdio.h>

int main (int argc, char **argv)
{
    printf("Hello world\n");
    return 0;
}

Voilà, un programme extrêmement simple mais tellement capital qu'il faut le protéger par seccomp.

Tout d'abord, quels appels système sont requis pour ce programme ? Facile, strace est notre ami.

snoopy@peanuts2:~/projects/seccomp-dlfp$ strace -c ./hello 
Hello world
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
  -nan    0.000000           0         1           read
  -nan    0.000000           0         1           write
  -nan    0.000000           0         2           open
  -nan    0.000000           0         2           close
  -nan    0.000000           0         3           fstat
  -nan    0.000000           0         9           mmap
  -nan    0.000000           0         3           mprotect
  -nan    0.000000           0         1           munmap
  -nan    0.000000           0         1           brk
  -nan    0.000000           0         3         3 access
  -nan    0.000000           0         1           execve
  -nan    0.000000           0         1           arch_prctl
------ ----------- ----------- --------- --------- ----------------
100.00    0.000000                    28         3 total

Pour la partie «active» du programme, celle qui nous intéresse plus :

fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 3), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa7a47f9000
write(1, "Hello world\n", 12)           = 12
exit_group(0)                           = ?

Facile !

Activons donc seccomp-bpf. Nous ferons la supposition que notre programme refusera de tourner sans, évidemment, pour ne pas prendre de risque.

#include <stdio.h>
#include <seccomp.h>


int main(int argc, char **argv, char **envp)
{
    scmp_filter_ctx scmp = seccomp_init(SCMP_ACT_KILL);
    if (!scmp) {
        fprintf(stderr, "Failed to initialize libseccomp\n");
        return -1;
    }
    // Allow all needed syscalls
    seccomp_rule_add(scmp, SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 0);
    seccomp_rule_add(scmp, SCMP_ACT_ALLOW, SCMP_SYS(write), 0);
    seccomp_rule_add(scmp, SCMP_ACT_ALLOW, SCMP_SYS(mmap), 0);
    seccomp_rule_add(scmp, SCMP_ACT_ALLOW, SCMP_SYS(fstat), 0);

    // Load in the kernel
    if (seccomp_load(scmp) != 0) {
        fprintf(stderr, "Failed to load the filter in the kernel\n");
        return -1;
    }

    printf("Hello world\n");
    return 0;
}

Compilons et exécutons :

snoopy@peanuts2:~/projects/seccomp-dlfp$ gcc -lseccomp hello-safe.c -o hello-safe ; ./hello-safe 
Hello world

Et si on rajoute un appel à unlink dans le code ?

snoopy@peanuts2:~/projects/seccomp-dlfp$ ./hello-safe 
Bad system call
snoopy@peanuts2:~/projects/seccomp-dlfp$ echo $?
159

Comment ça marche ? C'est très simple : seccomp_init crée un «contexte» pour la librairie seccomp, avec une action à effectuer par défaut. Puis chaque appel à seccomp_rule_add rajoute une règle dans le contexte, avec en paramètre le contexte, l'action à effectuer, le numéro de l'appel système (merci à la macro SCMP_SYS) et le nombre d'arguments sur lequel on va filtrer… Et enfin seccomp_load charge le contexte sur le processus courant dans le noyau. Attention, une fois le contexte chargé, il ne peut plus être déchargé pour d'évidentes raisons de sécurité.

Les choses se compliquent : lisons des fichiers…

C'est tout de même plus pratique de pouvoir communiquer un peu avec le monde… Mais je ne veux pas que mon hello world soit corrompu et permette d'écrire sur mon disque. Je vais donc lui autoriser open uniquement avec le flag O_RDONLY.

J'ajoute donc cette règle dans mon programme :

seccomp_rule_add(scmp, SCMP_ACT_ALLOW, SCMP_SYS(open), 1, SCMP_A1(SCMP_CMP_EQ, O_RDONLY));

Et voilà… Aussi simple que cela. Imaginez les possibilités sur un programme SUID par exemple : pourquoi risquer de compromettre tous les droits d'un utilisateur si quelques lignes de code permettent de brider la fuite à quelques appels systèmes précis ?

Tout n'est pas blanc ou noir

ALLOW et KILL… C'est sommaire. seccomp permet plus que ça :

  • TRAP : envoie un signal SIGSYS,
  • ERRNO(errno) : refuse l'appel avec l'erreur indiquée,
  • TRACE(msg_num) : génère un évènement ptrace.

Armé de ces outils, vous pouvez commencer plein de choses :

  • développer plus aisément votre filtre seccomp en étant directement notifié des appels manquants,
  • faire croire à une non disponibilité du réseau pour exécuter un code qui fait des appels inutiles au réseau,
  • un monitoring plus poussé de vos processus avec un processus père se chargeant de donner des droits à des enfants à la demande, validant leurs demandes… Développer un tel logiciel parait hors de portée pour un simple journal par contre, surtout quand des gens l'ont déjà fait :)

Projets utilisant seccomp-bpf

Les plus beaux exemples d'utilisation de seccomp sont ceux qu'on ne voit pas : qemu, openssh 6.0, google chrome… Ces projets profitent de seccomp pour accroitre la sécurité sous Linux.

En rédigeant ce journal, je suis aussi tombé (ouille) sur un beau projet de sandbox qui mériterait d'être plus connu : Mbox. http://pdos.csail.mit.edu/mbox/
Mbox combine seccomp, fakeroot et un système de fichiers temporaire pour permettre d'exécuter, en toute confiance et sans privilèges particuliers, un logiciel et de valider à la fin ses actions pour les "commiter" sur le système de fichier réel.

Seccomp, c'est bon, mangez-en. Bien sûr, on vous dira «oui mais un conteneur c'est mieux», «une VM ça isole plus»… Ce n'est pas le même besoin, et seccomp est dans tous les cas un complément fort intéressant pour accroître la sécurité du système en mettant en place une politique volontaire de contrôle d'accès au sein des différents logiciels.

  • # Et sinon il y a SELinux

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

    Article intéressant.
    Cependant, si tu as dit qu'à la fin en somme Docker, LXC, QEMU ou KVM ne répondent pas à la même problématique, qu'en est-il de SELinux ?
    En effet ce dernier propose des utilitaires pour isoler une application entièrement vis à vis du système en limitant drastiquement (par défaut) l'accès aux appels systèmes ou autres primitives. Les règles de SELinux permettant d'accroitre es possibilité de l'application au strict nécessaire.

    Je pense que ça se rapproche d'un point de vue fonctionnelle à ce que tu présentes mais par une voie différente.

    • [^] # Re: Et sinon il y a SELinux

      Posté par . Évalué à 3. Dernière modification le 05/05/14 à 00:26.

      qu'en est-il de SELinux ?

      Même question pour RSBAC, SMACK et GrSecurity

      • [^] # Re: Et sinon il y a SELinux

        Posté par . Évalué à 2.

        Et AppArmor.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Et sinon il y a SELinux

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

          En fait SELinux propose un mécanisme qui fait déjà une isolation complète bac à sable avec la possibilité d'étendre les droits. j'ignore si les autres ont les mêmes facultés de manière automatisée.

    • [^] # Re: Et sinon il y a SELinux

      Posté par . Évalué à 3.

      C est assez different , qemu, lxc et autre isole un programme dans un environnement isolé. Donc un code verolé s exécutera mais sans faire de dégât . Dans le cas present si j ai bien compris, c est le développeur qui définit dans son programme les droits au il pense necessaire pour son appli.
      Ça ressemble plus au système sous Android ou chaque appli déclare les droits au elle souhaite avoir.

      Par contre le projet me fait penser a capsicum, y a t il un lien ?

      • [^] # Re: Et sinon il y a SELinux

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

        si j ai bien compris, c est le développeur qui définit dans son programme les droits au il pense necessaire pour son appli.

        Oui c'est ça l'avantage. L'idée c'est que les développeurs d'applications, qui par définition connaissent parfaitement leur code, pourront créer un filtre Seccomp afin de déclarer la liste spécifique des appels autorisés pour leur application.
        Avec SELinux c'est la distro qui fait le boulot de définir la politique de sécurité. C'est plus complet mais c'est un travail énorme et très casse-gueule.
        Et puis l'un n'empêche pas l'autre.

      • [^] # Re: Et sinon il y a SELinux

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

        Tu peux aussi l'utiliser à la manière de SELinux, en réduisant les droits et en faisant un exec. C'est un peut moins pratique par contre.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Et sinon il y a SELinux

        Posté par . Évalué à 4.

        Par contre le projet me fait penser a capsicum, y a t il un lien ?

        Le blog des développeurs de chrome est très intéressant à ce sujet : http://blog.cr0.org/2012/09/introducing-chromes-next-generation.html

        En gros, seccomp-bpf est un framework pour réduire la surface d'attaque (ie désarmer l'attaquant) alors que capsicum implique de continuer à faire confiance au noyau pour qu'un appel ne soit pas "dangereux" (par ex. la faille sur vmsplice).

        Having a nice, high level, access control semantics is appealing and, one may argue, necessary. When you're designing a sandbox for your application, you may want to say things such as:
        I want this process to have access to this subset of the file system.
        I want this process to be able to allocate or de-allocate memory.
        I want this process to be able to interfere (debug, send signals) with this set of processes.
        The capabilities-oriented framework Capsicum takes such an approach. This is very useful.
        However, with such an approach it's difficult to assess the kernel's attack surface. When the whole kernel is in your trusted computing base "you're going to have a bad time", as a colleague recently put it.
        Now, in that same dimension, at the other end of the spectrum, is the "attack surface reduction" oriented approach. The approach where you're close to the ugly guts of implementation details, the one taken by Seccomp-BPF.

  • # Docker

    Posté par . Évalué à 8.

    Seccomp, c'est bon, mangez-en. Bien sûr, on vous dira «oui mais un conteneur c'est mieux», «une VM ça isole plus»… Ce n'est pas le même besoin, et seccomp est dans tous les cas un complément fort intéressant pour accroître la sécurité du système en mettant en place une politique volontaire de contrôle d'accès au sein des différents logiciels.

    Je suis tout à fait d'accord, mais pour le problème que tu indique initialement, j'aurais plus vu quelque chose comme SELinux/Docker qui apporte tout ce que tu décris dans Mbox.

    Utiliser seccomp est relativement fastudieux à mettre en place, il faut lister les appels systèmes, déterminer s'ils sont réglo ou pas et comme tu le dis on est pas en mesure de savoir si le travail est fini ou pas parce qu'il n'y a pas d'analyse statique. Tu es en plus très dépendant de tes dépendances (si un module est mis à jour et ne fait plus un appel système tu ne le verra pas). Bref pour de l'intégration continue, je trouve qu'ajouter un projet de développement comme ça est un peu trop, alors que d'autres solutions permettent de réduire ça a un problème d'intégration sans perte de sécurité pour l'environnement d'intégration.

    Par contre ça peut être utile si tu veux vérifier ton code. Pour savoir qu'il ne fait que ce que tu veut et pas plus, pas moins (mais pour ça strace est plus approprié je pense).

    Quoi qu'il en soit merci énormément pour ton journal très intéressant. C'est super d'avoir des exemples bien expliqués comme ça !

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Autres projets utilisant seccomp-bpf

    Posté par . Évalué à 4.

    Voici deux autres projets utilisant seccomp-bpf:

    Tout comme Mbox, ils utilisent seccomp-bpf couplé à ptrace (SECCOMP_RET_TRACE). Cela a deux avantages:

    1. grâce à seccomp-bpf, seuls les appels systèmes dit "intéressant" provoquent un déroutement de l'exécution, c'est donc moins coûteux que PTRACE_SYSCALL où le processus est arrêté à chaque appel système, une fois en entrée et une fois en sortie.

    2. grâce à ptrace, il possible d'appliquer des règles qui seraient impossible à écrire avec la syntaxe PBF, comme par exemple interdire open("/etc/fstab", …) mais autoriser tous les autres open(). Il est même possible de modifier les paramètres des appels systèmes (c.f. PRoot).

    • [^] # Re: Autres projets utilisant seccomp-bpf

      Posté par . Évalué à 2.

      seccomp-bpf semble aussi compliqué que les autres solutions à mettre en place.

      Il faudrait que quelqu'un écrive une library pour protéger le système, qui n'autoriserait que la lecture écriture dans un répertoire pointé, l'interdiction de passer root, l'interdiction de fork,…

      C'est bien trop facile de donner trop de permissions à un gros outil qui ne fait que manipuler des données utilisateurs.

      "La première sécurité est la liberté"

      • [^] # Re: Autres projets utilisant seccomp-bpf

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

        Encore une fois l'idée est que ce sont les développeurs des applications qui écriront les filtres seccomp qui vont bien. Comme le travail sera fait en amont (par ceux qui connaissent leur propre code) toutes les distros en profiteront.

        Après ça c'est la théorie. Il faut faire du prosélytisme pour que les devs soient au courant et se penchent sur ce sujet.

        • [^] # Re: Autres projets utilisant seccomp-bpf

          Posté par . Évalué à 4.

          Le problème c'est que ça rajoute des spécifités linux et que tout le monde n'a pas envie d'ajouter à loisir ce genre de choses.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Autres projets utilisant seccomp-bpf

          Posté par . Évalué à 2.

          Je comprends bien la finesse que peut avoir la démarche d'impliquer les développeurs. C'est le principe des "capabilities" que fait tomber un programme au début de son lancement, pour que du code injecté puisse lancer certaine fonction système.

          Le problème est qu'un gros programme commence à avoir de gros besoin. Si on ouvre tout, car on fait tout, on ne protège plus rien. C'est plus facile d'avoir des "niveaux de sécurités", définit par une seul lib qui protège certain type d'attaque (corruption de donné local ou pas, de binaire, du réseau, etc…).

          C'est à mon avis hypersimple de faire une boulette avec seccomp qui permet d'ouvrir un shell ou autre chose qui permet ensuite d'avoir accès presque à tout (genre /dev/sda1 accessible dans un chroot).

          "La première sécurité est la liberté"

        • [^] # Re: Autres projets utilisant seccomp-bpf

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

          l'idée est que ce sont les développeurs des applications qui écriront les filtres seccomp qui vont bien.

          Il y a quelque chose qui m'échappe, là.

          Si j'ai bien compris, seccomp est censé protéger le système de choses malsaines que pourraient faire des applications mal écrites ou malveillantes. Et l'idée serait donc que les développeurs de ces applications écrivent les filtres censés protéger le système ? Il n'y aurait pas un souci d'œuf et de poule ?

          À moins, bien sur, que ce ne soit du lennardisme ?…

          * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

          • [^] # Re: Autres projets utilisant seccomp-bpf

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

            Donc les développeurs ne corrigent jamais les dépassements de tampons et autres failles dans leurs applications ?
            En général les développeurs font des programmes avec bienveillance et mettent des protection pour éviter qu'une personne profite de leur programme pour s'infiltrer.

            Ce n'est donc pas idéal car cela nécessite faire confiance mais c'est mieux que rien.

          • [^] # Re: Autres projets utilisant seccomp-bpf

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

            Non, le but est que le développeur d'une application bien écrite ou bienveillante évite qu'on puisse utiliser msn application pour faire n'importe quoi, en utilisant les droits qui vont avec. Par exemple, Google veut éviter qu'une faille dans l’interpréteur JavaScript permette de lire tout le dossier /home, il va donc dédié un processus à chaque page et empêcher ce processus de faire un open, même si l’interpréteur est complètement troué, l'attaquant ne pourra pas lire les fichiers de l'utilisateur.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Autres projets utilisant seccomp-bpf

              Posté par . Évalué à 0.

              Mais même si l'application est de bonne foi, rien ne garantit que les règles seccomp sont cohérentes tout comme rien ne garantit qu'elle n'ait pas de faille.

              Personnellement, je suis d'accord avec le commentaire au dessus : je ne pense pas que ça soit à l'application de gérer ce genre de cas.

              Après, rien n'empêche bien sûr de multiplier les mesures de sécurité mais j'ai peur que ça n'empiète sur les performances.

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: Autres projets utilisant seccomp-bpf

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

                Les deux approches sont complémentaires. Tu peux empêcher Chrome de lire /etc/passwd mais tu ne peux pas empêcher (facilement) de l'extérieur un processus de Chrome de lire le fichier où sont stocker les cookies ou les mots de passe, tu ne peux pas non plus empêcher Chrome d'accéder au réseau. Par contre, Chrome peut très bien faire tomber les droits des processus qui ne doivent pas lire dans ces fichiers, ou d'un processus qui ne fait que tu parsage et pas de réseau.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Autres projets utilisant seccomp-bpf

                Posté par . Évalué à 8.

                Personnellement, je suis d'accord avec le commentaire au dessus : je ne pense pas que ça soit à l'application de gérer ce genre de cas.

                Donc tu penses que apache, bind, sshd, postfix et autres daemons devraient tourner 100% en root, par ce que ce n'est pas à eux de gerer ca ?

                seccomp c'est le meme principe que tous les daemons qui démarrent en root, et une fois qu'ils ont terminé les operations qui necessitaient des droits root, changent leur uid en un autre, et pour certains s'enferment dans un chroot. Avec seccomp, en plus de changer d'uid et se mettre dans un chroot, le processus se retire l'accès aux appels systemes qu'il sait ne pas avoir besoin d'utiliser.

                Après, rien n'empêche bien sûr de multiplier les mesures de sécurité mais j'ai peur que ça n'empiète sur les performances.

                Pourquoi est ce que ca empièterait sur les performances ?

                • [^] # Re: Autres projets utilisant seccomp-bpf

                  Posté par . Évalué à -1.

                  Donc tu penses que apache, bind, sshd, postfix et autres daemons devraient tourner 100% en root, par ce que ce n'est pas à eux de gerer ca ?

                  En tout cas ça ne me choque pas. Les MAC type SELinux permettent d'éviter que les process ne sortent de leur champ d'action, même s'ils sont en root.

                  Pourquoi est ce que ca empièterait sur les performances ?

                  Parce que ça demande du traitement en plus, tant dans le noyau pour les MAC que dans les process même pour seccomp. Après pour dire à quel échelle, faut mesurer, l'impact n'est pas forcément négligeable (je pense aux téléphones portables).

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                  • [^] # Re: Autres projets utilisant seccomp-bpf

                    Posté par . Évalué à 3.

                    Donc tu penses que apache, bind, sshd, postfix et autres daemons devraient tourner 100% en root, par ce que ce n'est pas à eux de gerer ca ?

                    En tout cas ça ne me choque pas. Les MAC type SELinux permettent d'éviter que les process ne sortent de leur champ d'action, même s'ils sont en root.

                    Oui mais non, l'idée c'est de dire que les applications peuvent être écrites de façon a simplifier la gestion des droits. Ça rend plus simple l'écriture des politiques de sécurité voir ça la rend possible (parce que les LSM n'ont pas forcément la granularité pour savoir ce quel appel est légal ou pas). Par exemple la technique qui consiste à avoir 2 processus l'un avec les droits important et l'autre en frontal, permet d'avoir une politique de sécurité correct sur n'importe quel unix sans se prendre la tête. C'est par exemple ce qui est fait avec un serveur web et php-fpm et c'est nettement plus pratique à gérer pour l'organisation des ressources comme pour la sécurité.

                    Parce que ça demande du traitement en plus, tant dans le noyau pour les MAC que dans les process même pour seccomp.

                    Faut savoir que ça utilise des filtres bpf qui sont conçu pour la performance et qui sont de plus en plus utilisés dans le noyau (ça a commencé avec le réseau, ils parlaient de s'en service pour tracer le noyau).

                    Après pour dire à quel échelle, faut mesurer, l'impact n'est pas forcément négligeable (je pense aux téléphones portables).

                    Ça a déjà était fait (ça a peut être évolué entre temps).

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Autres projets utilisant seccomp-bpf

                    Posté par . Évalué à 3.

                    En tout cas ça ne me choque pas. Les MAC type SELinux permettent d'éviter que les process ne sortent de leur champ d'action, même s'ils sont en root.

                    Sauf qu'il n'y a pas de moyen de dire "ce fork du processus n'aura pas les droit de faire tel truc tandis que cet autre fork pourra le faire", ou "ce processus a le droit de créer un fichier lors de son démarrage, mais n'a plus le droit lorsqu'il a fini de démarrer". Le moyen le plus simple de faire ca, c'est que le processus se retire les droits lui meme lorsqu'il sait qu'il n'en aura plus besoin.

                    • [^] # Re: Autres projets utilisant seccomp-bpf

                      Posté par . Évalué à 2.

                      Le mieux, c'est de faire les 2 : ceintures et bretelles. Cela permet aussi d'attraper les bugs du logiciels, qui peut avoir des règles plus fines.

                      "La première sécurité est la liberté"

              • [^] # Re: Autres projets utilisant seccomp-bpf

                Posté par . Évalué à 4.

                Après, rien n'empêche bien sûr de multiplier les mesures de sécurité mais j'ai peur que ça n'empiète sur les performances.

                Eh oui, rien n'est gratuit. Apres tout, tu peux enlever les freins et les portes sur ta voiture, elle sera plus legere et plus rapide. Mais quelque chose me dit que c'est pas une bonne idee.

                • [^] # Re: Autres projets utilisant seccomp-bpf

                  Posté par . Évalué à 3.

                  Bien entendu, mais c'est toujours bon de se poser la question du ratio perfs/sécurité.

                  Sur un mobile les perfs c'est critique, ça joue sur la batterie. Ce n'est pas non plus toujours négligeable sur un laptop.

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: Autres projets utilisant seccomp-bpf

                  Posté par . Évalué à 4.

                  Apres tout, tu peux enlever les freins et les portes sur ta voiture, elle sera plus legere et plus rapide.

                  Les freins oui (mais ça doit pas être mesurable), les portes non tu perds en aérodynamisme.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Autres projets utilisant seccomp-bpf

            Posté par . Évalué à 6.

            L'idée c'est d'empêcher les processus d'exécuter du code arbitraire. Quand tu fais un interpréteur (javascript, flash, gostscript,…) tu ne veux pas qu'un code malveillant puisse détruire les données utilisateur. C'est le genre de choses qui aurait permis d'éviter pas mal de failles des lecteurs PDF et flash.

            Une autre technique consiste à faire de la séparation de privilège via de multiples processus.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Autres projets utilisant seccomp-bpf

        Posté par . Évalué à 9.

        Il faudrait que quelqu'un écrive une library pour protéger le système, qui n'autoriserait que la lecture écriture dans un répertoire pointé, l'interdiction de passer root, l'interdiction de fork,…

        Et même qu'on pourrait l'appeler… SELinux.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Et sinon, y a systemd

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

    Alors même si ça ne fait pas exactement la même chose, et que je pense que mettre seccomp dans un programme permet de rajouter un filtre après traitement divers et variés, il est possible d'utiliser systemd pour avoir une partie des avantages de seccomp sans rajouter de code.

    Cf https://lwn.net/Articles/507067/

    perso, je trouve ça un peu contraignant, mais ceci dit, c'est pas pire que selinux à ce niveau la, donc why not ?

    • [^] # Re: Et sinon, y a systemd

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

      C'est marrant, c'est ce que j'imaginais dans un commentaire précédent. Je suis content de voir que Lennart s'intéresse à mes idées.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

Suivre le flux des commentaires

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