우분투가 관리자 암호를 요구할 때, 어떤 관리 사용자가 요청할 것인지 어떻게 결정합니까?

여러 사람이 사용할 Ubuntu (10.10) 시스템을 설정하고 있습니다. 소규모 사무실의 공유 시스템입니다. 주요 역할은 VirtualBox로 가상 머신을 호스팅하고 Samba로 파일을 제공하는 것입니다.

Samba의 경우 여러 사용자가 자신의 워크 스테이션에서 Samba 공유에 연결할 수 있도록 여러 사용자 계정을 설정해야합니다. 그러나 여러 사람이 사용할 가상 머신을 실행하기위한 전용 계정도 있습니다. 때때로 사람들은이 계정으로 상승 된 권한을 요구하는 작업을 시도합니다. 이로 인해 Gnome의 "관리자 비밀번호를 입력하십시오"대화 상자가 나타납니다. 그러나이 대화 상자는 암호를 요구합니다. 컴퓨터를 설정할 때 내 첫 번째 계정이 생성되었으므로 사용자에게 sudo 권한이 부여 된 유일한 사용자라고 가정합니다.

다른 사용자를 "첫 번째 리조트의 관리자"로 지정하고 싶습니다. 모든 사용자가 해당 계정의 비밀번호를 알아야하기 때문에 공유 계정 사용자가 될 수 없으므로 권한이 엄격하게 제한되기를 바랍니다. 다른 사람에게 내 비밀번호를 알려주는 효과적인 방법이 없기 때문에 내 계정이 될 수 없으며 사이트에 자주 입력 할 수 없습니다. 그러나 직접 할 수 있는 사람이 있으므로에 추가했습니다 /etc/sudoers. 어떻게하면 뭔가에 대한 권한을 상승해야하는 경우, 그것은을 요청해야 우분투를 말할 수있는 자신의 첫 번째 계정?

요약:

• 컴퓨터의 계정 : Alice, Bob, Carol, Dave, Eliza.
• Ubuntu가 설치되었을 때 Alice는 설치 과정에서 추가 된 첫 번째 사용자였습니다.
• "Dave"는 실제로 많은 사람들이 사용하는 계정이며 /etc/sudoers암호는 공개 지식이기 때문에 사용할 수 없습니다 .
• Bob은 Gnome에서 "관리"계정으로 설정되었으며 적절하게 입력되었습니다 /etc/sudoers. Bob은이 사무실의 보스입니다.
• Bob, Carol, Eliza 또는 Dave로 로그인 한 상태에서 높은 권한이 필요한 작업을 시도하면 시스템은 Bob의 자격 증명을 요청해야합니다.
• Alice로 로그인 한 상태에서 높은 권한이 필요한 작업을 시도하면 Alice는 자격 증명을 요청해야합니다 (Alice는 일종의 buckaroo sysadmin이며 su -확장 된 관리 작업을 수행 하는 습관이 있음 ).

원하는 상태를 유지하기 위해 어떤 구성 변경이 필요합니까?

우선 루트 가 아닌 사용자 에게는 두 가지 다른 메커니즘을 통해 권한있는 작업이 허용된다는 점을 지적하십시오 .

1. sudo

2. PolicyKit

첫 번째는 Synaptic Package Manager 와 같이 sudo명령이 래핑 된 메뉴 항목 또는 메뉴 항목 을 명시 적으로 실행할 때 사용됩니다 . 이 경우 필요한 비밀번호는 호출하는 사용자, 일반적으로 로그인 한 사용자의 비밀번호입니다.gksu

두 번째는 PolicyKit 인식 응용 프로그램이 권한있는 작업을 수행하려고 할 때 사용됩니다. 이러한 경우 응용 프로그램은 D-Bus를 통해 PolicyKit 로컬 기관에 작업을 실행할 수 있는지 묻습니다. 그런 다음 로컬 기관은 인증 에이전트를 통해 활성 사용자에게 ID를 증명하도록 요청합니다. 대화 상자 창은 다음과 같습니다 (불행히 이탈리아어로 된 텍스트 :)

당신은 작은 검은 색 삼각형 및 레이블에서 PolicyKit을 식별 할 수있는 정보 . 보시다시피, admin그룹 에 둘 이상의 사용자가있는 경우 인증에 사용할 사용자를 목록에서 선택할 수 있습니다.

이 모든 것을 감안할 때 sudo달성 가능한 구성과 관련하여 PolicyKit과 훨씬 더 복잡합니다. 비밀번호없이 실행할 수 있고 특정 사용자 또는 그룹 만 실행할 수있는 작업을 구성 할 수 있습니다.

귀하의 질문으로, 응용 프로그램에서 사용하는 메커니즘이 현재 로그인 한 사용자와 독립적으로 PolicyKit 인 경우 필요한 암호는 Bob 또는 Alice (올바로 이해하면 유일한 두 명의 관리자)의 암호입니다. 인증에 사용하려는 사용자 목록에서

응용 프로그램에서 사용하는 메커니즘 sudo이 GUI를 통해 수행되는 관리 작업의 경우 빈도가 줄어들 기 때문에 인증을 위해 사용자를 선택할 수있는 즉각적이고 간단한 수단이 없습니다.

분명히 sudo그런 경우에 나에게 가장 적합한 선택이 될 것입니다. 주요 포인트가 나타납니다 대부분의 (실제) 관리자가 실제로 사용하지 않는 것이 될 수 /etc/sudoers최대한 가능한 범위 ( User_Alias, Runas_Alias, Host_Alias, Cmnd_Alias).

대부분의 관리자는 기존 규칙 중 일부만 사용 하고 사용자를 추가하거나 더 나쁜 sudo것은 규칙이 일반적으로 우분투 설정에 존재하는 그룹에 사용자를 추가 하는 것입니다 ( %sudo...). 물론 이것은 각 사용자에게 무료 통치권과 수퍼 유저 계정의 모든 권한을 부여합니다.

당신의 의견을 감안할 때 :

그래서 나는 그들을 추가했다 /etc/sudoers

나는 또한 당신이 그것을 가능한 한 사용하지 않는 것으로 생각합니다.

당신과 같은 시나리오에서 나는 말 그대로 Bob이 제한해야 할 몇 가지 행동을 스크립팅합니다. 실제로 이것은 내가 관리하는 서버에서 수행 한 작업으로, 두 명의 특정 사용자가 호스트에서 특정 KVM 게스트를 재부팅 할 수 있도록합니다. 스크립트에는 인터프리터에 대한 절대 경로가있는 해시 뱅이 포함되어 있으며 (예 : #!/bin/dash대신 #!/usr/bin/env bash) 특권 작업 ( /bin/dash또는 /bin/sh)을 위해 다른 곳에서 사용되는 셸로 실행될 수 있습니다. 그것들은 단지 예방책입니다. 그 외에는 바이너리에 대한 모든 절대 경로를 하드 코딩하고 가능한 한 적은 수를 사용해야합니다. 예를 들어 bash/ 를 사용할 때 s보다 s를 dash선호합니다 (참조 ). 변수에 절대 경로를 할당하고 해당 변수를 기반으로 프로그램을 참조하여이를 유지 관리 할 수 ​​있습니다 (builtincommandman bash$VIRSH) 대신 /usr/bin/virsh. 가능하면 외부 스크립트 코드를 검사 한 후 호출하십시오. 특히 권한있는 컨텍스트에서 호출해야하는 경우. 필자의 경우 sshd공개 키 인증 을 통해서만 컴퓨터에 연결하기 때문에 사용자를 특정 루트 디렉토리 및 특정 SSH 하위 시스템으로 제한 합니다. 분명히 당신은 그것을 필요로하지 않습니다.

확인에 확인 chown root: <the-script>; chmod u=rw,a=,a+rx <the-script>사람 만 방지하기 위해 root그것으로 땜질에서 적절한합니다. 또한 조심 setuid하고 setgid비트 (대상 바이너리 활성화 find를 발견 할 수 있습니다). 스크립트가에있는 순간을 가정 해 봅시다 /usr/sbin/priv-action.

이제를 수정하십시오 /etc/sudoers. noexec명시 적으로 허용 된 것 이외의 이진을 방지하는 데 사용할 수 있습니다. 여기에 설명하는 것뿐만 아니라 실제로 추가 설정이 많이 있습니다. 반드시 상담하십시오 man sudoers.

이제 파일 의 사용자 이름 ( User_Alias)을 선호 sudoers하지만 Group_Alias( man sudoers) 또는 실제 시스템 그룹 (예 :)을 사용할 수도 %sudo있습니다.

# The list is comma-separated: bob,alice,...
User_Alias      LIMITED_ADMINS=bob

그런 다음 특정 스크립트를 실행할 수 있도록 명령 별칭을 추가하십시오.

# The list is comma-separated: /usr/sbin/priv-action,/bin/bash,...
Cmnd_Alias      PRIV_ACTION=/usr/sbin/priv-action

마지막으로 할 수 있도록 마법 라인을 제공 bob(또는 오히려 아래에 나열된 사용자 LIMITED_ADMINS) 스크립트를 통해 권한이있는 명령을 실행할 :

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

이전의 별칭 정의와 달리 해당 줄에는 설명이 필요합니다. 먼저 "사용자 사양"라인 평균의 부품을 살펴 보겠습니다. 여기 man sudoers도움이됩니다 :

사용자 사양의 기본 구조는 who where = (as_whom) what입니다.

예제 라인 (대부분의 우분투 설정에서 발견) :

root    ALL=(ALL) ALL

즉, 이름이 지정된 사용자 root( #0UID에 연결하는 데 사용 0)는 모든 호스트에서 모든 사용자 컨텍스트에서 실행될 수 있지만 비밀번호를 묻는 메시지가 표시됩니다 (기본 동작 가정). NOPASSWD마지막 태그 앞에 태그를 추가하면 비밀번호를 요청하지 않고도 동일한 작업을 수행 ALL할 수 root있습니다 (예 :) root ALL=(ALL) NOPASSWD:ALL. ALL다양한 별명 유형에 대한 고유 한 와일드 카드 별명입니다.

그러나 밥에게 다시 :

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

의 bob다른 나열된 구성원이 User_Alias LIMITED_ADMINS모든 호스트에서 (있는 ALL그대로) 사용자 root(그룹을 암시하지만 제공 할 수 있음 man sudoers)로 실행되도록 허용합니다 Cmnd_Alias PRIV_ACTION. 더 좋아집니다. 이 스크립트를 작성한다고 가정하면 다양한 매개 변수를 허용하여 여러 스크립트를 작성하지 않아도됩니다. /etc/sudoers기꺼이 쉘과 유사한 와일드 카드를 사용하여 전달할 수있는 인수의 가능성을 제한합니다.

나는 관리자가 사용 sudoers하는 방식을 사용하지 않는다는 것을 일관되게 발견했다. 그래서 나는 두 권의 책 "Linux Server Hacks"와 "Linux Server Hacks Volume Two"에서 각각의 "Hack"을 높이 평가했다. 이 훌륭한 시설의보다 정교한 사용.

보안 사례에 도움이되지 않는 모든 종류의 복잡한 해결책을 제시 할 수는 있지만 기본적인 어휘를 말하면 /etc/sudoers상당히 마술적인 업적을 수행 할 수 있습니다. :)

NB : /etc/sudoers.d/기울어 진 느낌이들 경우 아래에 새 파일을 만들 수도 있습니다 . 이것은 당신 /etc/sudoers의 라인을 포함 한다고 가정합니다 :

#includedir /etc/sudoers.d

유닉스 / 리눅스에는 수퍼 유저가 한 명 뿐이며 그 이름은 루트이지만 sudoers는 루트가 될 수있는 사용자입니다. 그룹을 사용해야합니다.

newgrp admins

그런 다음 사용자를 해당 그룹에 할당하십시오.

chgrp alice admins

그런 다음 그룹이 사용자 인 것처럼 관리자 그룹을 sudoers 구성 파일에 추가하십시오.

최신 정보

또는 관리자 그룹에 사용자를 추가 할 수 있습니다.

chgrp alice admin