/etc/init.d에 비 루트 소유 스크립트를 유지하는 것이 얼마나 안전합니까?

데몬으로 실행되고 /etc/init.d의 스크립트로 제어되는 응용 프로그램이 있습니다.
때로는 이러한 스크립트의 시작 / 제어 매개 변수를 변경 한 다음 데몬을 다시 시작해야합니다. 이 스크립트는 루트 사용자에게만 쓰기 권한이 있으므로이 스크립트를 편집 할 때 루트 권한이 필요합니다.

내가 생각한 것은 루트가 아닌 사용자를 해당 스크립트의 소유자로 만들어야한다는 것입니다. 이런 식으로 루트와 특수 사용자 만이이 스크립트를 편집 할 수 있습니다.

루트가 아닌 일부 소유 파일을 /etc/init.d 디렉토리에 보관할 수 있습니까?
아니면 시스템의 자연스러운 질서를 어지럽히는 것이 불합리합니까?

즉각적으로 떠오른 것은 소외 계층 사용자가 부팅 할 때 root로 작업을 실행할 수 있다는 것입니다 . 이는 크래커에게 바람직합니다.

• 다른 계정의 권한을 상승 시키려고합니다
• 서버를 사용하여 불량 서비스를 호스팅하고 싶습니다
• 서버가 재부팅되면 IRC / 스팸 봇을 시작하려고합니다
• 모선을 핑 (ping)하여 "다시 일어나요"라고 말하고 새로운 페이로드를 다운로드하고 싶을 수도 있습니다.
• 그들의 트랙을 정리하고 싶다
• ... 다른 악.

권한이없는 사용자가 다른 서비스 (http / etc)를 통해 손상을 입었을 때 가능합니다. 대부분의 공격자는 빠르게 실행 ls또는 find에서 모든 것을 /에 /etc그러한 가능성이 존재하는 경우 다양한 언어로 작성된 쉘은 그이 간단하게 사용할 수있다, 볼 만합니다.

주로 SSH를 통해 서버를 원격으로 관리하는 경우 부팅시 출력을 볼 수 없기 때문에 init 스크립트를 검사하지 않으면이 내용을 볼 수 없을 가능성이 매우 높습니다. 알려진 해시와 비교하여 해당 스크립트의 해시를 확인하여 변경된 것이 있는지 또는 버전 제어 소프트웨어 등을 확인합니다.)

당신은 분명히 그런 일이 일어나기를 원하지 않습니다. 루트는 실제로 그 init 스크립트를 소유해야합니다. 스크립트를 업데이트하기에 충분히 편리하도록 개발 사용자를 sudoers 목록에 추가 할 수 있지만 init.d의 모든 것에 대한 권한이없는 쓰기 액세스를 허용하지 않는 것이 좋습니다.

Tim Post가 만든 장점 외에도 여러 사람이 서버로 변경 사항을 푸시 할 수 있어야하는 설정에는 일종의 구성 관리 시스템 사용을 고려해야합니다.

예를 들어 꼭두각시, 요리사 또는 cfengine을 사용하는 경우 관련 사용자가 파일을 로컬에서 편집 한 다음 구성 관리를 통해 변경 사항을 푸시 할 수 있습니다. : 정확히 어떻게 물론 제대로 사용중인 시스템에 따라 다르지만의 설정은 설정 파일 (노트의 이전 버전으로 되돌릴 쉽게 그것을 만드는 소프트웨어 버전이 포함됩니다 것이 최대를 설정 하면 되지, 경우 !) 누군가 실수했습니다. 또한 별도의 테스트 시스템 등에 구성을보다 쉽게 ​​복사 할 수 있습니다.