HardenedBSD August / September 2026 Status Report
HardenedBSD 2026년 8~9월 현황 보고
HardenedBSD가 분기별 릴리스 준비와 소스 트리·인프라 변경 사항을 보고합니다. 실험 단계인 bounds-safety 플래그를 사용자 공간에 연결했고, Radicle 취약점의 영향과 Tor 사용 권고, Radicle의 iroh 이전에 대한 우려도 설명합니다.
- 주제
AI 요약
HardenedBSD는 2026년 9월 28일 주간에 진행할 분기별 릴리스 엔지니어링을 앞두고 현황을 공유합니다. FreeBSD 메인 브랜치에서 보안과 관련 있어 보이는 커밋 몇 건을 HardenedBSD 15-stable에 반영할 계획이며, 다음 한두 주 안에 FreeBSD 보안 권고(Security Advisory)나 오류 공지(Errata Notice)가 나올 가능성이 있다고 봅니다.
소스 트리와 포트 변경
소스 트리에서는 bsdinstall에서 pkgbase 사용을 명시적으로 권하지 않도록 하고, /etc/os-release와 /var/run/os-release를 갱신했습니다. video(4)에 -ftrivial-var-auto-init=zero를 적용하고, login의 motd.template 링크와 hardening(4) 매뉴얼의 잘못된 참조를 고쳤습니다. AI·LLM 등이 생성한 결과물을 거부한다는 내용을 문서화했으며, ssh_config(5)에서는 기본 압축과 TCP keepalive를 비활성화했습니다.
또한 MK_BOUNDS_SAFETY 옵션을 추가해 -fbounds-safety를 world 빌드에 연결했습니다. 기본값은 비활성화입니다. Clang에서 이 기능은 아직 실험 단계라 실제 플래그 이름은 -Xclang -fexperimental-bounds-safety입니다. 현재 HardenedBSD 기본 시스템에서는 이 기능을 사용하지 않으며, 연결 작업은 사용자 공간에만 적용했습니다. 커널과 커널 모듈에는 Clang·LLVM 개발진이 기능을 정식 준비 완료로 판단한 뒤 같은 로직을 추가할 계획입니다.
이 플래그를 연결한 목적은 하위 프로젝트나 HardenedBSD 기반 시스템을 만드는 개발자가 자신의 코드에 실험 기능을 적용하기 쉽게 하는 데 있습니다. 작성자는 Capsicum처럼 코드베이스에 직접 통합해야 하는 접근 방식이 다소 강제적으로 느껴진다고 설명합니다. 다만 기반 기능을 마련하면 각 프로젝트가 적용 여부와 범위를 직접 결정할 수 있습니다. 포트에서는 math/libformfactor의 깨진 의존성을 수정했습니다.
인프라와 저장소 동기화
인프라 전반을 업데이트하고 rad.hardenedbsd.org와 ngx-01을 가상 머신에서 jail로 옮겼습니다. 두 시스템을 각각 jail로 전환한 뒤 처음 48시간가량 문제가 있었지만, 전환으로 상황이 크게 나아졌으며 아직 잠복한 문제는 남아 있다고 보고합니다. 다음에는 분기별 빌드가 끝나고 여러 미러에 완전히 동기화된 뒤 rsync 가상 머신을 jail로 옮길 예정입니다. 그다음에는 Tor Onion Service 엔드포인트를 현대화할 계획입니다.
자동 동기화 프로그램은 여러 원격 저장소에 푸시하도록 개선했습니다. GitHub 동기화도 다시 지원합니다. 현재 GitHub 미러 대상은 src와 ports 저장소이며, hbsdmon, libhijack, vm-bhyve-hbsd 같은 보조 프로젝트를 미러링할 계획은 없습니다. 자동 동기화는 6시간마다 실행되므로 Radicle에 직접 반영한 커밋이 GitHub에 나타나기까지 시간이 걸릴 수 있습니다.
장기적으로는 Radicle 노드의 제어 소켓과 직접 통신하는 Rust 오케스트레이션 데몬을 만들고 싶다고 밝혔습니다. 제어 소켓에서 메시지를 받아 필요한 작업을 실행하는, HardenedBSD 용도에 맞춘 간단한 CI/CD 도구를 구상합니다. 작성자는 Rust 코드를 읽는 일을 좋아하지만 아직 능숙하게 작성하지는 못한다며, 이 작업으로 Rust 실력을 키우고 Radicle 패치에도 더 잘 기여하고 싶다고 합니다. Radicle에서는 패치에 댓글을 달 수 있지만 댓글 목록을 확인하거나 답글을 다는 기능은 아직 없습니다. 작성자는 Rust에 익숙해진 뒤 이 문제를 해결하고 싶다고 덧붙였습니다.
Radicle 취약점과 대응
2026년 9월 23일 공개된 Radicle 취약점에는 두 가지 문제가 있습니다. 악성 노드가 다른 노드를 속여 비공개 저장소와 그 내용을 공개하게 만들 수 있습니다. 또 노드 간 통신은 전체가 암호화된 것으로 알려졌지만, 실제로는 초기 핸드셰이크만 암호화되고 장시간 이어지는 나머지 통신은 암호화되지 않았습니다.
HardenedBSD는 Radicle 네트워크에서 비공개 저장소를 사용하지 않아 첫 번째 문제의 영향을 받지 않는다고 설명합니다. 주 Radicle 시드 노드에는 Tor Onion Service 엔드포인트를 제공하며, 이를 이용하면 노드 통신이 암호화된 전송 경로를 거칩니다. 트래픽 분석까지 더 강하게 막아야 하는 사용자에게는 Tor를 통한 접속을 권합니다.
작성자는 Radicle이 여전히 HardenedBSD에 적합한 선택이라고 보지만, 향후 iroh로 이전하면 HardenedBSD와 사용자, 개발자에게도 영향이 생긴다고 말합니다. Radicle 팀과 HardenedBSD 팀, 더 넓은 커뮤니티가 함께 조율해야 할 가능성이 있어 이전 과정을 주의 깊게 지켜볼 계획입니다.
작성자는 이런 취약점이 발생한 점을 안타깝게 여기면서도, 과거 OpenSSL 코드 작업과 연동 경험을 들어 견고한 API를 만드는 일이 어렵다고 설명합니다. 동시에 개발 초기에 형식 검증을 했거나 tcpdump로 실제 네트워크 트래픽을 확인했다면 문제를 발견했을 것이라고 지적합니다. 문서를 믿고 직접 검증하지 않은 자신도 책임이 있다고 덧붙입니다. Radicle 팀에는 iroh 이전과 함께 실제 네트워크 트래픽을 검증하는 테스트를 마련하고, 다음 프로토콜을 더 신중하게 설계해 달라고 당부합니다. 비난을 보태기보다 팀을 격려하고, 직접 테스트하거나 Rust 개발로 돕자고 제안합니다.
원문: HardenedBSD / 번역·요약: Trawling