Salut @srd424. Je veux m'assurer que je comprends ce que vous demandez dans ce problème ... il me semble que vous aimeriez essentiellement savoir si libseccomp "connaît" un appel système donné, peu importe si cet appel système particulier est implémenté sur cette arche /ABI, oui ?

Si c'est le cas, je pense que vous devriez pouvoir utiliser seccomp_syscall_resolve_name(...) pour obtenir les informations que vous souhaitez. Si la valeur de retour est __NR_SCMP_ERROR alors l'appel système est inconnu de libseccomp, s'il est positif alors l'appel système existe dans l'arch/ABI natif, et s'il est négatif alors l'appel système n'existe pas sur l'arch/ natif ABI. Est-ce que ça marche pour toi?

Cela pourrait rendre les filtres .. interminables !

Ce que j'espérais faire, c'est d'avoir une règle de filtrage pour comparer le numéro d'appel système au plus élevé connu, et s'il est supérieur, retourner ENOSYS , sinon retourner EPERM (en supposant que les appels système en liste blanche ont été traités par une règle antérieure.)

Cependant, en regardant les détails de seccomp_rule_add , je ne suis pas sûr que cela fonctionnera .. le numéro d'appel système est traité spécialement. Un filtre bpf brut pourrait vraisemblablement être construit pour faire cela, mais cela va signifier des modifications plus invasives de libseccomp - probablement au-dessus de mon niveau de rémunération !

Il peut être raisonnable ou non d'ajouter une fonctionnalité à libseccomp, car je suppose que le problème d'origine peut survenir pour plusieurs utilisateurs de la bibliothèque. Il semble qu'il s'agisse (juste ?) de générer une action par défaut un peu plus sophistiquée.

Cela pourrait rendre les filtres .. interminables !

Je ne sais pas trop ce que tu veux dire ici... ? L'appel à seccomp_syscall_resolve_name(...) n'affecte pas réellement le filtre, il interroge simplement la base de données interne libseccomp syscall pour effectuer la résolution de l'appel système. Vous pouvez l'appeler une fois, mille fois ou jamais et votre filtre sera exactement le même :)

Ce que j'espérais faire, c'est d'avoir une règle de filtrage comparant le numéro d'appel système au plus élevé connu, et s'il est supérieur, renvoyer ENOSYS, sinon renvoyer EPERM (en supposant que les appels système sur liste blanche ont été traités par une règle antérieure.)

Bon, je pense que je commence à comprendre ce que vous demandez maintenant. Vous voulez que le filtre lui-même, et non le code de l'application, effectue une certaine action (renvoyez ENOSYS dans l'exemple ci-dessus) si l'appel système est inconnu de libseccomp ? Est-ce que c'est essentiellement ça, ou est-ce que j'ai encore raté quelque chose ?

Ce commentaire dans le deuxième fil mentionné ci-dessus m'a fait sourire :+1:

J'ai essayé d'ouvrir une discussion sur la gestion d'ENOSYS dans libseccomp à l'adresse
https://github.com/seccomp/libseccomp/issues/286 , mais je ne suis probablement pas
étant très cohérent..

Après avoir lu les discussions que vous avez mentionnées, je pense que je suis sur la même page.

Si quelqu'un (libseccomp, nspawn, whoever) pouvait retourner ENOSYS , alors la glibc essaiera de se replier du nouvel appel système, par exemple openat2 , vers l'ancien appel système, par exemple openat . Le retour de EPERM à la glibc fait simplement penser à la glibc que l'appel n'était pas autorisé, et la glibc abandonnera. Est-ce une reformulation juste du commentaire initial dans ce numéro?

Je pense que la demande est raisonnable. Je dois réfléchir un peu plus si libseccomp peut répondre à ces besoins, mais je n'ai aucune objection à ce stade. Il existe certainement des possibilités d'améliorer l'expérience de l'utilisateur final ici.

Merci pour le RFE.

Si quelqu'un (libseccomp, nspawn, whoever) pouvait retourner ENOSYS , alors la glibc essaiera de se replier du nouvel appel système, par exemple openat2 , vers l'ancien appel système, par exemple openat . Le retour de EPERM à la glibc fait simplement penser à la glibc que l'appel n'était pas autorisé, et la glibc abandonnera. Est-ce une reformulation juste du commentaire initial dans ce numéro?

Oui, cela sonne juste. L'opinion des gens de systemd est qu'EPERM est raisonnable la plupart du temps pour les appels système refusés, vraisemblablement car il transmet "non autorisé" à l'utilisateur final / administrateur. D'où l'idée de faire la distinction entre les "nouveaux" et les "anciens" appels système et de faire ENOSYS pour tout ce qui n'est pas reconnu. Je suppose que nous ne voulons pas énumérer et tester chaque appel système dans le BPF pour des raisons de performances.

Ce serait intéressant de savoir ce que docker, podman, lxc etc. font avec leur filtrage seccomp, pour voir s'ils en bénéficieraient. En attendant, j'ai publié un correctif pour nspawn qui permettrait la journalisation des événements seccomp, ce qui rendrait le débogage un peu plus facile.

Je pense que la demande est raisonnable. Je dois réfléchir un peu plus si libseccomp peut répondre à ces besoins, mais je n'ai aucune objection à ce stade. Il existe certainement des possibilités d'améliorer l'expérience de l'utilisateur final ici.

Merci pour le RFE.

Je suis d'accord avec @drakenclimber , cette demande semble raisonnable, je pense que j'ai juste besoin de plus de temps pour réfléchir aux solutions possibles :)

À un niveau assez basique, cela est similaire à RFE #11, et en fin de compte, cela peut être le moyen le plus simple de l'implémenter d'une manière qui n'est pas terrible pour les applications : une application peut spécifier une version maximale de l'API du noyau prise en charge, par exemple v5.8 (évidemment tokenisé), ainsi qu'une action donnée pour tout au-delà, puis libseccomp gère le reste. Cela fonctionnerait-il pour vous les gars @srd424?

Bonjour, cela a également été discuté dans https://github.com/systemd/systemd/pull/16739.

une application peut spécifier une version maximale de l'API du noyau prise en charge, par exemple v5.8 (évidemment tokenisée), ainsi qu'une action donnée pour tout au-delà, puis libseccomp gère le reste.

Cela fonctionnerait très bien. Dans systemd/systemd-nspawn, nous voudrions renvoyer des errnos personnalisés pour tous les appels système explicitement autorisés et refusés, EPERM pour tous les autres dans la "version de l'API du noyau prise en charge" et ENOSYS pour les nouveaux.

Je pense que la mise en œuvre ne serait pas trop compliquée. Par exemple pour amd64, les appels système "connus" peuvent être exprimés sous la forme n <= 181 || 186 <= n <= 235 || 237 <= n <= 334 || 424 <= n <= 439 . Et de telles expressions peuvent être facilement générées par programme à partir des tables d'appel système.

94 pourrait être lié aussi.

Je suis sous-caféiné ce matin, mais la gestion d'ENOSYS nous donnerait-elle alors la possibilité de transformer de grandes listes d'autorisation en petites listes de refus pour une éventuelle victoire en performance ?

Je pense que la mise en œuvre ne serait pas trop compliquée. Par exemple pour amd64, les appels système "connus" peuvent être exprimés sous la forme n <= 181 || 186 <= n <= 235 || 237 <= n <= 334 || 424 <= n <= 439. Et de telles expressions peuvent être facilement générées par programme à partir des tables d'appel système.

Comme vous y faites allusion, le BPF réel sera à la fois spécifique à l'arch/ABI et à la version du noyau. Dans l'exemple x86_64 ci-dessus, le BPF ne sera pas trop mauvais, mais nous n'aurons pas cette chance pour les autres arches/versions. Quoi qu'il en soit, il s'agit maintenant de deux problèmes qui demandent effectivement la même chose, donc je pense que c'est quelque chose que nous voudrons faire ... Je ne vais tout simplement pas commencer à sauter de haut en bas sur la facilité avec laquelle cela va être pour l'instant ; )

94 pourrait être lié aussi.

En quelque sorte oui, en quelque sorte non. Cela implique des plages, mais # 94 concerne les plages d'arguments spécifiées par l'appelant (ce qui est toujours quelque chose que je pense que nous voulons faire, le PR vient d'arriver à un mauvais moment et je pense que l'API a besoin de quelques ajustements) alors que nous parlons de des plages d'appels système implicitement créées qui sont générées par la bibliothèque elle-même.

Je suis sous-caféiné ce matin, mais la gestion d'ENOSYS nous donnerait-elle alors la possibilité de transformer de grandes listes d'autorisation en petites listes de refus pour une éventuelle victoire en performance ?

Du point de vue de l'application, par exemple systemd, si vous essayez de bloquer les "nouveaux" appels système, alors oui ... en supposant que nous parlons de la même chose :)

Pour être plus précis .. pour le moment, quiconque essaie de bloquer _de manière sécurisée_ certains appels système doit effectivement être autorisé, car vous ne pouvez pas être sûr des appels système qu'un noyau plus récent pourrait ajouter. Si nous pouvons demander à libseccomp de bloquer automatiquement les appels système inconnus, cela signifie-t-il que nous pouvons passer en toute sécurité à une petite liste de refus ?

Pour être plus précis .. pour le moment, quiconque essaie de bloquer _de manière sécurisée_ certains appels système doit effectivement être autorisé, car vous ne pouvez pas être sûr des appels système qu'un noyau plus récent pourrait ajouter. Si nous pouvons demander à libseccomp de bloquer automatiquement les appels système inconnus, cela signifie-t-il que nous pouvons passer en toute sécurité à une petite liste de refus ?

J'espère sincèrement que nous pourrons y arriver, car ce serait une fonctionnalité absolument géniale. Par exemple, Docker utilise actuellement une liste d'autorisation et leur liste par défaut est maintenant d'environ 240 appels système (et toujours en croissance).

L'impact sur les performances d'une liste aussi longue peut être prohibitif. Notez que cela peut être quelque peu atténué en utilisant la fonctionnalité d'arbre binaire que nous avons ajoutée dans la v2.5.

Pour être plus précis .. pour le moment, quiconque essaie de bloquer _de manière sécurisée_ certains appels système doit effectivement être autorisé, car vous ne pouvez pas être sûr des appels système qu'un noyau plus récent pourrait ajouter. Si nous pouvons demander à libseccomp de bloquer automatiquement les appels système inconnus, cela signifie-t-il que nous pouvons passer en toute sécurité à une petite liste de refus ?

Je ne vois pas comment cela pourrait fonctionner. Inconnu de libseccomp et inconnu de l'auteur de la liste de refus signifient généralement des choses différentes. Ce qui signifie que le problème conceptuel ne disparaîtra pas même si libseccomp a une image plus claire des appels système pris en charge en interne.

Bon point - je suppose que nous aurions besoin d'ensembles bien définis étiquetés par version du noyau pour que cela fonctionne, ce qui semble être un peu discuté.

Je pense que la mise en œuvre ne serait pas trop compliquée. Par exemple pour amd64, les appels système "connus" peuvent être exprimés sous la forme n <= 181 || 186 <= n <= 235 || 237 <= n <= 334 || 424 <= n <= 439. Et de telles expressions peuvent être facilement générées par programme à partir des tables d'appel système.

Comme vous y faites allusion, le BPF réel sera à la fois spécifique à l'arch/ABI et à la version du noyau. Dans l'exemple x86_64 ci-dessus, le BPF ne sera pas trop mauvais, mais nous n'aurons pas cette chance pour les autres arches/versions. Quoi qu'il en soit, il s'agit maintenant de deux problèmes qui demandent effectivement la même chose, donc je pense que c'est quelque chose que nous voudrons faire ... Je ne vais tout simplement pas commencer à sauter de haut en bas sur la facilité avec laquelle cela va être pour l'instant ; )

Les tableaux sont assez continus :

>>> l = {int(s[1]):s[0] for s in (s.split() for s in open('syscalls-x86_64').readlines()) if len(s)>1}; x = np.array(sorted(l.keys())); np.diff(x)
array([ 1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  5,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1, 90,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1])
>>> l = {int(s[1]):s[0] for s in (s.split() for s in open('syscalls-alpha').readlines()) if len(s)>1}; x = np.array(sorted(l.keys())); np.diff(x)
array([ 1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  2,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  3,  1,  2,  1,  1,
        1,  1,  1,  2,  1,  1,  1,  3, 12,  3,  3,  1, 11,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        2,  1,  1,  1,  1,  1,  1,  5,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1, 39,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  2,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  2,  1,  1,  1,  1,  3,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        2,  1,  1,  1])
>>> l = {int(s[1]):s[0] for s in (s.split() for s in open('syscalls-arm').readlines()) if len(s)>1}; x = np.array(sorted(l.keys())); np.diff(x)
array([1, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 2, 1, 1, 3, 1, 1, 2, 1, 2, 3, 4,
       1, 2, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 2, 1, 1, 1, 2, 1, 2, 3, 1, 1,
       1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 2, 2, 1, 1, 1, 3,
       1, 1, 1, 1, 1, 1, 2, 1, 3, 1, 1, 1, 1, 1, 3, 3, 1, 1, 2, 1, 1, 1,
       1, 2, 1, 1, 2, 1, 2, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1])
>>> l = {int(s[1]):s[0] for s in (s.split() for s in open('syscalls-riscv64').readlines()) if len(s)>1}; x = np.array(sorted(l.keys())); np.diff(x)
array([  1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   2,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,  16,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1, 130,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1])

J'ai implémenté un filtre d'appels système "connus" pour systemd-nspawn dans https://github.com/systemd/systemd/pull/16819. https://github.com/systemd/systemd/pull/16819/commits/158e30ffd9355a7640a7276276eb9219b6c87914 contient un dump de certains programmes générés par libseccomp. Ces dumps sont longs, je ne les répéterai donc pas ici, mais SCMP_FLTATR_CTL_OPTIMIZE rend le programme plus efficace, mais aussi plus long. Les choses pourraient être rendues environ 50 fois plus courtes en utilisant des comparaisons de portée.

Je viens juste de trouver ce fil, juste pour dire que j'ai pensé à des lignes similaires et c'est certainement quelque chose que Docker/runc aurait également aimé résoudre. Le faire avec une version maximale du noyau est probablement la meilleure façon de le faire, car cela signifie que les rédacteurs de profils (et les environnements d'exécution de conteneur) n'ont pas besoin de suivre les appels système ajoutés dans le désordre ou quel était le dernier appel système au moment de l'écriture Le profil.

Sur la base de la discussion ci-dessus, il semble que la plupart (tous ?) des personnes ici pensent que le problème #11 est la bonne façon de résoudre ce problème ; Quelqu'un a-t-il un problème avec la fermeture de ce problème en faveur du déplacement des discussions futures vers le problème d'origine (#11) ?