☰

콤보

tag-icon • tag-icon security apt freebsd integrity
콤보

Linux에 대한 배경 지식이 더 많기 때문에 FreeBSD를 살펴보고 대부분의 내용을 읽었습니다.FreeBSD 매뉴얼, 이는 훌륭하고 다음과 같은 정보도 제공합니다.보안(13장). 나열된 보안 관련 정보가 많지만 FreeBSD 소스 코드(포트 및 바이너리 패키징 시스템 포함)의 무결성이 어떻게 달성되는지 찾거나 이해할 수 없습니다.

앞서 언급했듯이 저는 일부 Linux 배포판, 특히 Debian에 다음과 같은 메커니즘이나 도구가 있는 방식에 익숙합니다.안전한 아파트원래 신뢰 루트는 공개 키("Debian 아카이브 자동 서명 키")를 통해 사용되지만 gpg는 일련의 해시 목록에 서명하여 궁극적으로 패키지의 모든 파일을 덮어씁니다.

FreeBSD를 안전하게 얻는 방법을 다룰 때 FreeBSD Subversion 저장소를 사용하는 옵션에 대해 언급합니다.

HTTPS는 다른 컴퓨터가 FreeBSD 미러를 가장하거나(일반적으로 "중간자" 공격이라고 함) 최종 사용자에게 부적절한 콘텐츠를 전달하려고 시도하는 것을 방지하기 위해 선호되는 프로토콜입니다. (원천:https://www.freebsd.org/doc/handbook/svn.html)

TLS/SSL의 유용성에 전적으로 동의하지만, 이것이 가능한 모든 보호 기능인지 궁금합니다. "보안 채널" HTTPS(일부 CA는 국가 행위자로 나타남) 외에도 가져오는 소스의 무결성을 확인하기 위해 FreeBSD 커뮤니티에서 사용하는 다른 서명된 WOT 대안이 있습니까?

그래서 비슷한 것이 있는지 묻고 있습니다.보안에 적합한데비안?

고쳐 쓰다:

저는 2012년 초에 몇 가지 다른 Linux 배포판인 Arch Linux에서 WOT(Web of Trust) 방법을 통해 패키지 서명을 확인했습니다.https://pierre-schmitz.com/trust-the-master-keys/), 젠투에도 비슷한 상황이 있는 것 같은데 언제 도입되었는지는 모르겠습니다. https://wiki.gentoo.org/wiki/Integrity/Concepts

어쨌든 Linux 배포판은 패키지/소스 코드 무결성 문제로 어려움을 겪고 있는 것 같습니다. 따라서 BSD의 보안 및 명령 세계에도 비슷한 것이 존재한다고 확신합니다.

답변1

콤보

서명된 패키지 저장소를 게시했으며 작동 방식은 다음과 같습니다.

/usr/local/etc/pkg/repos/JdeBP.conf그 일환으로 시스템 관리자는 xe 와 같은 구성 파일을 추가하여 /usr/local/etc/pkg/keys/JdeBP.pub그런 다음 Xe는 이를 /usr/local/etc/pkg/repos/JdeBP.conf.

이 명령을 사용하여 나만 가지고 있는 개인 키로 패키지 저장소에 서명합니다 pkg repo . /elsewhere/package_signing_key. 이렇게 하면 저장소와 패키지에 대한 서명 정보가 세 개의 파일 및 에 생성 됩니다 meta.txz. 각 아카이브에는 두 개의 파일이 있으며, 하나는 다른 하나의 파일입니다. 다이제스트 및 패키지 사이트 아카이브에는 각 패키지 아카이브 파일의 해시가 포함되어 있습니다. 메타아카이브에는 다른 두 이름과 pkg-ng 도구에 대한 일부 버전 정보만 포함되어 있습니다.digests.txzpackagesite.txzsignature

따라서 이는 Secure APT와 매우 유사합니다. 몇 가지 차이점이 있습니다.

  • Releasepkg-ng에는 하나의 레벨만 있으며 실제 패키지 아카이브의 체크섬을 제공하는 대신 Packages해시를 제공합니다. 실제 패키지 아카이브의 해시를 직접 제공합니다.Packagespackagesite.yaml
  • Release개별적으로 다운로드 가능한 파일 과 파일 로 분할되는 대신 Release.gpg파일(전체 저장소 포함)과 해당 파일은 단일 작업(및 단일 HTTP/FTP 트랜잭션)의 단위로 다운로드됩니다 Packages.Sourcespackagesite.yamlsignaturefetchpackagesite.txz

그러나 아이디어는 거의 동일합니다. 시스템 관리자는 해당 파일이 로컬에 저장된 신뢰할 수 있는 공개 키 복사본과 비교하여 확인할 수 있기 packagesite.yaml때문에 해당 파일이 내가 보낸 것이라고 믿습니다. signature시스템 관리자는 해당 redo-1.3.txz파일의 해시가 (현재) 신뢰할 수 있는 packagesite.yaml.

포트

항구는 매우 다른 물고기입니다. Debian의 Secure APT는 소스 코드 패키지를 더 많은 패키지로 취급합니다. FreeBSD/TrueOS 포트는 Debian 의미의 소스 패키지가 아니라 다른 사람이 릴리스한 소스 패키지를 얻고 빌드하는 자동화된 방법입니다. 포트는 기본적으로 fetch소스에 대한 몇 가지 지침이 포함된 makefile입니다 . 여기에는 무엇을 얻을 것인지에 대한 해시 목록이 있습니다.

포트 자체는 Subversion(FreeBSD의 경우) 또는 git(TrueOS 또는 FreeNAS의 경우)을 사용하여 FreeBSD 또는 TrueOS 저장소에서 가져옵니다. 따라서 Subversion이나 git을 신뢰한다는 표준 아이디어가 적용됩니다. 예를 들어, TrueOS에서 git을 사용하여 포트(자체)를 가져올 때 사용되는 "원격" URL은 iXsystems 보안 GitHub 저장소(TrueOS)의 HTTPS URL입니다.수동)이 그것이다.

따라서 xe가 신뢰하는 Subversion 또는 git fetch를 사용하여 xe가 포트를 가져왔기 때문에 시스템 관리자는 포트를 신뢰합니다. Xe는 (현재) 신뢰할 수 있는 포트에 나열된 해시와 일치하기 때문에 이 포트에서 얻은 소스 아카이브를 신뢰합니다.

노트

데비안의 Release.gz과 는 Packages.gz실제로 HTTP 전송을 압축하는 방법일 뿐입니다. 여러 운영 체제 버전을 처리하는 데 예상되는 방식의 차이 등 보안과 관련이 없는 몇 가지 다른 사항을 얼버무리고 있습니다.

데비안은 수년에 걸쳐 FreeBSD가 작동하는 방식으로 발전해 왔으며 더 이상 위키 페이지에서 말하는 방식으로 작동하지 않습니다. 오늘날 해시와 서명은 InReleaseFreeBSD 저장소와 마찬가지로 하나의 파일에 있습니다. 이렇게 하면 저장소 소유자가 다운로드 사이에 저장소를 업데이트하여 서명 불일치가 발생할 Release때 다운로드 후 발생할 수 있는 "찢어짐" 문제를 방지할 수 있습니다.Release.gpg

(데비안은 원래 이 작업을 수행한 이유는 수년에 걸쳐 이러한 것들을 단계적으로 개발했기 때문입니다. 각각은 이전 메커니즘을 변경하지 않고 구축했습니다. 먼저 시스템 Package, 그 다음에는 Release그 위에 메커니즘, 그 다음에는 Release.gpg그 메커니즘 위에 있는 메커니즘입니다.

또한: FreeBSD에는 이를 수행하는 다른 방법이 있습니다. 여기에는 "지문 인식" 및 digests파일 서명( digests.txz아카이브에 있음)이 포함됩니다.

또한 키 서명에 대한 보안 고려 사항을 얼버무렸습니다. 이는 이것이 보안 APT와 어떻게 유사하거나 다른지를 논의하는 답변과 실제로 관련이 없기 때문입니다. 개인 키 보안에 대한 요구 사항은 공개/개인 키를 사용한 서명의 전체 개념에 공통되며 저장소 구조와는 독립적입니다.

추가 읽기

관련 정보