Libseccomp: 버그: 의사 시스템 호출에 대해 BPF를 생성하지 마십시오.

아래의 개선된 초안을 위해 제거된 재생기

분명히 하기 위해 디버깅 목적으로 PFC에서 의사 시스템 호출을 계속 내보내야 하지만 (쓸모 없는) BPF 필터 규칙을 내보내서는 안 됩니다.

내 보고서에서 문제를 만들어 주셔서 감사합니다.

분명히 하기 위해 디버깅 목적으로 PFC에서 의사 시스템 호출을 계속 내보내야 하지만 (쓸모 없는) BPF 필터 규칙을 내보내서는 안 됩니다.

다시 생각해 보십시오. PFC가 BPF를 반영하지 않는 경우에만 이것이 복잡하고 모호해질 것이라고 믿습니다.

다시 생각해 보십시오. PFC가 BPF를 반영하지 않는 경우에만 이것이 복잡하고 모호해질 것이라고 믿습니다.

PFC에서 시스템 호출이 누락된 경우 라이브러리가 (존재하지 않는) 시스템 호출에 대한 필터를 추가하는 데 실패하는 방법에 대한 많은 가짜 버그 보고서를 받게 됩니다.

의사 시스템 호출의 개념을 이해하는 사람들에게는 PFC 출력에서 ​​이를 제거하는 것은 간단한 연습입니다. 또한 PFC 출력은 BPF 출력의 정확한 복사본을 의도한 것이 아니라 단순히 디버깅 도구이자 생성된 필터 코드를 시각화하는 쉬운 방법이라는 점을 언급할 가치가 있습니다.

생성된 필터 코드를 시각화하는 쉬운 방법

그러나 생성된 코드에서 의사 시스템 호출이 없어야 하므로 _generated_ 필터 코드를 시각화하지 않습니다.

PFC에서 시스템 호출이 누락된 경우 라이브러리가 (존재하지 않는) 시스템 호출에 대한 필터를 추가하는 데 실패하는 방법에 대한 많은 가짜 버그 보고서를 받게 됩니다.

의사 시스템 호출 검사가 코드에 있어서는 안 된다는 것을 이해하는 것이 훨씬 쉽습니다('최적화'에서와 같이 '아치에 대한 그러한 시스템 호출이 없기 때문에'). 코드와 실제 코드의 시각화.

PFC 출력이 훨씬 읽기 쉽기 때문에 scmp_bpf_disasm 를 사용하는 것보다 bpf를 반영하는 PFC를 선호합니다.

@vt-alt에 대한 우려를 이해하고 있으며 향후 릴리스에서는 PFC로 이를 수행할 수 있지만 PFC 출력에서 ​​의사 시스템 호출을 제거하는 것은 실수라고 생각합니다.

@drakenclimber 이에 대한 강력한 의견이 있습니까?

x86_64용 수정된 재생기:

#include <stdlib.h>
#include <errno.h>

#include <seccomp.h>

#include "util.h"

int main(int argc, char *argv[])
{
        int rc;
        struct util_options opts;
        scmp_filter_ctx ctx = NULL;

        rc = util_getopt(argc, argv, &opts);
        if (rc < 0)
                goto out;

        ctx = seccomp_init(SCMP_ACT_KILL);
        if (ctx == NULL)
                return ENOMEM;

        rc = seccomp_arch_add(ctx, SCMP_ARCH_X32);
        if (rc < 0)
                goto out;

        rc = seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(access), 0);
        if (rc < 0)
                goto out;
        rc = seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(arm_fadvise64_64), 0);
        if (rc < 0)
                goto out;

        rc = util_filter_output(&opts, ctx);
        if (rc)
                goto out;

out:
        seccomp_release(ctx);
        return (rc < 0 ? -rc : rc);
}

업데이트됨: TSKIP 문제 수정

아직 완전히 테스트되지는 않았지만 수정될 수 있습니다. 균형 트리 최적화 알고리즘 @drakenclimber에 대해 이것이 합리적인지 확인할 수 있습니까?

diff --git a/src/arch-arm.c b/src/arch-arm.c
index 3465111..4dd4b63 100644
--- a/src/arch-arm.c
+++ b/src/arch-arm.c
@@ -54,7 +54,7 @@ int arm_syscall_resolve_name_munge(const char *name)
        if (sys == __NR_SCMP_ERROR)
                return sys;

-       return sys + __SCMP_NR_BASE;
+       return (sys | __SCMP_NR_BASE);
 }

 /**
@@ -68,7 +68,7 @@ int arm_syscall_resolve_name_munge(const char *name)
  */
 const char *arm_syscall_resolve_num_munge(int num)
 {
-       return arm_syscall_resolve_num(num - __SCMP_NR_BASE);
+       return arm_syscall_resolve_num(num & (~__SCMP_NR_BASE));
 }

 const struct arch_def arch_def_arm = {
diff --git a/src/arch-x32.c b/src/arch-x32.c
index 7b97fb3..3890968 100644
--- a/src/arch-x32.c
+++ b/src/arch-x32.c
@@ -43,7 +43,7 @@ int x32_syscall_resolve_name_munge(const char *name)
        if (sys == __NR_SCMP_ERROR)
                return sys;

-       return sys + X32_SYSCALL_BIT;
+       return (sys | X32_SYSCALL_BIT);
 }

 /**
@@ -57,7 +57,7 @@ int x32_syscall_resolve_name_munge(const char *name)
  */
 const char *x32_syscall_resolve_num_munge(int num)
 {
-       return x32_syscall_resolve_num(num - X32_SYSCALL_BIT);
+       return x32_syscall_resolve_num(num & (~X32_SYSCALL_BIT));
 }

 const struct arch_def arch_def_x32 = {
diff --git a/src/gen_bpf.c b/src/gen_bpf.c
index 55a7958..ae9c3f4 100644
--- a/src/gen_bpf.c
+++ b/src/gen_bpf.c
@@ -1555,6 +1555,10 @@ static int _gen_bpf_syscalls(struct bpf_state *state,
        for (s_iter = s_tail; s_iter != NULL; s_iter = s_iter->pri_prv) {
                if (!s_iter->valid)
                        continue;
+               /* skip pseudo-syscalls */
+               if ((s_iter->num & 0x80000000) &&
+                   (state->attr->api_tskip == 0 || s_iter->num != -1))
+                       continue;

                if (*bintree_levels > 0 &&
                    ((syscall_cnt + empty_cnt) % SYSCALLS_PER_NODE) == 0)

@vt-alt에 대한 우려를 이해하고 있으며 향후 릴리스에서는 PFC로 이를 수행할 수 있지만 PFC 출력에서 ​​의사 시스템 호출을 제거하는 것은 실수라고 생각합니다.

@drakenclimber 이에 대한 강력한 의견이 있습니까?

실제로는 아니지만 문제의 근본은 PFC 출력이 여러 가지 다양한 방식으로 사용되고 있다는 것입니다.

1. 위에서 언급했듯이 신규 사용자가 필터를 대략적으로 확인할 수 있는 쉬운 방법입니다.
2. 고급 사용자는 실제 BPF 필터와 거의 비슷할 것으로 기대하고 있습니다.

PFC 로직에 --no-pseudo-syscalls 플래그를 추가할 수 있을까요? 그러면 초심자 사용자에게는 동일하게 유지될 수 있지만 고급 사용자는 BPF에 대한 더 나은 근사값을 얻을 수 있습니다.

_업데이트됨: TSKIP_ 문제를 수정했습니다.

아직 완전히 테스트되지는 않았지만 수정될 수 있습니다. 균형 트리 최적화 알고리즘 @drakenclimber에 대해 이것이 합리적인지 확인할 수 있습니까?

할 것이다. 이 시나리오를 재현할 자동화된 테스트를 만들 수 있는지 확인하고 싶습니다.

_업데이트됨: TSKIP_ 문제를 수정했습니다.
아직 완전히 테스트되지는 않았지만 수정될 수 있습니다. 균형 트리 최적화 알고리즘 @drakenclimber에 대해 이것이 합리적인지 확인할 수 있습니까?

할 것이다. 이 시나리오를 재현할 자동화된 테스트를 만들 수 있는지 확인하고 싶습니다.

그리고 물론 위에 있는 재현자 테스트부터 시작하겠습니다. 감사 해요!

_업데이트됨: TSKIP_ 문제를 수정했습니다.

아직 완전히 테스트되지는 않았지만 수정될 수 있습니다. 균형 트리 최적화 알고리즘 @drakenclimber에 대해 이것이 합리적인지 확인할 수 있습니까?

이진 트리는 누산기를 수정해야 할 때 미리 계산하고 이것이 jge 논리를 삽입하는 방법을 알고 있습니다. 필터를 구축하는 동안 시스템 호출(위의 제안과 같이)을 제거하면 이 논리가 깨집니다.

내 변경 사항도 아직 완전히 테스트하지는 않았지만, 의사 시스템 호출을 제거하여 바이너리 트리를 작동시키려면 이와 같은 것이 필요할 것이라고 확신합니다. 이것을 사용하여 BPF 바이너리 트리를 생성했는데 합리적으로 보입니다. 생산 준비가 된 솔루션에 가까워지면 완전히 검증하겠습니다.

@@ -1532,11 +1532,31 @@ static int _gen_bpf_syscalls(struct bpf_state *state,
                _sys_sort(db_secondary->syscalls, &s_head, &s_tail, optimize);

        if (optimize == 2) {
+               /* since pseudo-syscalls are removed from the filter, we need
+                * to calculate the syscall count by hand
+                */
+               for (s_iter = s_tail; s_iter != NULL; s_iter = s_iter->pri_prv) {
+                       if (!s_iter->valid)
+                               continue;
+
+                       /* skip pseudo-syscalls */
+                       if ((s_iter->num & 0x80000000) &&
+                           (state->attr->api_tskip == 0 || s_iter->num != -1))
+                               continue;
+
+                       syscall_cnt++;
+               }
+
                rc = _gen_bpf_init_bintree(&bintree_hashes, &bintree_syscalls,
-                                          bintree_levels, db->syscall_cnt,
+                                          bintree_levels, syscall_cnt,
                                           &empty_cnt);
                if (rc < 0)
                        goto out;
+
+               /* reset the syscall_cnt variable because later in this
+                * function it's used as a counter
+                */
+               syscall_cnt = 0;
        }

db 구조체에 "유효한" 시스템 호출 수를 추적하는 변수가 있으면 더 똑똑하고 빠르게 만들 수 있습니다.

PFC 로직에 --no-pseudo-syscalls 플래그를 추가할 수 있을까요?

이 깃발은 어디로 갈까요? 나는 이것을 빌드 시간 옵션으로 원하지 않는다고 생각합니다. 필터 옵션을 추가할 수 있다고 생각하지만 저는 그것에 대해 별로 기대하지 않습니다. 나는 PFC의 의사 시스템 호출을 고수하지만 지금은 BPF에서 삭제하는 것에 투표할 것입니다.

내 변경 사항도 아직 완전히 테스트하지는 않았지만, 의사 시스템 호출을 제거하여 바이너리 트리를 작동시키려면 이와 같은 것이 필요할 것이라고 확신합니다. 이것을 사용하여 BPF 바이너리 트리를 생성했는데 합리적으로 보입니다. 생산 준비가 된 솔루션에 가까워지면 완전히 검증하겠습니다.

나는 이것이 트리 최적화를 깨뜨릴 것이라고 의심했습니다.

@drakenclimber 는 이것이 표준 최적화보다 트리 정렬에 훨씬 더 많은 영향을 미친

한 가지는 "arch-arm.c" 및 "arch-x32.c"의 변경 사항에 관계없이 더 합리적으로 수행해야 한다고 생각합니다.

PFC 로직에 --no-pseudo-syscalls 플래그를 추가할 수 있을까요?

이 깃발은 어디로 갈까요? 나는 이것을 빌드 시간 옵션으로 원하지 않는다고 생각합니다. 필터 옵션을 추가할 수 있다고 생각하지만 저는 그것에 대해 별로 기대하지 않습니다. 나는 PFC의 의사 시스템 호출을 고수하지만 지금은 BPF에서 삭제하는 것에 투표할 것입니다.

내가 생각하기 전에 입력했음을 인정합니다. ;)

예, 필터 옵션이 있어야 하고 잘못된 느낌입니다. 나는 동의한다; 위에서 설명한 대로 해보자. 계속해서 질문을 받으면 다시 방문할 수 있습니다.

내 변경 사항도 아직 완전히 테스트하지는 않았지만, 의사 시스템 호출을 제거하여 바이너리 트리를 작동시키려면 이와 같은 것이 필요할 것이라고 확신합니다. 이것을 사용하여 BPF 바이너리 트리를 생성했는데 합리적으로 보입니다. 생산 준비가 된 솔루션에 가까워지면 완전히 검증하겠습니다.

나는 이것이 트리 최적화를 깨뜨릴 것이라고 의심했습니다.

@drakenclimber 는 이것이 표준 최적화보다 트리 정렬에 훨씬 더 많은 영향을 미친

한 가지는 "arch-arm.c" 및 "arch-x32.c"의 변경 사항에 관계없이 더 합리적으로 수행해야 한다고 생각합니다.

확신하는. 나는 이것을 소유할 수 있다.

@drakenclimber "> 위에서 언급했듯이 신규 사용자가 필터를 대략적으로 확인할 수 있는 쉬운 방법입니다."

"Pseudo syscall"은 커널에 존재하지 않으며 잘 알려진 개념도 아닙니다. 이것은 순전히 libseccomp의 발명품이며 여기에서는 설명하지 않습니다. 음수라고만 명시했으며 아키텍처에 대해 주어진 시스템 호출이 존재하지 않을 때 나타납니다. 이것은 존재하지 않는 syscall과 어떻게 다릅니까? 어떤 목적으로 부정적인가요? 의사 시스템 호출 개념은 새로운 사용자에게 정말 혼란스럽습니다.

새로운(er) 사용자가 필터에서 확인된 존재하지 않는 시스템 호출을 보고 싶어한다는 것을 믿을 수 없습니다.

한 점 더 추가하겠습니다. 이 모든 것은 신중하고 상세한 이해만이 작동하는 보안 분야에 있습니다. 새로운 모호한 개념(의사 시스템 호출)과 표현의 차이(bpf 및 pfc)를 만듭니다. 이것은 정말로 새로운 사용자를 위한 것이며 더 혼란스럽습니까?

@vt-alt 걱정해주셔서 감사합니다. 하지만 v2.5.0 릴리스에서는 BPF 필터에서 의사 시스템 호출을 억제하고 PFC 필터에 계속 표시할 것입니다. 귀하가 이 결정에 동의하지 않을 수 있음을 이해하지만 이 결정을 존중해 주시기 바랍니다. 향후 릴리스에서는 의사 시스템 호출(다중 ABI 지원을 위한 것)의 이면에 있는 목적을 설명하고 맨페이지에 문서화하는 작업을 더 잘 수행할 것입니다. 이에 대한 문제를 만들었습니다(아래 링크). 해당 토론과 그에 따른 PR에 참여하는 것을 환영합니다. 미래에 PFC 필터에 대한 접근 방식을 수정할 수도 있지만 여기서 아무 것도 약속하고 싶지 않습니다.

• https://github.com/seccomp/libseccomp/issues/258

다시 한 번 BPF 문제를 알려주셔서 감사합니다. 다음 libseccomp 릴리스를 개선하는 데 도움이 되었습니다!

#264를 통해 마감합니다.