Libseccomp: RFE: "최대 커널 버전" 지원

+1
이는 블랙리스트를 보안 문제 완화에 사용할 수 있도록 하는 데 도움이 됩니다.

@nmav 를 분명히 하기 위해 이 RFE는 시스템 호출이 Linux 커널에 처음 도입된 시기에 대한 정보를 내부 시스템 호출 테이블에 추가하기 위한 것이지, 현재 실행 중인 커널이 주어진 시스템 호출을 지원하는지 확인하기 위한 논리를 추가하기 위한 것이 아닙니다. 그러나 시스템 호출을 차단하려는 경우 libseccomp가 특정 아치/ABI 및 커널 버전에서 지원되는지 여부에 관계없이 libseccomp를 사용하여 차단할 수 있습니다.

이 RFE는 거의 5년이 지났고 @cgwalters 와의 단일 토론 외에는 그러한 기능에 대한 다른 관심을 보거나 들은 적이 없습니다. 다른 많은 미해결 문제가 있고 대부분은 우선 순위가 더 높기 때문에 언제 이 문제를 해결할 것인지, 또는 그러한 작업이 유용한 추가 기능이 될 것인지도 명확하지 않습니다.

@cgwalters 및 @drakenclimber 2020년 이 문제에 대해 어떻게 생각하십니까? WONTFIX로 이 작업을 종료하고 싶지만 해당 단계를 수행하기 전에 몇 가지 의견과 피드백을 받고 싶습니다.

@cgwalters 및 @drakenclimber 2020년 이 문제에 대해 어떻게 생각하십니까? WONTFIX로 이 작업을 종료하고 싶지만 해당 단계를 수행하기 전에 몇 가지 의견과 피드백을 받고 싶습니다.

솔직히 이건 정말 멋진 아이디어라고 생각합니다. 내 내부 고객 중 몇 명이 이 정확한 이유 때문에 허용 목록을 사용하고 있습니다. 그들이 거부 목록을 사용하고 새로운 시스템 호출이 커널에 추가된다면 그 시스템 호출은 또 다른 공격 수단이 될 것입니다.

조금만 더 열어두자. Oracle 내부에 물어보고 이 기능에 관심이 있는 고객이 있는지 확인하겠습니다. 그러나 @cgwalters (또는 그 문제에 대한 다른 사람)는 시간과 관심이 있다면 그것을 소유하는 것을 전적으로 환영합니다. :).

좋아요, 관심이 있는 한, 저는 이것을 열어두는 데 문제가 없습니다.

그래도 유용할 것 같아요!

문제 #286은 이 작업을 추진하는 데 도움이 되는 구체적인 문제인 것 같습니다... 거의 5년이 지났지만 ;)

이를 위한 첫 번째 단계는 syscall이 처음 도입된 시기를 나타내는 새 필드를 syscalls.csv 파일에 추가하는 것입니다. 현재 ~469개의 시스템 호출이 정의되어 있으므로(!) 좋은 작업이 될 것입니다. 그러나 "정의되지 않은" 값을 사용하여 기존 시스템 호출에 대해 이 작업을 상각할 수 있습니다. 이 값은 단순히 새벽에 생성되는 시스템 호출로 취급합니다. 물론 syscalls.csv 테이블에 대한 모든 새로운 추가 사항은 커널 버전과 함께 추가되어야 합니다.

더 빠른 생각:

• syscall.csv 형식

#syscall (v5.8.0-rc5 2020-07-14),kver_min,x86,x86_64,...
accept,<version>,PNR,43,...

... 여기서 <version> 는 "5_8", "UNDEF" 또는 이와 유사한 것일 수 있습니다.

• 버전 토큰

enum kernel_version {
    KV_UNDEF = 0,
    KV_1_0,
    KV_1_1,
    KV_1_3,
    KV_2_0,
    ...
    KV_5_8,
    _KV_MAX,
};

커널 버전을 추적하는 것이 올바른가요? 새로운 시스템 호출이 예를 들어 버전 번호가 낮은 안정적인 커널 분기로 백포트되지 않는다는 것이 보장됩니까?

Red Hat은 모든 종류의 것을 커널에 백포트할 것이므로 그렇지 않습니다.

RedHat이 시스템 호출을 이전 커널 버전으로 백포트하면 libseccomp 버전도 일치하도록 패치할 수 있습니다. 공정하기는 하지만 특정 사용 사례에서는 이것이 더 중요할 수 있지만 #286 수정에 대한 접근 방식으로는 상당히 실행 가능하다고 생각합니다. 다른 문제는 더 나은 접근 방식이 있는지 확신할 수 없다는 것입니다. syscall은 비연속적인 순서로 추가될 수 있습니다(예: close_range openat2 가 추가됨 -- 이 예제는 친절하지만 내 잘못).

RedHat이 시스템 호출을 이전 커널 버전으로 백포트하면 libseccomp 버전도 일치하도록 패치할 수 있습니다.

네, 맞습니다. 업스트림 libseccomp 프로젝트는 다양한 엔터프라이즈 Linux 배포판을 제어할 수 없으며 해당 배포판이 업스트림 프로젝트(Linux 커널 또는 libseccomp)에서 벗어나기로 결정하면 자체적으로 지원됩니다. 최선을 다해 도와드리겠지만 자체 지원 및 엔지니어링 직원이 있는 이러한 엔터프라이즈 배포를 위해 업스트림 프로젝트를 희생할 수는 없습니다.

참고로 syscalls(2) 맨페이지에는 커널에 다양한 시스템 호출이 도입된 시기에 관한 몇 가지 기록 정보가 있습니다.

• https://www.mankier.com/2/syscalls

각 syscall에 대한 버전 번호를 알아내기 위해 syscall spelunking을 수행할 수 있습니다. 유일한 질문은 특정 syscall이 다른 릴리스의 다른 아키텍처에 추가되었다고 확신하기 때문에 아키텍처별로 버전 번호를 가져야 하는지 여부입니다.

... 유일한 질문은 특정 시스템 호출이 다른 릴리스의 다른 아키텍처에 추가되었다고 확신하기 때문에 아키텍처별로 버전 번호를 지정해야 하는지 여부입니다.

그것들은 내가 볼 수 있는 한 가장 확실히 그랬고 지금도 그렇습니다. 약간 성가시게 될 것이고 CSV를 확실히 폭발시킬 것이지만, 각 아치/ABI에 대한 syscall의 첫 번째 모습을 추적하는 것이 아마도 올바른 일입니다.

이 @cyphar 에 대해 도움을 주시면 대단히 감사하겠습니다.