Libseccomp: BUG: SCMP_CMP_GT/GE/LT/LE funktioniert nicht wie erwartet für negative Systemaufrufargumente

Danke für den Problembericht; das ist gut so.

Haben Sie zufällig versucht, den Reproduzierer mit den Headern/Makros im Samples/seccomp- Verzeichnis des Kernels zu

Ich hatte den Eindruck, dass der BPF-Code im Kernel die unmittelbaren Werte als signiert behandelt; das ist möglicherweise nicht der Fall, oder ich habe etwas im libseccomp-Code vermasselt.

FWIW, BPF selbst verwendet u32 für seine Argumente. Führt libseccomp eine Zeichenerweiterung für Compat-Argumente durch? (Das sollte es wahrscheinlich nicht, aber dann müssen die Regeln für die Übereinstimmung mit "-1" zwischen 32-Bit und 64-Bit unterschiedlich sein ...)

Das Problem, das mich im Moment beunruhigt, sind die BPF GT/GE-Vergleiche im Sprungoperator, zumal ich vermute, dass fast jeder den BPF-Sofortwert als Vorzeichenwert für diese Vergleiche behandelt.

@kees Was ist der empfohlene Ansatz, um signierte Vergleiche von Syscall-Argumenten mit der seccomp-bpf-Maschine des Kernels durchzuführen? Ich hoffe, es ist nicht so etwas wie "Überprüfen Sie zuerst das High-Bit und führen Sie dann die erforderliche Zweier-Komplement-Konvertierung durch, bevor Sie negative Zahlen vergleichen". Es ist zwar ärgerlich, aber wir können libseccomp jederzeit ändern, um das erforderliche BPF zu generieren (obwohl die generierten Filter in einigen Fällen jetzt viel größer sind), aber ich mache mir Sorgen um die Anwendungen, die ihre eigenen BPF-Filter erstellen; die Chancen, dass sie dies richtig handhaben, stehen wahrscheinlich nicht sehr gut.

Da Syscall-Argumente "unsigned long" sind (siehe syscall_get_arguments() und struct seccomp_data), gibt es leider keinen allgemeinen Fall dafür, wie ein Syscall Vorzeichenkonvertierungen handhabt. Einige Systemaufrufe führen beim Überschreiten der Compat-Barriere zur Zeichenerweiterung, andere (prctl) nicht. Gibt es viele negative-aber-nicht-minus-eins-Systemaufrufargumente?

Um heute darauf zurückzukommen, und nachdem ich heute Morgen ein bisschen mehr mit den Dingen gespielt habe, denke ich, dass dies eine Dokumentation sein wird / "Vorsicht!" Problem, da es keine gute Lösung gibt, insbesondere wenn es sich um bestehende Benutzer handelt. Lassen Sie mich versuchen, einige libseccomp-Hintergrundinformationen / Erklärungen bereitzustellen , um die hilfreichen Kommentare von

FWIW, BPF selbst verwendet u32 für seine Argumente. Führt libseccomp eine Zeichenerweiterung für Compat-Argumente durch? (Das sollte es wahrscheinlich nicht, aber dann müssen die Regeln für die Übereinstimmung mit "-1" zwischen 32[-Bit und 64-Bit unterschiedlich sein ...)

Die Regelfunktionen der libseccomp-API interpretieren alle unmittelbaren Werte als _uint64_t_. Wenn Sie also mit Ihren Typen/Umsetzungen nachlässig umgehen, können Sie auf Probleme stoßen. Beispiel:

$ cat 00-test.c
    /* ... */
    seccomp_rule_add_exact(ctx, SCMP_ACT_KILL, 1000, 1,
                           SCMP_A0(SCMP_CMP_GT, -1));
    seccomp_rule_add_exact(ctx, SCMP_ACT_KILL, 1001, 1,
                           SCMP_A0(SCMP_CMP_GT, (uint32_t)-1));
    seccomp_rule_add_exact(ctx, SCMP_ACT_KILL, 1002, 1,
                           SCMP_A0(SCMP_CMP_GT, 0xffffffff));
    /* ... */
$ make 00-test
  CC       00-test.o
  CCLD     00-test
$ ./00-test -p
  #
  # pseudo filter code start
  #
  # filter for arch x86_64 (3221225534)
  if ($arch == 3221225534)
    # filter for syscall "UNKNOWN" (1002) [priority: 65533]
    if ($syscall == 1002)
      if ($a0.hi32 >= 0)
        if ($a0.lo32 > 4294967295)
          action KILL;
    # filter for syscall "UNKNOWN" (1001) [priority: 65533]
    if ($syscall == 1001)
      if ($a0.hi32 >= 0)
        if ($a0.lo32 > 4294967295)
          action KILL;
    # filter for syscall "UNKNOWN" (1000) [priority: 65533]
    if ($syscall == 1000)
      if ($a0.hi32 >= 4294967295)
        if ($a0.lo32 > 4294967295)
          action KILL;
    # default action
    action ALLOW;
  # invalid architecture action
  action KILL;
  #
  # pseudo filter code end
  # 
$ ./00-test -b | ../tools/scmp_bpf_disasm 
   line  OP   JT   JF   K
  =================================
   0000: 0x20 0x00 0x00 0x00000004   ld  $data[4]
   0001: 0x15 0x00 0x0c 0xc000003e   jeq 3221225534 true:0002 false:0014
   0002: 0x20 0x00 0x00 0x00000000   ld  $data[0]
   0003: 0x35 0x0a 0x00 0x40000000   jge 1073741824 true:0014 false:0004
   0004: 0x15 0x00 0x02 0x000003e8   jeq 1000 true:0005 false:0007
   0005: 0x20 0x00 0x00 0x00000014   ld  $data[20]
   0006: 0x35 0x04 0x06 0xffffffff   jge 4294967295 true:0011 false:0013
   0007: 0x15 0x01 0x00 0x000003e9   jeq 1001 true:0009 false:0008
   0008: 0x15 0x00 0x04 0x000003ea   jeq 1002 true:0009 false:0013
   0009: 0x20 0x00 0x00 0x00000014   ld  $data[20]
   0010: 0x35 0x00 0x02 0x00000000   jge 0    true:0011 false:0013
   0011: 0x20 0x00 0x00 0x00000010   ld  $data[16]
   0012: 0x25 0x01 0x00 0xffffffff   jgt 4294967295 true:0014 false:0013
   0013: 0x06 0x00 0x00 0x7fff0000   ret ALLOW
   0014: 0x06 0x00 0x00 0x00000000   ret KILL

... wie wir sehen können, wird der Wert bei entsprechender Umformung nicht vorzeichenerweitert. Ich gehe jedoch davon aus, dass dies nicht das ist, was die meisten Leute tun. Die gute Nachricht ist, dass ich mir die Anzahl der Systemaufrufe, die negative Argumente annehmen, als relativ gering vorstelle, sodass die Auswirkungen etwas begrenzt sein sollten.

In Zukunft müssen wir definitiv etwas in die Dokumentation dazu schreiben und sehen, ob wir etwas tun können, um den Entwicklern das Leben zu erleichtern, vielleicht 32-Bit-Varianten der _SCMP_A*_-Makros implementieren.

@pcmoore - danke für die ausführliche Antwort und entschuldige, dass ich nicht früher zurückkomme. Nein, ich habe noch nicht versucht, einen Reproduzierer basierend auf https://github.com/torvalds/linux/tree/master/samples/seccomp zu schreiben, aber basierend auf Ihrem Feedback klingt es so, als ob ich das nicht brauche. Lass es mich wissen, wenn du noch etwas brauchst. Vorerst werde ich den Ansatz „seien Sie vorsichtig“ verfolgen und mich bei Problemen melden. Ich freue mich darauf, wie Sie dies in Zukunft einfacher machen können.

@jdstrand Ich denke, wir sind vorerst alle

Sollten in der Zwischenzeit Probleme mit einem richtig eingegebenen Cast-Wert auftreten, können Sie dieses Problem gerne aktualisieren.

Die gute Nachricht ist, dass ich mir die Anzahl der Systemaufrufe, die negative Argumente annehmen, als relativ gering vorstelle, sodass die Auswirkungen etwas begrenzt sein sollten.

Ich bin gerade auf dieses Problem gestoßen, als ich (unter anderem) überprüfte, ob der fd-Parameter von openat() gleich dem Sonderwert AT_FDCWD ist, der -100 ist. Dies führte zu:

  # filter for syscall "openat" (257) [priority: 131067]
  if ($syscall == 257)
    if ($a0.hi32 == 4294967295)
      if ($a0.lo32 == 4294967196)
        if ($a2.hi32 & 0x00000000 == 0)
          if ($a2.lo32 & 0x00000003 == 0)
            action ERRNO(2);

Wo soll es sein:

  # filter for syscall "openat" (257) [priority: 131067]
  if ($syscall == 257)
    if ($a0.hi32 == 0)
      if ($a0.lo32 == 4294967196)
        if ($a2.hi32 & 0x00000000 == 0)
          if ($a2.lo32 & 0x00000003 == 0)
            action ERRNO(2);

Da Glibc 2.26+ anscheinend ausschließlich den openat-Systemaufruf mit AT_FDCWD verwendet, um open() zu implementieren, könnte dies viele Leute zum Stolpern bringen. Das Anwenden einer Umwandlung auf uint32_t wie oben vorgeschlagen hat das Problem für mich behoben:

        // selector, action, syscall, no of args, args
        { SEL, SCMP_ACT_ERRNO(ENOENT), "openat", 2,
-               { SCMP_A0(SCMP_CMP_EQ, AT_FDCWD), /* glibc 2.26+ */
+               { SCMP_A0(SCMP_CMP_EQ, (uint32_t)AT_FDCWD), /* glibc 2.26+ */
                  SCMP_A2(SCMP_CMP_MASKED_EQ, O_ACCMODE, O_RDONLY) }},

Ein explizites SCMP_A0_U32 wäre sicher schön zu haben.

@drakenclimber @jdstrand @michaelweiser was https://github.com/pcmoore/misc-libseccomp/commit/b9ce39d776ed5a984c7e9e6db3b87463edce82a7 als Fix dafür?

@pcmoore : Vielen Dank, dass Sie sich weiterhin darum kümmern! Ich habe es gerade ausprobiert und es sieht im Code wirklich gut aus:

static struct {
        const uint64_t promises;
        const uint32_t action;
        const char *syscall;
        const int arg_cnt;
        const struct scmp_arg_cmp args[3];
} scsb_calls[] = {
[...]
        { PLEDGE_WPATH, SCMP_ACT_ALLOW, "openat", 2, /* glibc 2.26+ */
                { SCMP_A0_32(SCMP_CMP_EQ, AT_FDCWD),
                  SCMP_A2_64(SCMP_CMP_MASKED_EQ, O_ACCMODE, O_WRONLY) }},

Leider scheint die Hilfsfunktion nicht als Strukturinitialisierer geeignet zu sein:

In file included from pledge.c:42:
/include/seccomp.h:230:26: error: initializer element is not constant
 #define SCMP_CMP32(...)  (__scmp_arg_32(SCMP_CMP64(__VA_ARGS__)))
                          ^
/include/seccomp.h:241:26: note: in expansion of macro ‘SCMP_CMP32’
 #define SCMP_A0_32(...)  SCMP_CMP32(0, __VA_ARGS__)
                          ^~~~~~~~~~
pledge.c:188:5: note: in expansion of macro ‘SCMP_A0_32’
   { SCMP_A0_32(SCMP_CMP_EQ, AT_FDCWD),
     ^~~~~~~~~~
/include/seccomp.h:230:26: note: (near initialization for ‘scsb_calls[21].args[0]’)
 #define SCMP_CMP32(...)  (__scmp_arg_32(SCMP_CMP64(__VA_ARGS__)))
                          ^
/include/seccomp.h:241:26: note: in expansion of macro ‘SCMP_CMP32’
 #define SCMP_A0_32(...)  SCMP_CMP32(0, __VA_ARGS__)
                          ^~~~~~~~~~
pledge.c:188:5: note: in expansion of macro ‘SCMP_A0_32’
   { SCMP_A0_32(SCMP_CMP_EQ, AT_FDCWD),
     ^~~~~~~~~~

Danke für die Rezension @michaelweiser , leider dachte ich nicht, dass die Leute diese Makros als Initialisierer verwenden, aber das ist eine gültige Verwendung und sicherlich gibt es einige Leute, die es auf diese Weise verwenden.

Ich muss noch ein bisschen darüber nachdenken ... habt ihr Ideen, wie man das elegant lösen könnte?

Keine Ahnung, Entschuldigung, ich hatte meine Augen schon mit Streichhölzern geöffnet. :)

Wenn ich es mir jetzt ansehe, sehe ich das Problem: Aufgrund der variablen Argumentlisten kann man nicht die notwendigen Casts einschleusen, oder?

Könnte scmp_arg_cmp vielleicht eine Union enthalten, die verschiedene Ansichten der Daten mit der richtigen Breite, Ausrichtung (und vielleicht sogar Byte-Reihenfolge) angibt (was IMO irgendwie mit "elegant" kollidiert):? Wenn es rein intern zu libseccomp ist und nicht mit einer Kernel-Schnittstelle kompatibel sein muss, könnte es dann einen Datentypindikator als separates Feld enthalten und die Benutzerfunktionen sortieren lassen? Und könnte das sogar mit Varargs initialisiert werden?

Anstatt die Operation als ganze 32/64-Bit-Operation zu markieren, könnten die Operanden sonst mit Anmerkungen versehen werden, eine Umwandlung umschließen und dem Benutzer (wie Sie) die strenge Empfehlung geben, diese Anmerkungen immer zu verwenden, da sonst schwer zu debuggende Probleme auftreten ?

{ SCMP_A0(SCMP_CMP_EQ, SCMP_OP_32(AT_FDCWD)),
  SCMP_A2(SCMP_CMP_MASKED_EQ, SCMP_OP_64(O_ACCMODE), SCMP_OP_64(O_WRONLY)) }},

oder

{ SCMP_A0(SCMP_CMP_EQ, SCMP_OP1_32(AT_FDCWD)),
  SCMP_A2(SCMP_CMP_MASKED_EQ, SCMP_OP2_64(O_ACCMODE, O_WRONLY)) }},

Ich bin nicht genug von einem Präprozessor-Crack, um mir viel mehr einfallen zu lassen, sorry.

@pcmoore , die Änderungen sehen für mich gut aus. Ich bin kein Präprozessor-Experte, aber ich werde mir das Problem ansehen , das

Wenn ich es mir jetzt ansehe, sehe ich das Problem: Aufgrund der variablen Argumentlisten kann man nicht die notwendigen Casts einschleusen, oder?

Ja, das ist es so ziemlich. Vielleicht gibt es einen nicht schrecklichen Weg, aber ich habe noch keinen gefunden.

Könnte scmp_arg_cmp vielleicht eine Union enthalten, die verschiedene Ansichten der Daten mit der richtigen Breite, Ausrichtung (und vielleicht sogar Byte-Reihenfolge) angibt (was IMO irgendwie mit "elegant" kollidiert):? Wenn es rein intern zu libseccomp ist und nicht mit einer Kernel-Schnittstelle kompatibel sein muss, könnte es dann einen Datentypindikator als separates Feld enthalten und die Benutzerfunktionen sortieren lassen? Und könnte das sogar mit Varargs initialisiert werden?

Wir haben ein Problem darin, dass die scmp_arg_cmp-Struktur Teil der libseccomp-API ist. Wenn wir also die Hauptversion von libseccomp nicht ändern möchten, können wir die Größe der Struktur oder den Offset eines der Mitgliedsfelder nicht wirklich ändern; dies würde die vorhandene binäre Schnittstelle mit vorhandenen Anwendungen zerstören. Das Konvertieren der 64-Bit-Datumsfelder in eine Union, die entweder einen 64-Bit- oder 32-Bit-Wert enthält, sollte an sich in Ordnung sein, aber Sie müssten auch einige zusätzliche Informationen zur scmp_arg_cmp-Struktur hinzufügen, um anzugeben, welches der Unionselemente verwendet werden soll ; Es ist dieses zusätzliche Flag, das problematisch sein könnte.

Es könnte möglich sein, einige Bits aus den Feldern "arg" oder "op" zu stehlen, beide sind 32-Bit-Werte und belegen nur einen Bruchteil dieses Speicherplatzes. Ich halte das jedoch für eine ziemlich extreme Option und möchte dies nach Möglichkeit vermeiden.

Anstatt die Operation als ganze 32/64-Bit-Operation zu markieren, könnten die Operanden sonst mit Anmerkungen versehen werden, eine Umwandlung umschließen und dem Benutzer (wie Sie) die strenge Empfehlung geben, diese Anmerkungen immer zu verwenden, da sonst schwer zu debuggende Probleme auftreten ?

Ich verstehe nicht ganz, was wir gewinnen würden, wenn wir die Operanden mit einem Makro umschließen. Können Sie das etwas genauer ausführen? Wir könnten ein Makro bereitstellen, um die Datumswerte zu umschließen, aber das ist nicht wirklich anders, als Aufrufer nur zu bitten, das richtige Casting bereitzustellen.

@pcmoore , die Änderungen sehen für mich gut aus. Ich bin kein Präprozessor-Experte, aber ich werde mir das Problem ansehen , das

Vielen Dank. Hoffentlich können wir uns hier zu dritt etwas Nützliches einfallen lassen.

@pcmoore : Blick auf http://efesx.com/2010/07/17/variadic-macro-to-count-number-of-arguments/ und http://efesx.com/2010/08/31/overloading- Makros/ Mir fällt folgendes ein:

#define VA_NUM_ARGS(...) VA_NUM_ARGS_IMPL(__VA_ARGS__, 5,4,3,2,1)
#define VA_NUM_ARGS_IMPL(_1,_2,_3,_4,_5,N,...) N
#define macro_dispatcher(func, ...) \
            macro_dispatcher_(func, VA_NUM_ARGS(__VA_ARGS__))
#define macro_dispatcher_(func, nargs) \
            macro_dispatcher__(func, nargs)
#define macro_dispatcher__(func, nargs) \
            func ## nargs

#define SCMP_CMP64(...)         ((struct scmp_arg_cmp){__VA_ARGS__})

#define SCMP_CMP32_1(x)                 SCMP_CMP64(x)
#define SCMP_CMP32_2(x, y)              SCMP_CMP64(x, y)
#define SCMP_CMP32_3(x, y, z)           SCMP_CMP64(x, y, (uint32_t)(z))
#define SCMP_CMP32_4(x, y, z, q)        SCMP_CMP64(x, y, (uint32_t)(z), (uint32_t)(q))
#define SCMP_CMP32(...) macro_dispatcher(SCMP_CMP32_, __VA_ARGS__)(__VA_ARGS__)

#define SCMP_A0_64(...)         SCMP_CMP64(0, __VA_ARGS__)
#define SCMP_A0_32(...)         SCMP_CMP32(0, __VA_ARGS__)

Für diesen Testfall:

        struct scmp_arg_cmp f[] = {
                SCMP_A0_64(SCMP_CMP_EQ, 1, 20),
                SCMP_A0_32(SCMP_CMP_EQ, 2, 3),
                SCMP_A0_32(SCMP_CMP_LT, 2),
        };

es kommt aus gcc-7.4.0 -E und clang-7 -E als:

 struct scmp_arg_cmp f[] = {
  ((struct scmp_arg_cmp){0, SCMP_CMP_EQ, 1, 20}),
  ((struct scmp_arg_cmp){0, SCMP_CMP_EQ, (uint32_t)(2), (uint32_t)(3)}),
  ((struct scmp_arg_cmp){0, SCMP_CMP_LT, (uint32_t)(2)}),
 };

Unter der Annahme, dass SCMP_A[0-5]_43 mindestens op zu funktionieren und SCMP_CMP32 arg , können zwei Zeilen gespeichert werden, indem diese Parameter positionell festgelegt werden:

#define SCMP_CMP32_1(x, y, z)           SCMP_CMP64(x, y, (uint32_t)(z))
#define SCMP_CMP32_2(x, y, z, q)        SCMP_CMP64(x, y, (uint32_t)(z), (uint32_t)(q))
#define SCMP_CMP32(x, y,...)            macro_dispatcher(SCMP_CMP32_, __VA_ARGS__)(x, y, __VA_ARGS__)

#define SCMP_A0_32(x,...)       SCMP_CMP32(0, x, __VA_ARGS__)

Gut gemacht @michaelweiser! Wollten Sie eine PR zusammenstellen, damit wir die Änderungen etwas einfacher überprüfen/kommentieren können? Wenn nicht, ist das völlig in Ordnung, ich werfe einen zusammen und sorge dafür, dass Sie viel Anerkennung erhalten :)

Ich mache das PR-Projekt heute Abend. Oben auf https://github.com/pcmoore/misc-libseccomp/commit/b9ce39d776ed5a984c7e9e6db3b87463edce82a7 oder von Grund auf?
Wie schreiben wir dem Blogger Roman seine Überlastungslösung zu? Gefunden, was die aktuelle Heimat seines Blogs zu sein scheint, unter https://kecher.net/overloading-macros/. Sein Beitrag sieht aus wie die Originalquelle. Kommentar mit Link zum Beitrag über der macro_dispatcher Logik?

Ich mache das PR-Projekt heute Abend. Oben auf pcmoore@b9ce39d oder von Grund auf neu?

Grosses Dankeschön! Gehen Sie voran und stützen Sie es vom Master-Zweig ab. Ich habe das Zeug nie in meinem misc-libseccomp-Baum zusammengeführt und plane dies an dieser Stelle auch nicht, da Ihr Ansatz viel besser ist.

Wie schreiben wir dem Blogger Roman seine Überlastungslösung zu? Gefunden, was die aktuelle Heimat seines Blogs zu sein scheint, unter https://kecher.net/overloading-macros/. Sein Beitrag sieht aus wie die Originalquelle. Kommentar mit Link zum Beitrag über der macro_dispatcher Logik?

Im Allgemeinen schreiben wir Personen nicht direkt in der Quelle gut, es sei denn, es gibt eine Lizenzanforderung; Ich würde empfehlen, in der Patch-Beschreibung einen Kommentar hinzuzufügen, der Roman die Grundidee zuschreibt und einen Link zu seinem Blog-Beitrag enthält. Ich sehe keine Lizenzen oder Einschränkungen für seine Beispiele, daher glaube ich nicht, dass es diesbezüglich Probleme gibt, und basierend auf einer Auswahl seines Blogs glaube ich, dass seine Absicht darin besteht, diese Ideen mit anderen (wie uns) zu teilen ), um ihnen bei der Lösung ihrer Probleme zu helfen. Wenn Sie eine E-Mail-Adresse für Roman haben, können Sie jederzeit versuchen, ihm eine E-Mail zu senden; Wenn wir ihn aus irgendeinem Grund nicht erreichen können, denke ich, dass es in Ordnung ist, fortzufahren.

Behoben über 80a987d6f8d0152def07fa90ace6417d56eea741.