Libseccomp: 버그: src/db.c 재작업으로 인해 A2 처리가 깨짐

에 만든 2018년 02월 26일 · 18코멘트 · 출처: seccomp/libseccomp

제안된 이진 트리 성능 향상을 테스트하기 위해 read() 및 버퍼 크기 인수(A2)에 대한 비현실적인 규칙 집합을 작성했습니다. 그러나 적어도 이 테스트 케이스에서는 src/db.c 재작업 커밋(ce3dda9a1)이 A2 처리를 중단한 것으로 보입니다.

db 재작업 커밋 전에 read(devzero_fd, buf, 8000) 와 같은 읽기가 -10 반환했습니다. 이 커밋 후에는 이제 -5 반환합니다.

다음은 어리석은 read() 규칙을 생성하는 데 사용한 C 코드입니다.

        /* read */
        for (i = 5; i <= 12; i++) {
                rc = seccomp_rule_add(ctx, SCMP_ACT_ERRNO(i), SCMP_SYS(read), 1,
                        SCMP_A2(SCMP_CMP_GT, 4 << i));
                if (rc < 0) {
                        fprintf(stdout, "%s:%d Failed to add read rule %d : rc = %d\n",
                                __FUNCTION__, __LINE__, i, rc);
                        goto error;
                }   
        }   
        rc = seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(read), 1,
                SCMP_A2(SCMP_CMP_LE, 64));
        if (rc < 0) {
                fprintf(stdout, "%s:%d Failed to add read allow rule : rc = %d\n",
                        __FUNCTION__, __LINE__, rc);
                goto error;
        }

생성한 PFC는 다음과 같습니다.

  # filter for syscall "read" (0) [priority: 65525]
  if ($syscall == 0)
    if ($a2.hi32 >= 0)
      if ($a2.lo32 > 64)
      else
        action ALLOW;
      if ($a2.lo32 > 16384)
        action ERRNO(12);
      if ($a2.lo32 > 8192)
        action ERRNO(11);
      if ($a2.lo32 > 4096)
        action ERRNO(10);
      if ($a2.lo32 > 2048)
        action ERRNO(9);
      if ($a2.lo32 > 1024)
        action ERRNO(8);
      if ($a2.lo32 > 512)
        action ERRNO(7);
      if ($a2.lo32 > 256)
        action ERRNO(6);
      if ($a2.lo32 > 128)
        action ERRNO(5);
    else
      action ALLOW;
  # default action
  action ERRNO(34);

bug priorithigh

출처

drakenclimber

모든 18 댓글

그건 그렇고, 나는 근본 원인을 돕기 위해 내가 할 수있는 일을 할 것입니다

drakenclimber 에 2018년 02월 26일

scmp_bpf_disasm을 사용하여 최신 libseccomp가 점프를 잘못된 순서로 배치하고 있습니다.

머리

 0014: 0x25 0x11 0x00 0x00000080   jgt 128  true:0032 false:0015
 0015: 0x25 0x0f 0x00 0x00000100   jgt 256  true:0031 false:0016
 0016: 0x25 0x0d 0x00 0x00000200   jgt 512  true:0030 false:0017
 0017: 0x25 0x0b 0x00 0x00000400   jgt 1024 true:0029 false:0018
 0018: 0x25 0x09 0x00 0x00000800   jgt 2048 true:0028 false:0019
 0019: 0x25 0x07 0x00 0x00001000   jgt 4096 true:0027 false:0020
 0020: 0x25 0x05 0x00 0x00002000   jgt 8192 true:0026 false:0021
 0021: 0x25 0x03 0x00 0x00004000   jgt 16384 true:0025 false:0022
 0022: 0x25 0x01 0x00 0x00000040   jgt 64   true:0024 false:0023
 0023: 0x06 0x00 0x00 0x7fff0000   ret ALLOW

사전 재작업

 0014: 0x25 0x01 0x00 0x00000040   jgt 64   true:0016 false:0015
 0015: 0x06 0x00 0x00 0x7fff0000   ret ALLOW
 0016: 0x25 0x0f 0x00 0x00004000   jgt 16384 true:0032 false:0017
 0017: 0x25 0x0d 0x00 0x00002000   jgt 8192 true:0031 false:0018
 0018: 0x25 0x0b 0x00 0x00001000   jgt 4096 true:0030 false:0019
 0019: 0x25 0x09 0x00 0x00000800   jgt 2048 true:0029 false:0020
 0020: 0x25 0x07 0x00 0x00000400   jgt 1024 true:0028 false:0021
 0021: 0x25 0x05 0x00 0x00000200   jgt 512  true:0027 false:0022
 0022: 0x25 0x03 0x00 0x00000100   jgt 256  true:0026 false:0023
 0023: 0x25 0x01 0x00 0x00000080   jgt 128  true:0025 false:0024
 0024: 0x06 0x00 0x00 0x00050022   ret ERRNO(34)

drakenclimber 에 2018년 02월 27일

흥미로운. 따라서 PFC는 "올바른" 것처럼 보이지만 생성된 BPF는 ... 거꾸로입니다. 이상한. 특히 커밋이 BPF 생성 코드를 변경하지 않았다는 점을 고려하면.

우선 순위 값이 어떻게 든 엉망이되고 있는지 궁금합니다.

pcmoore 에 2018년 02월 27일

모호한 점 죄송합니다. PFC(재작업 변경 후)도 잘못된 순서입니다. 위에 게시한 PFC는 db.c 재작업 이전의 순서입니다.

HEAD에서 현재 생성한 PFC는 다음과 같습니다.

  # filter for syscall "read" (0) [priority: 65525]
  if ($syscall == 0)
    if ($a2.hi32 >= 0)
      if ($a2.lo32 > 128)
        action ERRNO(5);
      if ($a2.lo32 > 256)
        action ERRNO(6);
      if ($a2.lo32 > 512)
        action ERRNO(7);
      if ($a2.lo32 > 1024)
        action ERRNO(8);
      if ($a2.lo32 > 2048)
        action ERRNO(9);
      if ($a2.lo32 > 4096)
        action ERRNO(10);
      if ($a2.lo32 > 8192)
        action ERRNO(11);
      if ($a2.lo32 > 16384)
        action ERRNO(12);
      if ($a2.lo32 > 64) 
      else
        action ALLOW;
    else
      action ALLOW;
  # default action
  action ERRNO(34);

drakenclimber 에 2018년 02월 27일

알겠습니다. 조금 더 의미가 있습니다. 문제는 확실히 db 계층의 어딘가에 있습니다.

정확히 거꾸로 된 모습이 좀 웃기네요.

pcmoore 에 2018년 02월 27일

문제를 찾았습니다. 체인 인수 관리에서 lvl_nxt 및 lvl_prv의 동작은 대규모 db.c 재작업 후 교체되었습니다. _db_tree_add()에 대한 몇 가지 작은 변경으로 이전 libseccomp 동작과 일치했습니다.

다음은 수정 사항이 있는 분기입니다.
https://github.com/drakenclimber/libseccomp/tree/issues/112

변경 사항을 정리하고 테스트 한두 개를 추가한 다음 코드 적용 범위가 최대 수준인지 확인합니다.

drakenclimber 에 2018년 02월 28일

오늘 아침, 아마도 당신이 위의 글을 게시 하기 직전에 시간을 찾았고, 이것을 조금 살펴보기로 결정했습니다. 수정 사항은 약간 다르지만 거의 동일한 결론에 도달한 것 같습니다. 귀하와 마찬가지로 몇 가지 추가 작업/정리가 필요하지만 현재 수정 사항은 다음과 같습니다.

https://gist.github.com/pcmoore/f644341a85c6ad7131a26f68f99e3fc6

지금은 어떤 접근 방식이 더 마음에 드는지 잘 모르겠습니다. 이 부분에 대해 좀 더 생각해봐야겠죠?

pcmoore 에 2018년 02월 28일

흠... 거짓말은 하지 않겠습니다. 이 시점에서 두 가지 수정 사항에 매혹되지 않습니다.

내 것은 간단하지만 _db_tree_prune()을 완전히 무시했습니다. 요점에서 말했듯이 비슷한 문제가 있을 수 있습니다.

lt() 및 eq() 매크로를 활용하기 위해 gt() 매크로를 다시 작업하려는 당신의 아이디어가 마음에 들지만, 특히 lt()는 다루기 어려워지고 있습니다. lt()를 인라인 함수로 변환하지 않는 이유가 있습니까?
편집 - 방금 당신이 요점에서 비슷한 의견을 말한 것을 알았습니다.

이전 libseccomp 및 HEAD에 대해 gdb를 실행했고 lvl_prv 및 lvl_nxt의 동작이 변경되었지만 우리 외에는 아무도 볼 수 없는 내부 변수이기 때문에 별 문제가 되지 않을 수도 있습니다.

이 난리를 피운 것 같은데... 잘 모르겠습니다. 동의합니다, 나는 그것에 대해 생각해야합니다 ;)

drakenclimber 에 2018년 02월 28일

흠... 거짓말은 하지 않겠습니다. 이 시점에서 두 가지 수정 사항에 매혹되지 않습니다.

나는 아마도 이전 커밋에 의해 레벨 이 재정렬된 것처럼 보이지만 이것은 미묘한 버그 중 하나이지만 이와 같이 트리 수준을 재정렬하는 데 약간의 미묘한 버그가 있는 것이 걱정됩니다.

어느 쪽이든, 레벨에 대해 원하는 순서가 무엇인지 이해하고 싶습니다. "가장 큰"이 먼저입니까, "가장 큰"이 마지막입니까? 일단 이해하면 테스트/수정을 진행할 수 있습니다. 이전 2.x 릴리스와의 호환성 외에 다른 이유가 없다면 "가장 큰" 것이 답이라고 생각합니다. 하지만 현재로서는 확실히 말할 수 없습니다.

내 것은 간단하지만 _db_tree_prune()을 완전히 무시했습니다. 요점에서 말했듯이 비슷한 문제가 있을 수 있습니다.

둘 다 기본적으로 원칙적으로 동일한 작업을 수행합니다. 제 것은 몇 가지 추가 조건을 추가하고 db_chain_lt(x,y) 매크로를 정리하여 조금 더 나아갑니다.

lt() 및 eq() 매크로를 활용하기 위해 gt() 매크로를 다시 작업하려는 당신의 아이디어가 마음에 들지만, 특히 lt()는 다루기 어려워지고 있습니다. lt()를 인라인 함수로 변환하지 않는 이유가 있습니까?

대부분 역사적 이유. 그들은 훨씬 더 단순한 매크로로 삶을 시작했지만, 아마도 함수가 되어야 한다고 생각하는 지점까지 꽤 성장했습니다. 헤더 파일에 정말로 있어야 하는지 평가하는 것도 좋을 것이라고 생각합니다. src/db.c에서만 사용된다고 생각합니다.

이전 libseccomp 및 HEAD에 대해 gdb를 실행했고 lvl_prv 및 lvl_nxt의 동작이 변경되었지만 우리 외에는 아무도 볼 수 없는 내부 변수이기 때문에 별 문제가 되지 않을 수도 있습니다.

네, 내부 상태/트리입니다. 저는 그것에 대해 별로 걱정하지 않습니다. 중요한 것은 생성된 필터의 정확성입니다.

이 난리를 피운 것 같은데... 잘 모르겠습니다. 동의합니다, 나는 그것에 대해 생각해야합니다 ;)

헤. 하루나 이틀 정도 시간을 두고 다시 그룹화합시다. :) 지금은 릴리스된 버전에 영향을 주지 않고 마스터 브랜치에만 있으므로 문제를 바로잡을 시간이 있습니다.

pcmoore 에 2018년 02월 28일

현재 이것은 릴리스된 버전에 영향을 미치지 않으며 마스터 브랜치에만 있으므로 문제를 바로잡을 시간이 있습니다.

잘 들린다. 계획을 구상하는 동안 몇 가지 테스트를 해볼게

drakenclimber 에 2018년 02월 28일

👍1

현재 seccomp A2 처리를 평가하는 프로그램을 작성했습니다. 전체 프로그램은 다음에서 사용할 수 있습니다.

https://gist.github.com/drakenclimber/3c6b45ecd973ee495281ef225fa5e54a

간단히 말해서, 보다 큼 규칙은 "최종 생성" "최초 처리" 순서로 생성됩니다.

> 규칙이 오름차순으로 생성 되는 필터의 경우, 예를 들어
seccomp_rule_add(ctx, action1, syscall, 1, SCMP(SCMP_CMP_GT, 10)
seccomp_rule_add(ctx, action2, syscall, 1, SCMP(SCMP_CMP_GT, 20)
seccomp_rule_add(ctx, action3, syscall, 1, SCMP(SCMP_CMP_GT. 30)
그러면 필터가 일관된 방식으로 작동합니다. 예를 들어

if (A2 > 30)
    do action3
if (A2 > 20)
    do action2
if (A2 > 10)
    do action1

> 규칙이 내림차순 으로 생성 되는 필터의 경우, 예를 들어
seccomp_rule_add(ctx, action3, syscall, 1, SCMP(SCMP_CMP_GT, 30)
seccomp_rule_add(ctx, action2, syscall, 1, SCMP(SCMP_CMP_GT, 20)
seccomp_rule_add(ctx, action1, syscall, 1, SCMP(SCMP_CMP_GT. 10)
그러면 필터가 생성되지만 이상하게 작동합니다. 데드 코드가 생성됩니다. 마지막 두 if 문에 연결할 수 없습니다.

if (A2 > 10)
    do action1
if (A2 > 20)
    do action2
if (A2 > 30)
    do action1

여러 < A2 작업이 있는 필터는 현재 seccomp에서 허용되지 않습니다. <= 를 위의 > 필터와 동일하게 만드는 방법을 알아낼 수 없었기 때문에 이것은 이상해 보입니다.

tom<strong i="43">@OracleDesktop</strong> $ ./a2test 3
Failed to add rule
        action = 0x5000e op = 0x3 datum = 18000 rc = -17
Mode 3 (LE descending) test failed.  rc = -17

tom<strong i="46">@OracleDesktop</strong> $ ./a2test 4
Failed to add rule
        action = 0x50006 op = 0x3 datum = 250 rc = -17
Mode 4 (LE ascending) test failed.  rc = -17

src/db.c 에 깊숙이 묻혀 있는 else if 논리가 < 오류를 일으키는 것 같습니다. 예: . 변경/고칠 가치가 있는지 확실하지 않습니다.

현재 동작을 캡처할 수 있도록 이 코드 중 일부를 자동화된 테스트로 변환하려고 합니다.

drakenclimber 에 2018년 03월 01일

쓰여진 대로 여기 의 요지는 지난주에 추가한 자동화 테스트에 실패했습니다. 파고들어 그 이유를 알아내도록 노력하겠습니다.

 batch name: 43-sim-a2_order
 test mode:  c
 test type:  bpf-sim
Test 43-sim-a2_order%%001-00001 result:   SUCCESS
Test 43-sim-a2_order%%002-00001 result:   SUCCESS
Test 43-sim-a2_order%%003-00001 result:   SUCCESS
Test 43-sim-a2_order%%004-00001 result:   SUCCESS
Test 43-sim-a2_order%%005-00001 result:   SUCCESS
Test 43-sim-a2_order%%006-00001 result:   SUCCESS
Test 43-sim-a2_order%%007-00001 result:   SUCCESS
Test 43-sim-a2_order%%008-00001 result:   FAILURE bpf_sim resulted in ERRNO(5)
Test 43-sim-a2_order%%009-00001 result:   FAILURE bpf_sim resulted in ERRNO(5)
Test 43-sim-a2_order%%010-00001 result:   FAILURE bpf_sim resulted in ERRNO(5)
Test 43-sim-a2_order%%011-00001 result:   FAILURE bpf_sim resulted in ERRNO(5)
Test 43-sim-a2_order%%012-00001 result:   FAILURE bpf_sim resulted in ERRNO(5)
Test 43-sim-a2_order%%013-00001 result:   FAILURE bpf_sim resulted in ERRNO(5)
Test 43-sim-a2_order%%014-00001 result:   FAILURE bpf_sim resulted in ERRNO(5)
Test 43-sim-a2_order%%015-00001 result:   FAILURE bpf_sim resulted in ERRNO(5)
Test 43-sim-a2_order%%016-00001 result:   FAILURE bpf_sim resulted in ERRNO(5)
Test 43-sim-a2_order%%017-00001 result:   FAILURE bpf_sim resulted in ERRNO(5)
Test 43-sim-a2_order%%018-00001 result:   FAILURE bpf_sim resulted in ERRNO(5)
Test 43-sim-a2_order%%019-00001 result:   FAILURE bpf_sim resulted in ERRNO(5)
Test 43-sim-a2_order%%020-00001 result:   FAILURE bpf_sim resulted in ERRNO(5)

drakenclimber 에 2018년 03월 12일

내 나쁜 - 요점을 잘못 적용했습니다. 테스트가 통과하고 있습니다. 휴 :)

drakenclimber 에 2018년 03월 12일

하아! :)

나는 그것에 대해 테스트를 실행 했다고 생각 했지만 그 당시에는 많은 것을 가지고 놀고 있었기 때문에 내가 잘못 기억하고 있다고 생각했습니다. 계속 봐주셔서 감사합니다. 저는 여전히 SELinux와 감사로 인해 약간 혼란스럽습니다. 그러나 커널이 지금 -rc5에 있기 때문에 병합 전에 새 코드에 중단을 두는 즉시 진정될 것으로 예상합니다. 창문 ...

pcmoore 에 2018년 03월 12일

걱정 마. 그것은 확실히 더 높은 우선 순위입니다.

나는 다양한 비현실적인 테스트를 통해 당신의 요지를 실행했습니다. 나는 그것을 깨뜨리지 못했지만 지금까지 _db_tree_prune()의 일부만 연습하고 있습니다. 변경 사항이 더 편안해지기 시작했지만 조금 더 시간을 들이고 싶습니다.

drakenclimber 에 2018년 03월 13일

👍1

_db_tree_prune() 코드를 찔러보고 깨뜨릴 수 없었습니다. Test 08-sim-subtree_checks는 prune() 내에서 대부분의 코드 경로를 테스트하는 데 정말 좋습니다.

나는 당신의 요점에서 나온 변화가 좋다고 생각합니다.

drakenclimber 에 2018년 03월 15일

풀 리퀘스트 #115를 제출했습니다. 롤 준비가 된 것 같아요

drakenclimber 에 2018년 03월 23일

이제 해결해야 하므로 종료합니다(위의 기록 참조).

pcmoore 에 2019년 01월 15일

이 페이지가 도움이 되었나요?

0 / 5 - 0 등급

Libseccomp: 버그: src/db.c 재작업으로 인해 A2 처리가 깨짐

모든 18 댓글

관련 문제