내가 찾아낸 좋은 방법이 있는데, ProtectSystem=을 예제에선 사용하지 않았지만
TemporaryFileSystem=/:ro, BindReadOnly=/usr/bin/binary /lib /lib64 /usr/lib usr/lib64 와 같이 하면
원하는 바이너리와 읽기 원하는 경로만 포함시킬 수 있음
ProtectSystem=은 현재 이 동작과 호환되지 않음
더 자세한 내용은 여기 참고
이 방식이 에러 발생 시 이메일을 보내는 등 추가 동작이 필요한 서비스에는 문제가 될 수 있다고 생각함
사이트 인증서 이슈를 수정해주면 좋겠음
일부 브라우저에서는 인증서 오류 때문에 접근 자체가 불가능함
공유해줘서 고마움
systemd-analyze를 --user 플래그와 함께 사용하면 systemd 사용자 유닛의 보안을 확인할 수 있음("systemd-analyze --user security")
컨테이너를 Podman으로 이전하면서 systemd를 더 많이 쓰기 시작했고, 이 툴이 systemd 유닛/컨테이너 서비스의 보안 향상에 많은 도움이 될 것임
예전 init 스크립트는 모두 제각각이라서 이런 일관된 강화 작업이 불가능했음
물론 기존 init 스크립트로도 이런 강화 작업을 할 수 있긴 하지만, systemd는 커널의 좋은 기능들을 표준적이고 일관된 방법으로 쉽게 쓸 수 있게 도와줌
나는 리눅스에 비교적 늦게 입문해서 systemd 없는 시스템을 상상하기 힘들고, systemd 없는 시스템은 다루기 너무 불편했음
최근엔 "unshare"라는 툴을 발견해서 /nix 전체를 RW로 다시 마운트하는 등의 실험을 다른 프로세스에 영향 없이 할 수 있었음
systemd는 사용성이 다소 투박하긴 하지만 대안은 솔직히 내게는 Windows뿐이라고 생각함
왜 리눅스 배포판에서 이런 보안 스위치를 기본적으로 더 많이 활성화하지 않는지 궁금함
보수적으로 강화하는 데에 단점이 있나 생각함
많은 사용자에게는 세팅이 너무 많고 복잡할 수 있음
너무 공격적으로 세팅을 변경하면 의도치 않게 기존 설정이 깨질 수 있음
예를 들어 NetworkManager를 강화했다면 IPv4, IPv6 모두 연결되는지, dns=systemd-resolved와 dns=default 모드가 정상 동작하는지, ModemManager와 셀룰러 연동, openvpn이나 cisco anyconnect 플러그인, NetworkManager-dispatcher hook 등 다양한 부분을 일일이 검증해야 함
또 얼마나 많은 배포판 관리자가 자신이 관리하는 패키지의 스위치를 어느 정도까지 바꿔도 사용자 환경 0.01% 이상이 깨지지 않는지 확신할 수 있는지도 문제임
이러한 플래그를 배포판에서 관리하면 업스트림 릴리즈 때마다 호환성 이슈가 덤으로 따라오고, 반대로 업스트림이 설정하면 하위 호환성 때문에 더 신중하게만 쓸 수밖에 없음
이 질문은 "왜 배포판에서 기본적으로 MAC(SELinux 등)을 강하게 안 쓰는가?"와 비슷함
sshd 같은 것도 더 제한을 두는 게 좋긴 하지만
적용을 위한 초기 개발 비용
각종 사용자 환경마다 벌어지는 버그 리포트 처리 비용
배포판/업스트림 변화에 맞춘 지속 관리 비용
이런 것 때문에 메이저 배포판에서는 부담이 큼
SELinux, AppArmor도 마찬가지로 유지 관리자들이 투자 대비 효과를 낮게 보는 경우가 많음
핵심 시스템 서비스의 정상 동작을 각 파라미터마다 일일이 통합 테스트할 역량이나 리소스가 없는 것도 큰 이유임
관련 대화 https://news.ycombinator.com/item?id=29995566
systemd-analyze security 결과가 배포판별로 다름
desbma/shh는 strace로 수집한 내용을 SyscallFilter 등 단위별 룰로 자동 생성해주는데, SELinux의 audit2allow와 유사함
하지만 strace를 운영 환경에 설치하는 것은 논란이 가능함 https://github.com/desbma/shh
나도 잘 모르겠지만, 일부 세팅은 새로 추가된 것들이라 많은 사용자가 잘 모를 수도 있음
systemd 고수만 있는 게 아니고, 설정을 켜면 이전 버전 systemd에서 정상 동작하지 않을 위험도 있음
SELinux, AppArmor 등 다양한 기능이 있지만, 많은 배포판이나 개발자, 사용자들이 굳이 필요하다고 느끼지 않아서 자동 적용이 어려운 부분임
보안 강화를 위한 옵션이 너무 많아서, 일반적인 서비스별 하드닝 예시를 모아둔 저장소가 있으면 좋겠다고 생각함
사용자들이 공통적으로 적용하는 강화 스크립트를 활용하는 경우가 많은데, 의외로 권한을 더 넓게 설정해야 예외 상황이 발생하지 않음을 발견하게 됨
nixpkgs같이 업스트림 지원이 부족한 배포판에서 패키징할 때는
메인스트림 배포판에서 어떻게 패키징 및 하드닝하는지 참고하는 게 제일 유용함
그런 하드닝 방법들이 보통 충분히 테스트된 경우가 많으니, postgresql 등 강화 예시가 궁금하다면 Debian, Ubuntu, RHEL 패키지에서 출발하는 게 좋음
systemd가 제공하는 훌륭한 보안 기능 중 하나가 크리덴셜 관리임
이를 통해 환경 변수나 파일 시스템에 저장하는 것보다 더 안전하게 애플리케이션에 자격 증명을 전달할 수 있음
Vault 등이 없는 환경, 예를 들어 개인 프로젝트에선 항상 이 방법을 선호함
해당 기능과 연동되는 Go 패키지도 직접 만듦 systemd에서의 credentials credential-go 패키지
Hacker News 의견
자동화된 systemd 서비스 하드닝을 strace 프로파일링을 통해서 구현할 수 있다는 점이 흥미롭다고 생각함
https://github.com/desbma/shh
내가 찾아낸 좋은 방법이 있는데, ProtectSystem=을 예제에선 사용하지 않았지만
TemporaryFileSystem=/:ro, BindReadOnly=/usr/bin/binary /lib /lib64 /usr/lib usr/lib64 와 같이 하면
원하는 바이너리와 읽기 원하는 경로만 포함시킬 수 있음
ProtectSystem=은 현재 이 동작과 호환되지 않음
더 자세한 내용은 여기 참고
이 방식이 에러 발생 시 이메일을 보내는 등 추가 동작이 필요한 서비스에는 문제가 될 수 있다고 생각함
어제 올라온 systemd 하드닝 관련 글에 비해 훨씬 현실적이며 바로 적용 가능한 좋은 팁들이 많음
내가 어제 글 댓글에서 더 실제적인 예시를 들려주려고 노력했었는데, 오늘 글은 실질적인 내용을 멋지게 잘 정리해서 systemd로 격리와 보안을 빠르고 쉽게 강화할 수 있는 방법들을 알려줌
훌륭한 글이라고 생각함
어제 글도 참고로 남김
https://us.jlcarveth.dev/post/hardening-systemd.md
https://news.ycombinator.com/item?id=44928504
일부 브라우저에서는 인증서 오류 때문에 접근 자체가 불가능함
공유해줘서 고마움
systemd-analyze를 --user 플래그와 함께 사용하면 systemd 사용자 유닛의 보안을 확인할 수 있음("systemd-analyze --user security")
컨테이너를 Podman으로 이전하면서 systemd를 더 많이 쓰기 시작했고, 이 툴이 systemd 유닛/컨테이너 서비스의 보안 향상에 많은 도움이 될 것임
예전 init 스크립트는 모두 제각각이라서 이런 일관된 강화 작업이 불가능했음
나는 리눅스에 비교적 늦게 입문해서 systemd 없는 시스템을 상상하기 힘들고, systemd 없는 시스템은 다루기 너무 불편했음
최근엔 "unshare"라는 툴을 발견해서 /nix 전체를 RW로 다시 마운트하는 등의 실험을 다른 프로세스에 영향 없이 할 수 있었음
systemd는 사용성이 다소 투박하긴 하지만 대안은 솔직히 내게는 Windows뿐이라고 생각함
왜 리눅스 배포판에서 이런 보안 스위치를 기본적으로 더 많이 활성화하지 않는지 궁금함
보수적으로 강화하는 데에 단점이 있나 생각함
많은 사용자에게는 세팅이 너무 많고 복잡할 수 있음
너무 공격적으로 세팅을 변경하면 의도치 않게 기존 설정이 깨질 수 있음
예를 들어 NetworkManager를 강화했다면 IPv4, IPv6 모두 연결되는지, dns=systemd-resolved와 dns=default 모드가 정상 동작하는지, ModemManager와 셀룰러 연동, openvpn이나 cisco anyconnect 플러그인, NetworkManager-dispatcher hook 등 다양한 부분을 일일이 검증해야 함
또 얼마나 많은 배포판 관리자가 자신이 관리하는 패키지의 스위치를 어느 정도까지 바꿔도 사용자 환경 0.01% 이상이 깨지지 않는지 확신할 수 있는지도 문제임
이러한 플래그를 배포판에서 관리하면 업스트림 릴리즈 때마다 호환성 이슈가 덤으로 따라오고, 반대로 업스트림이 설정하면 하위 호환성 때문에 더 신중하게만 쓸 수밖에 없음
이 질문은 "왜 배포판에서 기본적으로 MAC(SELinux 등)을 강하게 안 쓰는가?"와 비슷함
sshd 같은 것도 더 제한을 두는 게 좋긴 하지만
이런 것 때문에 메이저 배포판에서는 부담이 큼
SELinux, AppArmor도 마찬가지로 유지 관리자들이 투자 대비 효과를 낮게 보는 경우가 많음
핵심 시스템 서비스의 정상 동작을 각 파라미터마다 일일이 통합 테스트할 역량이나 리소스가 없는 것도 큰 이유임
관련 대화
https://news.ycombinator.com/item?id=29995566
systemd-analyze security 결과가 배포판별로 다름
desbma/shh는 strace로 수집한 내용을 SyscallFilter 등 단위별 룰로 자동 생성해주는데, SELinux의 audit2allow와 유사함
하지만 strace를 운영 환경에 설치하는 것은 논란이 가능함
https://github.com/desbma/shh
나도 잘 모르겠지만, 일부 세팅은 새로 추가된 것들이라 많은 사용자가 잘 모를 수도 있음
systemd 고수만 있는 게 아니고, 설정을 켜면 이전 버전 systemd에서 정상 동작하지 않을 위험도 있음
SELinux, AppArmor 등 다양한 기능이 있지만, 많은 배포판이나 개발자, 사용자들이 굳이 필요하다고 느끼지 않아서 자동 적용이 어려운 부분임
보안 강화를 위한 옵션이 너무 많아서, 일반적인 서비스별 하드닝 예시를 모아둔 저장소가 있으면 좋겠다고 생각함
사용자들이 공통적으로 적용하는 강화 스크립트를 활용하는 경우가 많은데, 의외로 권한을 더 넓게 설정해야 예외 상황이 발생하지 않음을 발견하게 됨
메인스트림 배포판에서 어떻게 패키징 및 하드닝하는지 참고하는 게 제일 유용함
그런 하드닝 방법들이 보통 충분히 테스트된 경우가 많으니, postgresql 등 강화 예시가 궁금하다면 Debian, Ubuntu, RHEL 패키지에서 출발하는 게 좋음
systemd가 제공하는 훌륭한 보안 기능 중 하나가 크리덴셜 관리임
이를 통해 환경 변수나 파일 시스템에 저장하는 것보다 더 안전하게 애플리케이션에 자격 증명을 전달할 수 있음
Vault 등이 없는 환경, 예를 들어 개인 프로젝트에선 항상 이 방법을 선호함
해당 기능과 연동되는 Go 패키지도 직접 만듦
systemd에서의 credentials
credential-go 패키지
nodejs나 npm처럼 2줄짜리 코드도 패키지로 만드는 문화 같다고 생각함
실제로는
left-pad보다도 복잡하지 않음
Go 커뮤니티에서는 원래 의존성을 줄이고, 불필요한 추상화(함수 호출 등)를 피하는 게 미덕이었던 것으로 아는데
이런 간단한 동작은 다들 즉석에서 직접 작성하곤 했었음
이 credential 전달방식이 포크된 자식 프로세스까지 자격 증명 상속을 어떻게 막는지 궁금함
정말 유용한 글임
systemd 각 옵션 리스트와, "man을 참고하고 행운을 빈다" 같은 조언도 마음에 들음
systemd는 정말 훌륭해서 내 서버에 적극 배포하고 싶음
사소한 팁이지만 제목 표기에서 systemd의 올바른 표기는 systemd임
SystemD, system D, system d 등이 아닌 systemd가 맞음
이유는 system daemon이어서, 유닉스/리눅스 전통대로 소문자 d로 끝나는 이름을 쓴 것임
나는 보통 systemD로 부르는 걸 많이 봤는데 왜 그렇게 널리 쓰였는지 궁금함
systemd에서 syscall 이슈를 디버깅하는 팁이 정말 유용함