나는 Landlock를 이용해 원치 않는 텔레메트리를 차단했음
C로 간단한 프로그램을 작성해 특정 포트 하나만 수신하도록 하고, 나머지 네트워크 연결은 모두 차단했음 sandboxer.c 예제를 참고했으며, 파일 접근 제한은 건드리지 않고 네트워크만 제어함 dmesg에서 차단된 연결이 표시되는데, 아마 audit 기능 덕분인 듯함
이 도구는 비특권 사용자 모드에서 작동하고, 컨테이너 안에서도 방화벽 설정 없이 잘 동작함
단, 악의적인 프로그램을 완전히 막는 용도로는 적합하지 않다고 생각함
소스 코드를 공유해줄 수 있는지 궁금함
Landlock이 완벽하진 않음 이슈 #28과 관련 메일 스레드를 보면, 샌드박스 규칙이 존재하지 않는 디렉터리를 참조할 수 없다는 문제가 있음
예를 들어 ~/.ssh가 아직 없을 때 규칙을 추가하면, 나중에 디렉터리가 생성되더라도 접근이 차단되지 않음
즉, 보안적으로 허점이 생길 수 있음
나는 itch.io 게임들을 bwrap으로 샌드박싱해보는 중임
최소 권한으로 실행하려니 꽤 까다로움
“Microlandia”는 실행이 안 되지만, 다른 Unity 게임들은 잘 돌아감
Landlock 기반 도구들이 더 많아져서 이런 작업이 쉬워지길 기대함
컨테이너 런타임에서 Landlock의 지원 상태가 궁금함
CRI들이 자체 인터페이스를 정의하려는 것 같지만, 커널 지원보다 항상 늦을 수밖에 없음
대부분의 인프라 담당자가 앱별로 샌드박스 정책을 유지보수하진 않을 것 같음
애플리케이션이 직접 Landlock을 사용하는 게 더 현실적이라고 봄
Landlock이 TCP 소켓만 제한하고, UDP나 raw 소켓은 막지 않는다는 점에 주의해야 함
그건 꽤 큰 보안 허점처럼 보임. 이유가 뭘까 궁금함
raw 소켓은 권한이 필요하고, iptables로 UID 기반 차단도 가능함
Landlock과는 다르지만 보완적으로 쓸 수 있음
그래도 꽤 큰 구멍처럼 느껴짐
이상한 제약이지만, 알아둬서 다행임
Landlock이 /sys 설정 대신 새로운 syscall을 추가한 게 흥미로움
아마 비특권 원칙 때문일 것임
seccomp로 Landlock syscall을 차단할 수 있는지도 궁금함
오래된 seccomp 정책이 Landlock 번호를 포함하지 않으면 SIGSYS가 날 수도 있지 않을까?
다른 LSM들도 점점 syscall 기반으로 전환 중임
파일시스템 기반 API는 footgun이 많고, dirfd 기반 접근 제어엔 syscall이 더 적합함
잘 작성된 seccomp 필터는 -ENOSYS를 반환해서 단순히 “지원 안 함”처럼 보이게 함
seccomp로 Landlock syscall을 제한할 수는 있지만, 실용성은 낮음
Landlock은 기존 권한을 더 제한할 뿐, 새 권한을 부여하지 않기 때문임
나는 이제 막 리눅스 보안에 관심을 가지기 시작했음
맥에서 벗어나 리눅스로 완전히 옮기려 준비 중인데, malware 방어에 Landlock이 어떤 도움이 되는지 궁금함
예를 들어 ~/.ssh 접근을 자동으로 거부하는 환경을 만들고 싶음
또, 이걸로 앱 런처를 만들 수 있는지도 알고 싶음
Landlock의 위협 모델은 악성코드 자체가 아니라, 정상 앱의 코드 실행 취약점임
앱이 스스로 필요 없는 권한을 제한해 공격자가 시스템을 장악하지 못하게 하는 용도임
~/.ssh 접근 차단 같은 건 AppArmor나 SELinux 같은 MAC 모델이 필요함
Landlock은 앱이 스스로 혹은 자식 프로세스를 제한할 때 유용함
예를 들어 npm이 post-install 스크립트를 빌드 디렉터리로만 제한하는 식임
OpenBSD의 pledge처럼 앱 개발자가 직접 사용하는 API임
다만 Linux는 생태계가 분산되어 있어 적용이 느릴 것임
그동안은 래퍼나 런처 형태로 쓰는 게 현실적임
패키지 매니저가 빌드 스크립트용 정책을 지정하거나, 사용자가 직접 래퍼를 써야 함
결국 프로그램이 자기 권한을 아는 경우에만 효과적임
macOS와 iOS의 sandboxing과 거의 동일한 개념임
앱이 실행 초기에 필요한 리소스만 화이트리스트로 지정하고 나머지는 차단함
악성 프로그램 방어용이 아니라, 자기 프로세스 보호용임
“공식 C 라이브러리가 없다”는 말이 웃기게 들림
이미 표준 라이브러리에 syscall이 있는데, 굳이 별도 라이브러리가 필요한가? man7 문서도 존재함
단순히 추상화 계층을 원한다는 뜻인지 궁금함
libc가 syscall 번호 관리나 부수 효과를 처리해주는 역할을 하므로,
glibc가 아직 Landlock 인터페이스를 제공하지 않는 건 의외임
아마 비리눅스 호환성 문제 때문일 것 같음
Hacker News 의견
C로 간단한 프로그램을 작성해 특정 포트 하나만 수신하도록 하고, 나머지 네트워크 연결은 모두 차단했음
sandboxer.c예제를 참고했으며, 파일 접근 제한은 건드리지 않고 네트워크만 제어함dmesg에서 차단된 연결이 표시되는데, 아마 audit 기능 덕분인 듯함이 도구는 비특권 사용자 모드에서 작동하고, 컨테이너 안에서도 방화벽 설정 없이 잘 동작함
단, 악의적인 프로그램을 완전히 막는 용도로는 적합하지 않다고 생각함
이슈 #28과 관련 메일 스레드를 보면, 샌드박스 규칙이 존재하지 않는 디렉터리를 참조할 수 없다는 문제가 있음
예를 들어
~/.ssh가 아직 없을 때 규칙을 추가하면, 나중에 디렉터리가 생성되더라도 접근이 차단되지 않음즉, 보안적으로 허점이 생길 수 있음
최소 권한으로 실행하려니 꽤 까다로움
“Microlandia”는 실행이 안 되지만, 다른 Unity 게임들은 잘 돌아감
Landlock 기반 도구들이 더 많아져서 이런 작업이 쉬워지길 기대함
CRI들이 자체 인터페이스를 정의하려는 것 같지만, 커널 지원보다 항상 늦을 수밖에 없음
대부분의 인프라 담당자가 앱별로 샌드박스 정책을 유지보수하진 않을 것 같음
애플리케이션이 직접 Landlock을 사용하는 게 더 현실적이라고 봄
런타임이 시스템 콜을 그냥 통과시키면 앱이 스스로 잠그는 걸 신뢰해야 하는 문제가 생긴다고 설명함
내부적으로 비슷한 API를 사용해 중요 프로세스 관리를 하고 있음
이런 연구가 규제 산업에도 큰 도움이 될 것임
커널 기능이라면 당연히 C API가 먼저일 텐데 왜 없는지 궁금함
libc는 그 위에 얹힌 계층일 뿐이고, 아직도 많은 syscall이 libc에 래퍼 없이 존재함
직접 헤더를 만들어
_syscallN매크로로 호출할 수도 있음landbox 같은 간단한 래퍼를 쓰면 되고,
Rust나 Go도 C FFI를 노출할 수 있음
커널의 sandboxer.c 예제를 참고하면 충분함
Landlock과는 다르지만 보완적으로 쓸 수 있음
/sys설정 대신 새로운 syscall을 추가한 게 흥미로움아마 비특권 원칙 때문일 것임
seccomp로 Landlock syscall을 차단할 수 있는지도 궁금함
오래된 seccomp 정책이 Landlock 번호를 포함하지 않으면 SIGSYS가 날 수도 있지 않을까?
파일시스템 기반 API는 footgun이 많고, dirfd 기반 접근 제어엔 syscall이 더 적합함
잘 작성된 seccomp 필터는 -ENOSYS를 반환해서 단순히 “지원 안 함”처럼 보이게 함
Landlock은 기존 권한을 더 제한할 뿐, 새 권한을 부여하지 않기 때문임
맥에서 벗어나 리눅스로 완전히 옮기려 준비 중인데, malware 방어에 Landlock이 어떤 도움이 되는지 궁금함
예를 들어
~/.ssh접근을 자동으로 거부하는 환경을 만들고 싶음또, 이걸로 앱 런처를 만들 수 있는지도 알고 싶음
앱이 스스로 필요 없는 권한을 제한해 공격자가 시스템을 장악하지 못하게 하는 용도임
~/.ssh접근 차단 같은 건 AppArmor나 SELinux 같은 MAC 모델이 필요함Landlock은 앱이 스스로 혹은 자식 프로세스를 제한할 때 유용함
예를 들어 npm이 post-install 스크립트를 빌드 디렉터리로만 제한하는 식임
OpenBSD의 pledge처럼 앱 개발자가 직접 사용하는 API임
다만 Linux는 생태계가 분산되어 있어 적용이 느릴 것임
그동안은 래퍼나 런처 형태로 쓰는 게 현실적임
결국 프로그램이 자기 권한을 아는 경우에만 효과적임
앱이 실행 초기에 필요한 리소스만 화이트리스트로 지정하고 나머지는 차단함
악성 프로그램 방어용이 아니라, 자기 프로세스 보호용임
이미 표준 라이브러리에 syscall이 있는데, 굳이 별도 라이브러리가 필요한가?
man7 문서도 존재함
단순히 추상화 계층을 원한다는 뜻인지 궁금함
glibc가 아직 Landlock 인터페이스를 제공하지 않는 건 의외임
아마 비리눅스 호환성 문제 때문일 것 같음