Sommaire
- Problématique
- Comment faire…
- Qu'est-ce-que seccomp ?
- Utilisons seccomp-bpf
- Projets utilisant seccomp-bpf
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 Renault (site web personnel) . É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 karteum59 . Évalué à 3. Dernière modification le 05 mai 2014 à 00:26.
Même question pour RSBAC, SMACK et GrSecurity…
[^] # Re: Et sinon il y a SELinux
Posté par zebra3 . É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 Renault (site web personnel) . É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 akimatsumoto . É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 patrick_g (site web personnel) . Évalué à 5.
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 claudex . É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 Pinaraf . Évalué à 4.
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).
# Docker
Posté par barmic . Évalué à 8.
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
straceest 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 cedric-vincent . Évalué à 4.
Voici deux autres projets utilisant seccomp-bpf:
PRoot: http://proot.me
Sydbox: http://dev.exherbo.org/~alip/sydbox/sydbox.html
Tout comme Mbox, ils utilisent seccomp-bpf couplé à ptrace (SECCOMP_RET_TRACE). Cela a deux avantages:
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.
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 Nicolas Boulay (site web personnel) . É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 patrick_g (site web personnel) . É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 barmic . É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 Nicolas Boulay (site web personnel) . É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 Tonton Th (Mastodon) . Évalué à -2.
Il y a quelque chose qui m'échappe, là.
Si j'ai bien compris,
seccompest 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 ?…
[^] # Re: Autres projets utilisant seccomp-bpf
Posté par Renault (site web personnel) . É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 claudex . É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 zebra3 . É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 claudex . É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 Anonyme . Évalué à 8.
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.
Pourquoi est ce que ca empièterait sur les performances ?
[^] # Re: Autres projets utilisant seccomp-bpf
Posté par zebra3 . Évalué à -1.
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.
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 barmic . Évalué à 3.
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é.
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).
Ç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 Anonyme . Évalué à 3.
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 Nicolas Boulay (site web personnel) . É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 pasBill pasGates . Évalué à 4.
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 zebra3 . É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 barmic . Évalué à 4.
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 barmic . É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 zebra3 . Évalué à 9.
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
[^] # Re: Autres projets utilisant seccomp-bpf
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Non car SELinux est fait par les distribs et non par les codeurs. C'est la principale différence. C'est également dynamique, c'est plus facile de faire des processus à droit minimal.
"La première sécurité est la liberté"
[^] # Re: Autres projets utilisant seccomp-bpf
Posté par zebra3 . Évalué à 3.
Je ne connais pas bien SELinux mais je pense que rien n'empêche les codeurs de fournir un profil pour lui, me trompe-je ?
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 Nicolas Boulay (site web personnel) . Évalué à 3.
Tu ne pourras jamais avoir un profil qui permet de laisser tomber "à un moment", le fork ou l'accès réseau.
"La première sécurité est la liberté"
[^] # Re: Autres projets utilisant seccomp-bpf
Posté par Misc (site web personnel) . Évalué à 4.
Sans rajouter de code, non.
En rajoutant du code ( grosso modo ~ 10 lignes de selinux, plus sans doute une 10 à 20aine de lignes pour ta configuration, ou plus ), tu peux faire une transition d'un type selinux qui a l'accès au réseau à un type qui le supporte pas.
C'est pas trop dur à faire, faut juste s'en tirer avec le peu de code d'exemple qui existe. Par exemple la fonction condSELinuxContext du patch https://lists.fedoraproject.org/pipermail/devel/2013-September/188732.html
Ou ce genre de chose, ou tu forkes après :
http://cgit.freedesktop.org/systemd/systemd/commit/?id=7b52a628f8b43ba521c302a7f32bccf9d0dc8bfd
( ce que iodine fait aussi, par exemple )
https://github.com/yarrick/iodine/blob/eca80f769bfeaa3a33392c569506f1186e3a4654/src/common.c#L241
Et faire une policy qui permette la transition :
http://danwalsh.livejournal.com/23944.html
https://wiki.gentoo.org/wiki/SELinux/Tutorials/How_does_a_process_get_into_a_certain_context
# Et sinon, y a systemd
Posté par Misc (site web personnel) . É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 claudex . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.