Hacker News 의견들

• 왜 landlock에 대한 언급이 없는지 궁금함

• C → WASM → C로 이어지는 하이브리드 컴파일 접근법이 있음
  이렇게 하면 OS 상호작용을 완전히 제어하고, WASM처럼 메모리 접근을 샌드박싱하면서도 기술적으로는 여전히 C 코드로 유지됨
  관련 자료는 RLBox에서 볼 수 있음

  • WASM 샌드박스는 프로그램의 정합성(soundness) 을 보장하지 않음
    메모리를 망가뜨릴 수는 있지만, 그 범위가 샌드박스 안으로 제한될 뿐임
    SECCOMP 같은 시스템은 모든 상호작용 정책을 세세히 정의해야 해서 관료적임
    반면 Fil-C는 언어와 런타임 자체가 프로그램의 올바른 동작을 보장하려는 접근을 취함
    Fil-C 바이너리는 일반 실행 파일이므로 SECCOMP 같은 샌드박스와 함께 사용할 수도 있음
    Linux가 prctl 인터페이스를 만드는 데 20년이 걸렸으니, WASI에서 비슷한 걸 보려면 10년은 기다려야 할 것 같음
  • RLBox는 샌드박싱 기술이지 메모리 안전성 기술은 아님
    샌드박스 내부에서도 이상한 실행 흐름을 만들 수 있음

• Fil-C의 저자는 기술적으로 흥미로운 발명을 잘 하지만, 구현 검증이 충분히 이루어졌는지는 걱정됨
  setuid 프로그램을 Fil-C로 컴파일할 수 있다고 했는데, ld.so를 수정한 부분이 위험할 수 있음
  setuid 앱은 환경 변수, 파일 디스크립터, rlimit, 시그널 등에서 매우 방어적으로 작성되어야 함
  이런 부분은 아직 미완성이라 실제 인프라에 쓰기엔 리스크가 있음
  그래도 코드베이스를 Fil-C로 테스트해보면 흥미로운 버그를 발견할 수도 있음

  • 실제로 Fil-C를 깨뜨릴 방법이 있는지 테스트 중임
  • 진짜 걱정된다면 직접 실험하고 결과를 공유해야 함
  • 런타임을 투명하게 만들어 감사(auditing) 가 가능하도록 하는 게 목표임
    ld.so 수정은 libc 레이아웃을 가르치는 정도의 작은 변경임
    setuid 관련 getenv 버그도 이미 secure_getenv로 수정했음
    지적한 내용엔 일부 진실과 일부 FUD가 섞여 있음
  • Fil-C 저자가 비판에 비협조적으로 대응하는 태도가 아쉬움
    Fil-C는 데이터 레이스 상황에서 포인터와 capability가 불일치할 수 있음
    이로 인해 메모리 안전성 위반이 발생할 수 있음
    저자는 이를 부정하지만, Java와 비교하는 건 부적절함
    기술은 훌륭하지만, 저자의 태도가 신뢰를 떨어뜨림

• WASM은 샌드박스이자 실행 환경으로, 사용 방식에 따라 메모리 안전성을 어느 정도 확보할 수 있음
  C를 WASM으로 컴파일하면 버그는 여전히 존재하지만, 그 영향 범위가 제한됨
  따라서 WASM을 샌드박싱 기술로 분류하는 건 맞지만, 실행 환경으로서 더 많은 가능성이 있음

  • WASM은 결국 샌드박싱 기술임
    모듈 B의 버그로 모듈 A의 데이터를 읽을 수 있음
    즉, WASM은 가벼운 프로세스 샌드박스 대체재에 불과함
  • “사용 방식에 따라 다르다”는 말 자체가 WASM이 완전히 안전하지 않다는 증거임
    C도 “사용 방식에 따라 안전하다”고 말할 수 있으니까
  • WASM은 C의 메모리 모델을 이해하지 못하므로, Fil-C처럼 보호 기능을 구현할 수 없음
    WASM은 런타임 탈출은 막지만, 내부 프로그램의 메모리 탈출은 막지 못함

• Fil-C와 Rust 비교를 요청함

  • 두 기술 모두 훌륭하지만 접근 방식이 다름
    Fil-C는 기존 C 프로그램을 호환성과 보안 중심으로 강화하는 데 적합함
    Rust는 새 코드베이스를 만들 때 정적 안전성과 성능을 확보하기 좋음
    Fil-C는 약간의 성능 손실이 있지만 기존 C 코드(ffmpeg, nginx, sudo 등)에 유용함
    Rust는 멀티스레딩과 타입 시스템이 강점임
  • Fil-C는 GC를 도입해 성능 저하가 있을 수 있음
    언어 설계 개선보다는 메모리 안전성 확보가 목적임
    경쟁군은 Rust보다는 D, Nim, Go에 가까움
  • Fil-C는 런타임 검사로 안전하지 않은 메모리 접근을 감지하면 프로그램을 중단시킴
    Rust는 컴파일 타임에 예방함
    두 접근은 직교적이며, Rust에도 Fil-C 스타일의 런타임 검사를 추가할 수 있음

• MicroVM이 점점 인기를 얻고 있음
  Fil-C가 이를 어떻게 활용할 수 있을지 궁금함

  • 약간의 포팅이 필요하겠지만, microVM의 일부 기능을 Fil-C의 메모리 안전한 유저랜드로 끌어올릴 수도 있음

• 이 프로젝트가 더 주목받길 바람
  sudo나 polkit 같은 핵심 도구가 메모리 안전하게 배포되면 좋겠음

• 메모리 안전 언어에서도 샌드박싱 활용이 더 많아졌으면 함
  Rust나 Go에서도 OS 수준의 샌드박스를 잘 안 쓰는 게 아쉬움

  • Seccomp는 이식성과 조합성이 떨어짐
    라이브러리 단위로 설정하기 어렵고, 커널 버전이나 libc 구현에 민감함
    파일 경로 같은 포인터 뒤의 입력은 필터링할 수 없어 한계가 있음
    그래서 보통 애플리케이션 단위로 직접 설정해야 함
  • Rust는 런타임이 거의 없어서 샌드박싱에 적합함
    반면 Go는 런타임이 커서 Fil-C처럼 안전하게 만들기 어려움

• Fil-C가 clang의 Address Sanitizer(ASan) 와 뭐가 다른지 궁금함
  단순히 런타임 패닉을 내는 수준이라면 “메모리 안전”이라 부르기 어렵지 않나 함

  • ASan은 버그를 잘 잡지만 완전한 메모리 안전성을 보장하지 않음
    일부 버그는 탐지하지 못함
    메모리 주변에 “red zone”을 두는 방식이라 운이 좋으면 탐지됨
  • 메모리 오류가 영향을 주기 전에 패닉으로 막힌다면, 그것도 메모리 안전으로 볼 수 있음
    메모리 안전은 “크래시하지 않는다”가 아니라 “잘못된 접근이 효과를 내지 못한다”는 의미임

• 완전한 VM을 샌드박스로 쓰면 안 되는 이유를 질문함

  • VM은 훌륭한 샌드박스지만, Chrome이나 OpenSSH 같은 앱은 권한 분리가 필요함
    하나의 프로세스는 권한 없이 입력을 파싱하고, 다른 프로세스는 높은 권한으로 동작함
    두 프로세스는 IPC로 통신함
    VM을 쓰면 보안은 높지만 오버헤드가 크고, GPU나 파일 접근 같은 기능이 복잡해짐
    그래서 일반적으로는 OS 수준의 샌드박싱이 더 깔끔함
  • VM은 대부분의 문제를 해결하지만, 데스크톱 그래픽 가속은 여전히 어려움
    GPU를 전용으로 할당해야 하고, Qubes도 X11 포워딩으로만 연결되어 가속이 없음