Libseccomp: RFE : prise en charge de la "version maximale du noyau"

+1
Cela aiderait à rendre les listes noires utilisables pour atténuer les problèmes de sécurité.

@nmav pour être clair, ce RFE sert à ajouter des informations aux tables d'appels système internes sur le moment où l'appel système a été introduit pour la première fois dans le noyau Linux, et non à ajouter une logique pour déterminer si le noyau en cours d'exécution prend en charge un appel système donné. Cependant, si vous essayez de bloquer un appel système, vous pouvez le faire avec libseccomp, qu'il soit pris en charge ou non sur une version particulière de l'architecture/ABI et du noyau, libseccomp fera ce qu'il faut pour vous.

Ce RFE a presque cinq ans, et en dehors d'une seule discussion avec @cgwalters, je n'ai pas vu ou entendu beaucoup d'autres intérêts pour une telle fonctionnalité. Avec de nombreux autres problèmes ouverts, la plupart avec une priorité plus élevée, il n'est pas clair quand nous travaillerions sur cela, ou même si une telle chose serait un ajout utile.

@cgwalters et @drakenclimber que pensez-vous de ce problème en 2020 ? Je suis tenté de fermer cela en tant que WONTFIX, mais j'aimerais obtenir des commentaires et des commentaires avant de franchir cette étape.

@cgwalters et @drakenclimber que pensez-vous de ce problème en 2020 ? Je suis tenté de fermer cela en tant que WONTFIX, mais j'aimerais obtenir des commentaires et des commentaires avant de franchir cette étape.

Honnêtement, je pense que c'est une idée vraiment cool. Plusieurs de mes clients internes utilisent des listes d'autorisation pour cette raison précise. S'ils utilisaient une liste de blocage et qu'un nouvel appel système était ajouté au noyau, cet appel système constituerait une autre voie d'attaque.

Laissons-le ouvert un peu plus longtemps. Je vais demander au sein d'Oracle et voir si des clients sont suffisamment intéressés par cette fonctionnalité pour que je la prenne. Mais @cgwalters (ou n'importe qui d'autre d'ailleurs) est tout à fait le bienvenu pour le posséder s'ils ont le temps et l'intérêt :).

D'accord, tant qu'il y a de l'intérêt, je n'ai aucun problème à garder celui-ci ouvert.

Je pense toujours que ce serait utile !

Il semble que le numéro 286 soit le problème concret pour aider à faire avancer ce travail ... même si cela fait presque cinq ans ;)

Je pense que la première étape dans cette direction consiste à ajouter un nouveau champ au fichier syscalls.csv qui indique quand l'appel système a été introduit pour la première fois. Cela va représenter une bonne partie du travail car nous avons actuellement environ 469 appels système définis (!). Cependant, nous pourrions amortir ce travail pour les appels système existants avec une valeur "indéfinie" que nous traiterions simplement comme l'appel système créé à la nuit des temps. Bien sûr, tous les nouveaux ajouts à la table syscalls.csv devront être ajoutés avec la version du noyau.

Quelques réflexions plus rapides :

• format appelsyst.csv

#syscall (v5.8.0-rc5 2020-07-14),kver_min,x86,x86_64,...
accept,<version>,PNR,43,...

... où <version> pourrait être quelque chose comme "5_8", "UNDEF", ou similaire.

• jetons de version

enum kernel_version {
    KV_UNDEF = 0,
    KV_1_0,
    KV_1_1,
    KV_1_3,
    KV_2_0,
    ...
    KV_5_8,
    _KV_MAX,
};

La version du noyau est-elle la bonne chose à suivre ? Est-il garanti que les nouveaux appels système ne sont pas rétroportés vers, par exemple, des branches stables du noyau avec un numéro de version inférieur ?

Red Hat rétroportera toutes sortes de choses sur leurs noyaux, donc non.

Si RedHat rétroporte un appel système vers une ancienne version du noyau, ils peuvent également corriger leur version de libseccomp pour qu'elle corresponde. Bien que pour être juste, cela puisse avoir plus d'importance pour certains cas d'utilisation, mais en tant qu'approche pour réparer le # 286, je pense que c'est assez réalisable. L'autre problème est que je ne suis pas sûr qu'il existe une meilleure approche - les appels système peuvent être ajoutés dans un ordre non consécutif (par exemple, openat2 a été ajouté avant close_range - bien que cet exemple soit gentil de ma faute).

Si RedHat rétroporte un appel système vers une ancienne version du noyau, ils peuvent également corriger leur version de libseccomp pour qu'elle corresponde.

Oui, exactement. Le projet libseccomp en amont n'a aucun contrôle sur les différentes distributions Linux d'entreprise et si ces distributions décident de s'écarter des projets en amont (soit le noyau Linux, soit libseccomp), elles sont seules pour le support. Bien que nous fassions de notre mieux pour vous aider, nous ne pouvons pas sacrifier le projet en amont au profit de ces distributions d'entreprise avec leur propre personnel d'assistance et d'ingénierie.

Comme point de référence, la page de manuel syscalls(2) contient des informations historiques sur le moment où divers appels système ont été introduits dans le noyau :

• https://www.mankier.com/2/syscalls

Je peux faire la spéléologie des appels système pour déterminer un numéro de version pour chaque appel système - la seule question est de savoir si nous devrions avoir le numéro de version par architecture car je suis presque sûr que certains appels système ont été ajoutés à différentes architectures dans différentes versions.

... la seule question est de savoir si nous devrions avoir le numéro de version par architecture, car je suis presque sûr que certains appels système ont été ajoutés à différentes architectures dans différentes versions.

Ils l'étaient très certainement, et le sont toujours, pour autant que je sache. Même si cela va être légèrement ennuyeux et va certainement exploser le CSV, suivre la première apparition de l'appel système pour chaque arch/ABI est probablement la bonne chose à faire.

Toute aide que vous pouvez fournir sur ce @cyphar serait grandement appréciée.