/usr/local/<myapp>대부분의 경우 소스에서 프로그램을 설치할 때 새 사용자와 새 그룹을 생성하고 최근 생성된 사용자와 그룹에 소유권을 부여하는 것이 좋습니다 .
이 관행이 모범 사례로 간주되는 이유는 무엇입니까?
어떻게 개선되나요?
예: MySQL 데이터베이스 서버용 mysql 사용자/mysql 그룹.
답변1
각 애플리케이션에 대해 하나의 사용자 및 그룹을 생성하는 대신 각 서비스에 대해 하나의 사용자 및 그룹을 생성하는 것이 관행입니다. 즉, 로컬 사용자가 실행하는 프로그램은 루트가 아닌 사용자로 설치할 필요가 없습니다. 그것은악마, 백그라운드에서 실행되고 네트워크나 기타 통신 수단을 통해 이루어진 요청을 실행하는 프로그램인 경우 이러한 프로그램은 전용 사용자로 실행되어야 합니다.
데몬은 전용 사용자로 실행되므로 오작동하는 경우(공격자에 의해 유발될 수 있는 버그로 인해) 피해가 제한됩니다. 공격자가 로컬 루트를 찾지 않는 한 데몬의 데이터 파일만 영향을 받습니다. 취약성) 이런 일이 발생할 수 있습니다). 예를 들어, 데이터베이스 데몬은 데이터베이스( )의 데이터 파일이 속한 mysqld전용 사용자 및 그룹으로 실행됩니다 .mysql:mysql/var/lib/mysql/*mysql:mysql
데몬 실행 파일과 데몬에서 사용하지만 수정해서는 안 되는 기타 정적 데이터 및 구성 파일은 root:root대부분의 프로그램 및 구성 파일처럼 전용 사용자에게 속해서는 안 됩니다. 프로세스 에 비즈니스 덮어쓰기 또는 이 mysqld없으므로 이러한 파일은 이 사용자에게 속할 수 없거나 이 사용자 또는 그룹이 쓸 수 없습니다 . 일부 파일을 데몬과 관리자만 읽을 수 있어야 하는 경우 해당 파일은 모드 0640( )을 사용하여 루트 사용자와 개인 그룹이 소유해야 합니다./usr/sbin/mysqld/etc/mysql/my.cnfmysqlmysqlmysqlrw-r-----
사용자가 소유할 수 없는 특수 클래스의 실행 파일은 root:root사용자가 호출하지만 실행하려면 추가 권한이 필요한 프로그램입니다. 이러한 실행 파일은 다음과 같아야 합니다.설정값root 루트로 (적어도 부분적으로) 실행해야 하는 경우 실행 파일에는 모드 4755( rwsr-xr-x)가 있어야 합니다. 프로그램에 추가 권한이 필요하지만 루트가 아닌 경우 추가 권한이 사용자가 아닌 그룹을 통해 전달되도록 프로그램을 setgid해야 합니다. 실행 파일의 모드는 2755( rwxr-sr-x)입니다. 두 가지 이유가 있습니다:
- 실행 파일은 자체 수정이 허용되어서는 안 됩니다. 따라서 사용자가 취약점을 악용하는 경우 프로그램에서 사용하는 데이터 파일을 수정할 수는 있지만 주입할 수는 없습니다.트로이 목마프로그램을 실행하는 다른 사용자를 공격하려면 실행 파일에 접근하세요.
- 실행 파일의 데이터 파일은 이 그룹에 속합니다. setuid 프로그램은 개인 데이터 파일에 액세스하기 위해 실제 사용자(프로그램을 호출하는 사용자)와 유효 사용자(프로그램을 실행하는 사용자) 사이를 전환해야 합니다(이것이 추가 권한이 있는 이유입니다). setgid 프로그램은 그룹에서만 액세스할 수 있는 사용자별 데이터를 격리할 수도 있습니다(예: 루트 및 프로그램 그룹만 액세스할 수 있는 디렉터리에 사용자 소유 파일을 저장하여).
답변2
이는 일반적인 애플리케이션이 아니라 데몬입니다. 그 이유는 데몬이 루트가 아닌 비권한 사용자로 실행될 수 있기 때문에 보안상 취약하고 침해될 경우 가할 수 있는 피해는 사용자가 접근할 수 있는 영역으로 제한되기 때문이다.
답변3
이것이 좋은 방법으로 간주되는 이유는 시스템의 다른 사용자가 특정 응용 프로그램의 데이터 및 구성 파일을 덮어쓰는 것을 방지하기 위해서입니다.
예를 들어 mysql, mysqlmysql 데이터베이스 파일 저장소의 소유자가 되면 애플리케이션 API를 사용하지 않는 사람이 데이터베이스를 손상시키는 것을 방지할 수 있습니다. 또한 사용자는 mysql일반적으로 실제 쉘을 가지고 있지 않으므로 누구도 해당 사용자로 로그인할 수 없습니다.
답변4
이는 보안상의 이유입니다. 이는 누군가가 데몬 애플리케이션에 침입하여 입힐 수 있는 피해를 제한합니다. 사용자 애플리케이션은 일반적으로 root.
웹 서버, 메일 서버 및 데이터베이스가 모두 동일한 사용자로 실행되면 더 취약합니다. 시스템 액세스를 허용하는 버그나 구성 오류가 있는 경우 해당 액세스를 사용하여 세 가지 애플리케이션 모두에 액세스할 수 있습니다.
권장된 대로 모두 별도의 계정을 갖고 있는 경우 감염된 애플리케이션만 액세스할 수 있습니다. 상대방의 공개 구성 세부 정보를 읽을 수는 있지만 변경할 가능성은 없습니다.
많은 데몬은 사용자가 파일을 업로드 및 다운로드하거나 다른 데몬 구성에서 수행하지 않기를 원하는 작업을 수행하도록 허용합니다. 각 애플리케이션에 자체 사용자 ID와 그룹이 있는 경우 데몬 보안이 더 간단합니다.
데몬별 그룹이 있으면 데몬에게 파일 및 디렉터리에 대한 보안 읽기 전용 액세스 권한을 더 쉽게 안전하게 부여할 수 있습니다. 파일이나 디렉터리가 다른 사용자에게 속하지만 데몬 그룹에 속해 있는 경우 일반적으로 읽기 전용으로 액세스할 수 있습니다. 액세스 권한은 찾기와 같은 도구를 사용하여 쉽게 확인하고 수정할 수 있습니다.