systemd 서비스 하드닝은 어디서 시작할까? ProtectSystem, ProtectHome, ReadWritePaths 기준 정리

systemd 서비스 하드닝은 어디서 시작할까? ProtectSystem, ProtectHome, ReadWritePaths 기준 정리

리눅스에서 systemd 서비스 보안을 강화할 때 가장 먼저 손대는 옵션으로 ProtectSystem=, ProtectHome=, ReadWritePaths=가 자주 언급된다. 2026년 5월 16일 기준 systemd 공식 문서를 보면 이 세 옵션은 서비스 프로세스가 파일 시스템 어디까지 읽고 쓸 수 있는지를 줄이는 핵심 수단이지만, 값별 의미와 예외 처리 방식은 분명히 다르다.

이 글은 systemd 공식 문서를 기준으로 각 옵션이 실제로 무엇을 막는지, 어떤 조합이 실무에서 무난한 출발점인지, 그리고 systemd-analyze security 결과를 어디까지 믿어야 하는지를 객관적인 사실만 정리한다.

ProtectSystem=은 무엇을 바꿀까?

systemd.exec 문서에 따르면 ProtectSystem=은 서비스가 보는 파일 시스템 일부를 읽기 전용으로 바꾸는 설정이다. 핵심은 값에 따라 보호 범위가 달라진다는 점이다.

• true: 보통 /usr, /boot, /efi를 읽기 전용으로 만든다.
• full: 여기에 /etc까지 읽기 전용으로 포함한다.
• strict: 전체 파일 시스템 계층을 읽기 전용으로 만들되, API 파일 시스템인 /dev, /proc, /sys는 예외로 둔다.

즉 서비스가 운영체제 파일이나 설정 파일을 바꿀 필요가 없다면 ProtectSystem=full 또는 strict가 강한 기본값이 될 수 있다. 반대로 패키지 설치, 시스템 업데이트, 설정 파일 수정이 본업인 서비스라면 이 값을 무작정 올리면 동작이 깨질 수 있다.

ProtectHome=은 무엇을 막을까?

ProtectHome=은 사용자 데이터 접근 범위를 줄이는 옵션이다. systemd 공식 문서는 이 설정이 /home, /root, /run/user에 적용된다고 설명한다.

• yes: 세 디렉터리를 비어 있는 것처럼 보이게 하거나 접근 불가로 만든다.
• read-only: 세 디렉터리를 읽기 전용으로 노출한다.
• tmpfs: 세 경로 위에 읽기 전용 tmpfs를 올려 실제 홈 디렉터리를 감춘다.

공식 문서는 특히 장시간 실행되는 서비스, 그중에서도 네트워크를 직접 받는 서비스라면 사용자 개인 데이터가 꼭 필요하지 않은 한 이 옵션을 켜는 편을 권장한다. 서비스가 홈 디렉터리 아래 설정 파일이나 키 파일을 실제로 읽어야 한다면, 적용 전에 경로 의존성을 먼저 확인해야 한다.

ReadWritePaths=는 왜 같이 보게 될까?

ProtectSystem=full이나 strict를 켜면 서비스 입장에서 너무 넓게 읽기 전용이 걸리는 경우가 많다. 이때 systemd는 ReadWritePaths=로 일부 경로만 다시 쓰기 가능하게 예외를 줄 수 있게 한다.

예를 들어 서비스가 애플리케이션 상태를 /var/lib/myapp에 기록해야 한다면, 운영체제 전체는 보호하되 그 경로만 쓰기 가능하게 되돌리는 식이다. 실무에서는 이 방식이 "기본은 차단, 필요한 경로만 예외"라는 패턴을 만들기 쉽다.

다만 공식 문서는 ReadWritePaths=가 모든 쓰기 제한을 풀어 주는 만능 예외가 아니라고 설명한다. 마운트 지점 자체와 그 뒤의 파일 시스템 슈퍼블록이 모두 쓰기 가능해야 실제 기록이 가능하므로, 바탕 파일 시스템이 읽기 전용이면 이 옵션만으로는 쓰기가 되지 않는다.

세 옵션을 어떻게 조합하면 무난할까?

상황	무난한 출발점	확인할 점
설정 파일은 읽기만 하고 상태 파일만 일부 기록	ProtectSystem=full + 필요한 경로만 ReadWritePaths=	/etc 수정이 실제로 없는지 확인
루트 파일 시스템 대부분을 건드릴 이유가 없는 데몬	ProtectSystem=strict + 필요한 상태 디렉터리만 예외	/var, /tmp 쓰기 필요 경로 점검
사용자 홈 데이터가 전혀 필요 없는 네트워크 서비스	ProtectHome=yes	홈 아래 인증서, 소켓, 설정 파일 참조 여부 확인
홈 디렉터리는 읽되 수정은 막고 싶은 배치 작업	ProtectHome=read-only	읽기만으로 충분한 작업인지 검토

핵심은 서비스를 먼저 "무엇을 써야 하는 프로세스인가"로 분해하는 것이다. 쓰기 경로가 명확하지 않은 상태에서 strict부터 넣으면 장애 원인 파악이 어려워질 수 있고, 반대로 아무 제약도 걸지 않으면 서비스가 불필요하게 넓은 파일 시스템 권한을 갖게 된다.

systemd-analyze security 점수는 어디까지 믿어야 할까?

systemd-analyze security는 서비스 단위의 보안 설정을 점검하는 데 유용한 도구다. 공식 문서는 이 명령이 여러 보안 관련 설정을 검사해 0.0부터 10.0까지의 "exposure level"을 계산한다고 설명한다. 값이 높을수록 systemd 차원에서 적용된 샌드박싱이 적다는 뜻이다.

하지만 같은 문서는 이 점수를 절대적인 보안 수준으로 오해하면 안 된다고 분명히 적는다. 이유는 두 가지다.

• 이 평가는 systemd 자체가 제공하는 서비스 단위 보안 기능만 본다.
• 서비스 코드 내부의 자체 방어, 다른 보안 계층, IPC를 통한 우회 가능성까지 모두 반영하지는 않는다.

따라서 이 명령은 "무엇을 더 잠글 수 있는지 찾는 체크리스트"로는 좋지만, 점수가 낮다는 이유만으로 안전하다고 결론 내리면 과장이다. 반대로 점수가 높다고 해서 곧바로 취약하다는 뜻도 아니다.

자주 헷갈리는 질문

Q. ProtectSystem=strict면 모든 경로가 완전히 읽기 전용일까?

공식 문서 기준으로는 그렇지 않다. /dev, /proc, /sys 같은 API 파일 시스템은 예외다. 또 서비스가 실제로 써야 하는 경로는 ReadWritePaths= 같은 별도 설정으로 다시 열 수 있다.

Q. 홈 디렉터리를 완전히 숨기고 특정 하위 경로만 다시 보여 줄 수 있을까?

가능하다. systemd 문서는 ProtectHome=tmpfs가 실제 홈 디렉터리를 숨기면서도 BindPaths= 또는 BindReadOnlyPaths=로 필요한 경로만 다시 노출하는 데 유용하다고 설명한다.

Q. 파일 시스템 권한을 줄였는데도 서비스가 우회할 수 있는 경우가 있을까?

그럴 수 있다. systemd-analyze 문서는 일부 보안 설정은 다른 권한이 남아 있으면 우회될 수 있고, IPC 정책 검토도 함께 필요하다고 설명한다. 즉 파일 시스템 제약만으로 보안 검토를 끝냈다고 보면 부족하다.

실무에서는 어디서 시작하면 될까?

대부분의 일반적인 데몬이라면 다음 순서가 무난하다.

• User=로 루트 실행이 꼭 필요한지 먼저 줄인다.
• ProtectHome=yes로 사용자 데이터 접근 필요성을 확인한다.
• ProtectSystem=full부터 적용해 보고, 더 강하게 묶을 수 있으면 strict를 검토한다.
• 실제로 실패한 쓰기 경로만 확인해 ReadWritePaths=로 좁게 예외를 준다.
• 마지막으로 systemd-analyze security로 빠진 기본 보호막이 없는지 점검한다.

이 접근은 "처음부터 모든 권한을 허용한 뒤 사고가 나면 줄이기"보다 안전하고, 반대로 "무조건 제일 강한 값부터 넣고 장애를 맞추기"보다 운영 부담이 작다.

정리

ProtectSystem=, ProtectHome=, ReadWritePaths=는 systemd 서비스 하드닝의 기본 축이다. 첫 번째는 운영체제와 설정 파일, 두 번째는 사용자 데이터, 세 번째는 필요한 최소 쓰기 예외를 다룬다.

2026년 5월 16일 기준 systemd 공식 문서를 기준으로 보면, 대부분의 장시간 실행 서비스는 기본적으로 파일 시스템 쓰기 범위를 줄이는 쪽이 맞다. 다만 실제 적용은 서비스가 어떤 경로를 읽고 쓰는지 확인한 뒤, 좁은 예외만 허용하는 방식으로 진행하는 편이 안전하다.

참고 자료

• systemd 공식 문서: systemd.exec
• systemd 공식 문서: systemd-analyze