Libseccomp: BUG: SCMP_CMP_GT/GE/LT/LE가 부정적인 시스템 호출 인수에 대해 예상대로 작동하지 않습니다.

문제 보고에 감사드립니다. 그거 좋네.

혹시 커널의 samples/seccomp 디렉토리에 있는 headers/macros를 사용하여 재생산기를 작성해

커널의 BPF 코드가 즉각적인 값을 서명된 것으로 취급한다는 인상을 받았습니다. 그렇지 않을 수도 있고 libseccomp 코드에서 뭔가를 망쳤을 수도 있습니다.

FWIW, BPF 자체는 인수에 u32를 사용합니다. libseccomp는 compat 인수에 대해 부호 확장을 수행합니까? (그럴 수도 없지만 "-1"을 일치시키는 규칙은 32비트와 64비트 사이에서 달라야 합니다...)

지금 나를 걱정시키는 문제는 점프 연산자의 BPF GT/GE 비교입니다. 특히 대부분의 사람들이 이러한 비교에 대해 BPF 즉시값을 부호 있는 값으로 취급하고 있다고 생각하기 때문입니다.

@kees 커널의 seccomp-bpf 시스템과 syscall 인수의 서명된 비교를 수행하는 데 권장되는 접근 방식은 무엇입니까? 나는 그것이 "높은 비트를 먼저 확인한 다음 음수를 비교하기 전에 필요한 2의 칭찬 변환을 수행하십시오"라는 라인을 따라 무언가가 아니기를 바랍니다. 성가시지만 필요한 BPF를 생성하도록 libseccomp를 변경할 수 있지만(일부 경우에는 생성된 필터가 훨씬 더 커질 수 있음) 자체 BPF 필터를 생성하는 응용 프로그램에 대해 걱정합니다. 그들이 이것을 올바르게 처리할 확률은 아마도 그리 좋지 않을 것입니다.

불행히도 syscall 인수는 "unsigned long"이기 때문에(syscall_get_arguments() 및 struct seccomp_data 참조) syscall이 부호 변환을 처리하는 방법에 대한 일반적인 경우는 없습니다. compat 장벽을 넘을 때 일부 시스템 호출은 부호 확장을 수행하고 다른 시스템(prctl)은 수행하지 않습니다. 마이너스가 아닌 마이너스 1 시스템 호출 인수가 많이 있습니까?

오늘 이것으로 돌아가서 오늘 아침에 조금 더 놀고 나면 이것이 문서화/"조심하세요!"로 끝날 것이라고 생각합니다. 특히 기존 사용자에 대해 이야기할 때 좋은 솔루션이 없기 때문에 문제가 발생합니다. 커널 측에서 @kees 의 유용한 설명과 함께

FWIW, BPF 자체는 인수에 u32를 사용합니다. libseccomp는 compat 인수에 대해 부호 확장을 수행합니까? (아마 그렇게 해서는 안되지만 "-1"과 일치하는 규칙은 32[-비트와 64비트 사이에서 달라야 합니다...)

libseccomp API 규칙 함수는 모든 즉각적인 값을 _uint64_t_로 해석하므로 유형/캐스팅에 부주의하면 문제가 발생할 수 있습니다. 예:

$ 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

... 우리가 볼 수 있듯이 적절한 캐스팅을 사용하면 값이 부호 확장되지 않습니다. 그러나 나는 이것이 대부분의 사람들이 하는 일이 아닐 것으로 예상합니다. 좋은 소식은 부정적인 인수를 취하는 시스템 호출의 수가 상대적으로 적기 때문에 영향이 다소 제한되어야 한다고 생각한다는 것입니다.

앞으로 우리는 확실히 이것에 대한 문서를 작성하고 _SCMP_A*_ 매크로의 32비트 변형을 구현하여 개발자의 삶을 더 쉽게 만들 수 있는지 확인해야 합니다.

@pcmoore - 자세한 답변에 감사드리며 더 빨리 https://github.com/torvalds/linux/tree/master/samples/seccomp 기반으로 재생산기를 작성하려고 시도하지 않았지만 귀하의 피드백에 따르면 그럴 필요가 없는 것 같습니다. 다른 것이 필요하면 알려주십시오. 지금은 '주의' 방식으로 접근하여 문제가 있는 경우 다시 보고하겠습니다. 앞으로 어떻게 하면 이 문제를 더 쉽게 해결할 수 있을지 기대하겠습니다.

@jdstrand 당분간 모든 준비가 된 것 같습니다. 제보에 다시 한 번 감사드립니다. 더 나은 답변을 드리지 못해 죄송합니다. 하지만 앞으로는 뭔가가 있기를 바랍니다.

그 동안 올바른 유형의 캐스트 값에 문제가 발생하면 언제든지 이 문제를 업데이트하세요.

좋은 소식은 부정적인 인수를 취하는 시스템 호출의 수가 상대적으로 적기 때문에 영향이 다소 제한되어야 한다고 생각한다는 것입니다.

openat()의 fd 매개변수가 -100인 특수 값 AT_FDCWD와 같은지 여부를 확인할 때(무엇보다도) 방금 이 문제에 부딪쳤습니다. 이로 인해 다음이 발생합니다.

  # 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);

위치:

  # 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);

glibc 2.26+는 open()을 구현하기 위해 AT_FDCWD와 함께 openat syscall을 독점적으로 사용하는 것 같기 때문에 많은 사람들이 문제를 일으킬 수 있습니다. 위에서 제안한 대로 uint32_t에 캐스트를 적용하면 문제가 해결되었습니다.

        // 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) }},

명시적인 SCMP_A0_U32가 있으면 좋을 것입니다.

@drakenclimber @jdstrand @michaelweiser 여러분은 https://github.com/pcmoore/misc-libseccomp/commit/b9ce39d776ed5a984c7e9e6db3b87463edce82a7 에 대한 수정 사항에 대해 어떻게 생각하십니까?

@pcmoore : 계속해서 조사해주셔서 감사합니다! 방금 소용돌이를 주었고 코드에서 정말 멋지게 보입니다.

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) }},

불행히도 도우미 함수는 구조체 이니셜라이저로 적합하지 않은 것 같습니다.

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),
     ^~~~~~~~~~

@michaelweiser 리뷰에 감사드립니다. 불행히도 사람들이 이 매크로를 이니셜라이저로 사용하고 있다고 생각하지 않았습니다.

나는 이것에 대해 조금 생각해야 할 것입니다 ... 우아한 방식으로 이것을 해결하는 방법에 대한 아이디어가 있습니까?

몰라, 미안, 이미 성냥으로 눈을 뜨고 있었어. :)

지금 보니 문제가 있는 것 같습니다. 가변 인수 목록으로 인해 필요한 캐스트를 삽입할 수 없습니다. 그렇죠?

scmp_arg_cmp에 올바른 너비, 정렬(및 아마도 바이트 순서)(IMO가 "우아한"과 다소 충돌함)을 사용하여 데이터에 대해 다른 보기를 제공하는 통합이 포함될 수 있습니까? 그것이 순전히 libseccomp 내부에 있고 커널 인터페이스와 호환될 필요가 없다면, 데이터 유형 표시기를 별도의 필드로 갖고 사용자 기능이 이를 정렬하도록 할 수 있습니까? 그리고 varargs를 사용하여 초기화할 수도 있습니까?

그렇지 않으면 연산을 전체 32/64비트로 표시하는 대신 피연산자에 주석을 달아 캐스트를 래핑하고 디버깅하기 어려운 문제에 직면했을 때 항상 해당 주석을 사용하도록 사용자에게 엄격한 권장 사항을 제공할 수 있습니다. ?

{ 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)) }},

또는

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

더 많은 것을 생각해내기에는 전처리기 크랙이 부족합니다. 죄송합니다.

@pcmoore , 변경 사항이 좋아 보입니다. 저는 전처리기 전문가는 아니지만 @michaelweiser가 위에서 언급한 문제를 살펴보겠습니다.

지금 보니 문제가 있는 것 같습니다. 가변 인수 목록으로 인해 필요한 캐스트를 삽입할 수 없습니다. 그렇죠?

예, 그 정도입니다. 아마도 그 주위에 끔찍한 방법이 있지만 아직 찾지 못했습니다.

scmp_arg_cmp에 올바른 너비, 정렬(및 아마도 바이트 순서)(IMO가 "우아한"과 다소 충돌함)을 사용하여 데이터에 대해 다른 보기를 제공하는 통합이 포함될 수 있습니까? 그것이 순전히 libseccomp 내부에 있고 커널 인터페이스와 호환될 필요가 없다면, 데이터 유형 표시기를 별도의 필드로 갖고 사용자 기능이 이를 정렬하도록 할 수 있습니까? 그리고 varargs를 사용하여 초기화할 수도 있습니까?

scmp_arg_cmp 구조체가 libseccomp API의 일부라는 문제가 있으므로 libseccomp 주 버전을 범프하지 않는 한 구조체의 크기나 멤버 필드의 오프셋을 실제로 변경할 수 없습니다. 그렇게 하면 기존 응용 프로그램과의 기존 바이너리 인터페이스가 손상됩니다. 64비트 데이터 필드를 64비트 또는 32비트 값을 포함하는 공용체로 변환하는 것은 그 자체로 괜찮지만 scmp_arg_cmp 구조체에 몇 가지 추가 정보를 추가하여 사용할 공용체 구성원을 표시해야 합니다. ; 문제가 될 수 있는 것은 이 추가 플래그입니다.

"arg" 또는 "op" 필드에서 일부 비트를 훔치는 것이 가능할 수 있습니다. 둘 다 32비트 값이고 해당 공간의 일부만 사용합니다. 그러나 나는 그것이 다소 극단적인 선택이라고 생각하고 가능하다면 그것을 피하고 싶습니다.

그렇지 않으면 연산을 전체 32/64비트로 표시하는 대신 피연산자에 주석을 달아 캐스트를 래핑하고 디버깅하기 어려운 문제에 직면했을 때 항상 해당 주석을 사용하도록 사용자에게 엄격한 권장 사항을 제공할 수 있습니다. ?

피연산자를 매크로로 감싸서 얻을 수 있는 것이 무엇인지 잘 모르겠습니다. 좀 더 자세히 설명해 주시겠습니까? 데이터 값을 래핑하는 매크로를 제공할 수 있지만 이는 호출자에게 적절한 캐스팅을 제공하도록 요청하는 것과 실제로 다르지 않습니다.

@pcmoore , 변경 사항이 좋아 보입니다. 저는 전처리기 전문가는 아니지만 @michaelweiser가 위에서 언급한 문제를 살펴보겠습니다.

감사합니다. 바라건대 우리 셋이 여기서 유용한 것을 생각해낼 수 있기를 바랍니다.

@pcmoore : http://efesx.com/2010/07/17/variadic-macro-to-count-number-of-arguments/ 및 http://efesx.com/2010/08/31/overloading- 매크로/ 나는 다음을 생각해냅니다.

#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__)

이 테스트 케이스의 경우:

        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),
        };

gcc-7.4.0 -E 및 clang-7 -E 에서 다음과 같이 나옵니다.

 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)}),
 };

SCMP_A[0-5]_43 가 작동하려면 op 이상이 필요하고 SCMP_CMP32 가 arg 가 필요하다고 가정하면 해당 매개변수를 위치 지정하여 두 줄을 저장할 수 있습니다.

#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__)

잘했어 @michaelweiser! 변경 사항을 좀 더 쉽게 검토/설명할 수 있도록 PR을 통합하고 싶습니까? 그렇지 않은 경우 완벽하게 괜찮습니다. 하나를 함께 던져서 많은 크레딧을 얻을 수 있는지 확인합니다. :)

오늘 밤의 프로젝트를 홍보하겠습니다. https://github.com/pcmoore/misc-libseccomp/commit/b9ce39d776ed5a984c7e9e6db3b87463edce82a7 또는 처음부터?
Blogger Roman의 과부하 솔루션을 어떻게 인정합니까? https://kecher.net/overloading-macros/ 에서 그의 블로그의 현재 집으로 보이는 것을 찾았습니다 macro_dispatcher 논리 위의 게시물에 대한 링크와 함께 댓글을 작성하시겠습니까?

오늘 밤의 프로젝트를 홍보하겠습니다. pcmoore@b9ce39d 위에 또는 처음부터?

좋아요, 감사합니다! 계속해서 마스터 브랜치를 기반으로 하십시오. 저는 misc-libseccomp 트리의 내용을 병합하지 않았으며 귀하의 접근 방식이 훨씬 더 좋기 때문에 이 시점에서 계획하지 않습니다.

Blogger Roman의 과부하 솔루션을 어떻게 인정합니까? https://kecher.net/overloading-macros/ 에서 그의 블로그의 현재 집으로 보이는 것을 찾았습니다 macro_dispatcher 논리 위의 게시물에 대한 링크와 함께 댓글을 작성하시겠습니까?

우리는 일반적으로 라이선스 요구 사항이 없는 한 소스에 직접 사람을 표시하지 않습니다. 나는 Roman에게 기본 아이디어를 제공하고 그의 블로그 게시물에 대한 링크를 제공하는 패치 설명에 주석을 추가하는 것이 좋습니다. 나는 그의 예에 대한 라이선스나 제한을 보지 못했기 때문에 문제가 있다고 생각하지 않으며 그의 블로그 샘플을 기반으로 하여 그의 의도는 이러한 아이디어를 다른 사람들과 공유하는 것이라고 생각합니다. ) 문제를 해결하는 데 도움이 됩니다. 로만의 이메일 주소가 있다면 항상 그에게 이메일을 보낼 수 있습니다. 어떤 이유로든 그에게 연락할 수 없다면 계속하는 것이 좋다고 생각합니다.

80a987d6f8d0152def07fa90ace6417d56eea741을 통해 해결되었습니다.