시작 후 /boot 제거

이론적으로는 둘 다 시작 후에 /boot/일반적으로 사용 되지 않습니다 /boot/efi. 두 가지는 BIOS(또는 유사)와 운영 체제 사이의 브리지를 형성합니다. 일반적으로 런타임에는 사용되지 않습니다.

부팅을 재구성하고 운영 체제가 부팅 순서를 업데이트/업그레이드할 수 있도록 설치됩니다. 즉, Debian에서는 apt/가 dpkg두 가지 모두에 대한 변경을 유발합니다.

/bootdpkg(또는 Redhat 파생 제품의 rpm) 이외의 다른 것이 파일 트리에 액세스하려고 할 가능성은 거의 없습니다 .

---

보안 관점에서나는 제거의 지혜에 도전하고 싶습니다. 루트를 제외한 모든 사용자는 읽기 전용이어야 합니다. 사용자에게 루트 액세스 권한이 있으면 설치할 수 있습니다. 반면에 보안 패치를 포함한 업데이트를 시스템에 적용하지 못하게 하면 연결하는 것보다 더 많은 취약점이 발생할 수 있습니다.

대신에,검역 요새 접근을 고려하셨나요?그리고 chroot기다려? Chroot는 로그인한 사용자가 하위 파일 트리와 pid 네임스페이스에만 액세스할 수 있도록 허용하는 반면, 사용자 네임스페이스는 특정 항목이 탈출하는 것을 방지합니다( chroot이것만으로는 충분하지 않습니다).

가장 쉬운 방법은 아마도 SSH 서버를 다음으로 교체하는 것입니다.도커(또는팟캐스트) 컨테이너 내부에서 openssh를 실행합니다. 이렇게 하면 호스트 시스템을 확인하지 않고도 SSH 클라이언트가 Docker 컨테이너 내에 유지됩니다. 컨테이너 내부의 파일 시스템은 매우 작을 수 있습니다.알파인 리눅스 컨테이너최소한의 명령줄 외에는 거의 아무것도 없습니다.

---

명확성을 위해 다음을 참고하세요.chroot는 프로세스를 분리하기에 충분하지 않습니다. 루트 액세스를 통해 프로세스는 chroot를 벗어날 수 있습니다. 그러나 다른 격리(예: pid 및 사용자 네임스페이스 및 삭제 기능)는 chroot 감옥 내부의 프로세스를 보호하는 데 큰 도움이 되어야 합니다. 따라서 docker를 권장합니다.

부작용:나는 그것을 스스로 눈치 채지 못했습니다. 물론 부득이하게 가져오는 부담과는 별개로확신하는새 커널을 설치하기 전에 먼저 설치하십시오. (그렇지 않은 경우 설치 시 루트의 /boot 디렉터리에 커널을 정상적으로 자동으로 설치하므로 주의하십시오...)
그러나 보안상의 이점은 논쟁의 여지가 있습니다.

올바른 진행 방법(초기화 시스템이 무엇이든) 거의 확실하게... 부팅 시 설치하지 않을 것입니다... 실제로는 전혀 필요하지 않기 때문입니다. ;-P
fstab에서 관련 항목을 확인하고 간단히 추가하세요.자동이 아님매개변수는 다음과 같습니다.LABEL=LTUX_BOOT /boot ext4 noauto,noatime 0 2

정말로 설치하고 싶다면(나중에 제거하기 위해) 다음 혜택을 누릴 수 있습니다.x-systemd.idletimeout설치 시스템의 특징. fstab의 /boot 항목에 이와 같은 내용을 추가하면 noauto,x-systemd.automount,x-systemd.idle-timeout=1s1초의 중간 시간 후에 파일 시스템이 자동으로 마운트 해제됩니다.

이제 생각해 보니 요새 VM 관련 관점에서 이 질문을 하신 것 같습니다. 이는 일반적으로 상태 비저장이며 거의 설치되지 않습니다.

해커가 입힐 수 있는 피해가 조금이라도 걱정된다면 /boot대부분의 피해는 가상 머신이 재부팅될 때 적용됩니다.

이에 대해 극단적인 관점을 갖고 싶다면 실제로 부팅 파티션을 완전히 파괴하고 부팅할 수 있습니다. 결국 그것은 가상 머신입니다. "재부팅"하거나 보안 업데이트를 적용하려면 새 가상 머신을 가동하고 이전 가상 머신을 제거하기만 하면 됩니다. 그러면 해커는 가상 머신의 시작 순서를 방해할 수 없습니다.

/boot다른 답변에서 언급했듯이 보안 업데이트를 적용하는 것 외에는 유지하고 설치할 실제 이유가 없습니다 ./boot/efi

/boot일반적으로 사용되는부트로더로, 일반적으로 GRUB에 의해 실행됩니다. 일반적인 사용법에서 /boot여기에는 설치된 커널 버전에 대한 커널 및 initramfs 파일뿐만 아니라 커널 업데이트 시 업데이트해야 할 수 있는 모든 부트로더 구성 파일이 포함됩니다. 부트로더에 추가 파일이 필요한 경우 해당 파일을 /boot.

부트로더는 운영 체제 커널이 나타나기 전에 실행되어야 하므로 "파일 시스템 마운트"와 같은 Linux 커널 개념에 의존할 수 없습니다. 대신, 부트 로더가 파일 시스템에 액세스할 때 펌웨어 지원(UEFI 시스템의 EFI 시스템 파티션) 또는 부트 로더의 자체 파일 시스템 드라이버를 사용해야 합니다. 이러한 부트로더 수준 드라이버는 일반적으로 단순화되어 읽기 액세스만 제공하고 고급 캐싱이나 성능 향상을 위한 다른 방법을 사용하지 않습니다. 왜냐하면 이러한 드라이버의 유일한 작업은 운영 체제 커널을 부팅하는 데 필요한 몇 개의 파일을 로드하는 것이기 때문입니다.

일반적으로 부트로더의 파일 시스템 드라이버 상태를 커널 제어로 전송할 수 없으며 커널에는 일반적으로 고성능 파일 시스템 드라이버가 있으므로 그렇게 하고 싶지도 않습니다.

부트로더가 커널(일반적으로 Linux의 initramfs 파일)을 RAM 메모리에 성공적으로 로드하고 커널을 시작하면 /boot파일 시스템 작업이 기본적으로 완료됩니다. Linux 커널이나 initramfs 파일에는 일반적으로 파일 시스템의 다른 항목이 필요하지 않습니다. 시스템 시작의 일부로 /boot마운트하는 유일한 이유는 커널 업데이트가 설치될 때 파일 시스템을 쉽게 사용할 수 있도록 하기 위한 것입니다./boot

따라서 /boot대부분의 경우 "부팅 후 제거"하는 가장 좋은 방법은 간단히 주석을 달거나 /etc/fstab설치 noauto옵션을 추가하는 것입니다.처음부터 시작할 때 설치하지 마십시오.

커널 업데이트 시 스크립트를 실행할 표준 디렉터리 세트가 있는 것 같습니다.

• /etc/kernel/preinst.d/새 커널을 설치하기 전에 실행해야 하는 스크립트
• /etc/kernel/postinst.d/새 커널을 설치한 후 실행해야 하는 스크립트
• 설치된 커널이 제거되기 전후에 각각 실행되어야 하는 스크립트를 /etc/kernel/prerm.d/나타냅니다 ./etc/kernel/postrm.d/

이러한 디렉터리의 스크립트는 파일 이름의 일반적인 US-ASCII 정렬 순서로 실행됩니다. 스크립트를 /boot와 로 /etc/kernel/preinst.d/000-mountboot마운트 하고 또 다른 스크립트를 로 /etc/kernel/prerm.d/000-mountboot다시 마운트 해제하는 경우 배포판의 표준 커널 패키지가 스크립트가 빌드된 적절한 단계에서 이를 호출한다고 가정하면 원하는 기능을 얻을 수 있습니다./etc/kernel/postinst.d/zzz-umountboot/etc/kernel/postrm.d/zzz-umountboot

UEFI ESP 파티션(일반적으로 로 마운트됨 /boot/efi)은 정확히 동일하지만시스템 펌웨어부트로더 대신. 펌웨어가 *.efiESP 파티션에서 부트로더 파일(및 부트로더에 존재할 수 있는 추가 파일)을 성공적으로 로드하면 ESP의 주요 작업이 완료되며 부트로더 업데이트 또는 다음 부팅 주기까지 더 이상 필요하지 않습니다.

그러나 UEFI ESP 파티션에는 보조 기능이 있을 수 있습니다. UEFI 펌웨어가 "펌웨어 업데이트 캡슐"(즉, 실행 중인 운영 체제 내에서 시스템 펌웨어 업데이트를 예약하는 표준화된 방법)을 지원하는 경우 펌웨어 업데이트 파일을 업데이트 프로세스를 설정하기 전에 ESP. Linux에는 이 메커니즘을 사용하기 위한 도구가 있습니다. 명령 fwupdate및 fwupdmgr/or 에 대한 매뉴얼 페이지를 참조하십시오 fwupdtool. 이 메커니즘이 결국 공급업체별 UEFI/BIOS 업데이트 도구를 대체하는 경우 ESP를 설치할 때 최소한 두 가지 조건을 충족해야 합니다.

• 부트로더 업데이트를 설치할 때
• UEFI 펌웨어 업데이트를 설치할 때

현재 커널 업데이트의 경우와 달리 이러한 이벤트에 사용자 정의 스크립트를 추가하기 위한 표준 후크가 없는 것 같습니다.