DBUS Configuration File Description

freejack·2021년 8월 6일

원문은 https://dbus.freedesktop.org/doc/dbus-daemon.1.html의 일부이며, 이것은 구글번역+ 문서입니다.

메시지 버스 데몬에는 특정 응용 프로그램에 특화된 구성 파일이 있습니다. 예를 들어, 한 구성 파일은 메시지 버스를 시스템 전체 메시지 버스로 설정하고 다른 구성 파일은 사용자별 로그인 세션 버스로 설정할 수 있습니다.

구성 파일은 리소스 제한, 보안 매개변수 등도 설정합니다.

구성 파일은 상호 운용성 사양의 일부가 아니며 이전 버전과의 호환성이 보장되지 않습니다. 이 문서는 사양이 아니라 문서입니다.

표준 시스템 전체 및 세션별 메시지 버스 설정은 "/usr/local/share/dbus-1/system.conf" 및 "/usr/local/share/dbus-1/session.conf" 파일에서 구성됩니다. 이러한 파일은 일반적으로 /usr/local/etc/dbus-1의 system-local.conf 또는 session-local.conf를 <include>합니다. 기본 구성 파일을 수정하지 않도록 해당 파일에 로컬 재정의를 넣을 수 있습니다.

표준 시스템 버스는 일반적으로 /usr/local/share/dbus-1/system.d에서 추가 XML 파일을 읽습니다. 타사 패키지는 dbus 1.10(2015년 출시)부터 지원되는 해당 디렉터리에 올바른 작동에 필요한 기본 정책을 설치해야 합니다.

표준 시스템 버스는 일반적으로 /usr/local/etc/dbus-1/system.d에서 XML 파일도 읽습니다. 기본 정책을 무시하려는 경우 시스템 관리자가 이 파일을 사용해야 합니다.

타사 패키지는 역사적으로 /usr/local/etc/dbus-1/system.d에 XML 파일을 설치하지만 이 방법은 이제 더 이상 사용되지 않는 것으로 간주됩니다. 해당 디렉토리는 시스템 관리자용으로 예약된 것으로 처리되어야 합니다.

Note: 제가 작업하는 임베디드 단말의 경우 /usr/share/dbus-1/system.d와 /etc/dbus-1/system.d 에 *.conf파일이 위치합니다.

구성 파일은 XML 문서입니다. 다음과 같은 doctype 선언이 있어야 합니다.

<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">

구성 파일에 다음 요소가 있을 수 있습니다.

`<busconfig>`

루트 요소.

`<type>`

메시지 버스의 잘 알려진 유형입니다. 현재 알려진 값은 "system" 및 "session"입니다. 다른 값이 설정되면 D-Bus 사양에 추가되거나 네임스페이스가 지정되어야 합니다. 마지막 <type> 요소는 "wins"입니다(이전 값은 무시됨). 이 요소는 활성화된 클라이언트에 설정된 메시지 버스 특정 환경 변수만 제어합니다. 세션 버스를 시스템 버스와 구별하는 대부분의 정책은 구성 파일의 다른 요소에서 제어됩니다.

메시지 버스의 잘 알려진 유형이 "session"이면 DBUS_STARTER_BUS_TYPE 환경 변수는 "session"으로 설정되고 DBUS_SESSION_BUS_ADDRESS 환경 변수는 세션 버스의 주소로 설정됩니다. 마찬가지로 메시지 버스의 유형이 "system"이면 DBUS_STARTER_BUS_TYPE 환경 변수는 "system"으로 설정되고 DBUS_SYSTEM_BUS_ADDRESS 환경 변수는 시스템 버스의 주소로 설정됩니다 (일반적으로 어쨌든 잘 알려져 있음).

Example: <type>session</type>

`<include>`

이 시점에서 <include>filename.conf</include> 파일을 포함합니다. 파일 이름이 상대적인 경우 포함을 수행하는 구성 파일에 상대적으로 위치합니다.

<include>에는 선택적 속성 "ignore_missing=(yes|no)"가 있으며 제공되지 않으면 기본값은 "no"입니다. 이 속성은 포함된 파일이 없는 것이 치명적인 오류인지 여부를 제어합니다.

`<includedir>`

이 시점에서 <includedir>foo.d</includedir>의 모든 파일을 포함합니다. 디렉토리의 파일은 정의되지 않은 순서로 포함됩니다. ".conf"로 끝나는 파일만 포함됩니다.

이것은 특정 패키지에 의한 시스템 버스의 확장을 허용하기 위한 것입니다. 예를 들어, CUPS가 프린터 대기열 변경 알림을 보낼 수 있기를 원하는 경우 모든 앱이 이 메시지를 수신하고 프린터를 허용하는 파일을 /usr/local/share/dbus-1/system.d 에 설치할 수 있습니다. 데몬 사용자가 보낼 수 있습니다.

`<user>`

데몬이 실행되어야 하는 사용자 계정(사용자 이름 또는 UID). 데몬이 시작할때 이 UID로 변경할 수 없으면 종료됩니다. 이 요소가 없으면 데몬은 UID를 변경하거나 신경 쓰지 않습니다.

"wins" 파일의 마지막 <user> 항목, 나머지 항목은 무시됩니다.

버스 초기화가 완료된후 사용자가 변경됩니다. 따라서 소켓 등은 사용자를 변경하기 전에 생성되지만 사용자를 변경하기 전에는 클라이언트에서 데이터를 읽지 않습니다. 즉, 쓰기를 위해 루트 권한이 필요한 위치에 소켓 및 PID 파일을 생성할 수 있습니다.

`<fork>`

이 항목이 있다면, 버스 데몬은 실제 데몬이 됩니다(백그라운드로 분기 등). 이것은 일반적으로 --fork 명령줄 옵션대신 사용됩니다.

`<keep_umask>`

이 항목이 있다면, 버스 데몬은 포크할때 원래 umask를 유지합니다. 이것은 자식 프로세스의 동작에 영향을 미치지 않도록 하는데 유용할 수 있습니다.

`<syslog>`

이 항목이 있다면, 버스 데몬은 syslog에 기록합니다. --syslog, --syslog-only 및 --nosyslog 명령줄 옵션이 이 설정보다 우선합니다.

`<pidfile>`

이 항목이 있다면, 버스 데몬은 pid를 지정된 파일에 씁니다. --nopidfile 명령줄 옵션이 이 설정보다 우선합니다.

`<allow_anonymous>`

이 항목이 있다면, ANONYMOUS 메커니즘을 사용하여 인증된 연결에 연결 권한이 부여됩니다. 이 옵션은 ANONYMOUS 메커니즘이 아래에 설명된 <auth> 요소를 사용하여 활성화되지 않는한 실질적인 효과가 없습니다.

잘 알려진 시스템 버스 또는 잘 알려진 세션 버스의 구성에서 이 지시문을 사용하면 해당 버스를 안전하지 않게 만들 수 있으며 절대로 해서는 안됩니다. 마찬가지로 사용자 지정 버스 유형에서 이 지시문을 사용하면 익명 사용자가 권한을 손상시키거나 권한을 확대하는 것을 방지하도록 구성이 특별히 설계되지 않은한 일반적으로 사용자 지정 버스가 안전하지 않게 됩니다.

`<listen>`

버스가 수신 대기해야 하는 주소를 추가합니다. 주소는 전송 이름과 가능한 매개변수/옵션을 포함하는 표준 D-버스 형식입니다.

Windows 이외의 플랫폼에서 유닉스 기반 전송(unix, systemd, launchd)은 잘 알려진 시스템 버스와 잘 알려진 세션 버스 모두에 대한 기본값이며 강력히 권장됩니다.

Windows에서는 Unix 기반 전송을 사용할 수 없으므로 TCP 기반 전송을 사용해야 합니다. 원격 X11과 유사하게 tcp 및 nonce-tcp 전송에는 무결성 또는 기밀성 보호가 없으므로 일반적으로 로컬 루프백 인터페이스에서만 사용해야 합니다 (예: tcp:host=127.0.0.1 또는 nonce-tcp:host=localhost와 같은 주소 사용). 특히 잘 알려진 시스템 버스 또는 잘 알려진 세션 버스를 루프백이 아닌 TCP 주소에서 수신하도록 구성하는 것은 안전하지 않습니다.

개발자는 때때로 원격 TCP를 디버깅 도구로 사용하고 싶은 유혹을 받습니다. 그러나 이 기능이 완제품에서 활성화된 상태로 남아 있으면 결과가 위험할 정도로 불안정합니다. 개발자는 원격 TCP를 사용하는 대신 Secure Shell 또는 유사한 프로토콜을 통해 연결을 중계해야 합니다.

원격 TCP 연결은 암호화되지 않은 원격 X11, NFS 공유 홈 디렉토리 및 NIS(YP) 인증과 함께 신뢰할 수 있는 근거리 통신망 내의 서로 다른 시스템에 있는 동일한 사용자의 로그인 세션 간에 단일 세션 버스를 공유하는데 역사적으로 때때로 사용되었습니다. 이것은 동일한 LAN의 공격자에 대해 안전하지 않으며 강력하게 사용되지 않는 것으로 간주되어야 합니다. 보다 구체적으로, 암호화되지 않은 원격 X11 및 NFSv2/NFSv3과 동일한 방식과 동일한 이유로 안전하지 않습니다. D-Bus 유지 관리자는 해당 시스템 내에서만 액세스할 수 있는 (사용자, 시스템)쌍 별로 별도의 세션 버스를 사용할 것을 권장합니다.

Example: <listen>unix:path=/tmp/foo</listen>

Example: <listen>tcp:host=localhost,port=1234</listen>

여러 <listen> 요소가 있는 경우 버스는 여러 주소에서 수신 대기합니다. 버스는 <listen>에 주어진 마지막 주소를 사용하여 시작된 서비스 또는 기타 이해 당사자에게 주소를 먼저 전달합니다. 즉, 앱은 마지막 <listen> 주소에 먼저 연결을 시도합니다.

tcp 소켓은 IPv4 주소, IPv6 주소 또는 호스트 이름을 허용할 수 있습니다. 호스트 이름이 여러 주소로 확인되면 서버는 모든 주소에 바인딩됩니다. family=ipv4 또는 family=ipv6 옵션을 사용하여 주소 하위 집합에 강제로 바인딩할 수 있습니다.

Example: <listen>tcp:host=localhost,port=0,family=ipv4</listen>

특별한 경우는 운영 체제에서 선택한 사용 가능한 포트를 선택하는 것을 의미하는 0의 포트 번호를 사용하는 것입니다 (또는 포트 생략). 선택한 포트 번호는 --print-address 명령줄 매개변수로 얻을 수 있으며 DBUS_SESSION_BUS_ADDRESS가 설정된 경우와 같이 서버가 자체 주소를 보고하는 다른 경우에 표시됩니다.

Example: <listen>tcp:host=localhost,port=0</listen>

tcp/nonce-tcp 주소는 또한 bind=hostname 옵션을 허용하며, 수신 가능한 주소에서 서버가 수신할 인터페이스를 구성하는 데 사용됩니다. 호스트 이름은 로컬 시스템 인터페이스중 하나의 IP 주소입니다 (가장 일반적으로 127.0.0.1 ), 해당 IP 주소중 하나로 확인되는 DNS 이름, 모든 IPv4 인터페이스에서 동시에 수신 대기하려면 '0.0.0.0', 모든 IPv4 및 IPv6 인터페이스에서 동시에 수신 대기하려면 '::' (OS에서 지원하는 경우). 지정하지 않으면 기본값은 "host"와 동일한 값입니다.

Example: <listen>tcp:host=localhost,bind=0.0.0.0,port=0</listen>

`<auth>`

허용된 권한 부여 메커니즘을 나열합니다. 이 요소가 존재하지 않으면 알려진 모든 메커니즘이 허용됩니다. 여러 <auth> 요소가 있는 경우 나열된 모든 메커니즘이 허용됩니다. 메커니즘이 나열되는 순서는 의미가 없습니다.

Windows가 아닌 운영 체제에서는 EXTERNAL 인증 메커니즘만 허용하는 것이 좋습니다. 이것은 잘 알려진 시스템 버스와 잘 알려진 세션 버스에 대한 기본값입니다.

Example: <auth>EXTERNAL</auth>

Example: <auth>DBUS_COOKIE_SHA1</auth>

`<servicedir>`

dbus-daemon에게 잘 알려진 특정 버스 이름을 제공하기 위해 프로그램을 시작하는 방법을 알려주는 .service 파일을 검색하기 위한 디렉토리를 추가합니다. .service 파일의 내용에 대한 자세한 내용은 D-Bus 사양을 참조하십시오.

특정 서비스가 둘 이상의 <servicedir>에서 발견되면 구성 파일에 나열된 첫 번째 디렉토리가 우선합니다. 동일한 잘 알려진 버스 이름을 제공하는 두 개의 서비스 파일이 동일한 디렉토리에서 발견되면 어느 것이 선택될지는 임의적입니다 (이는 서비스 파일중 적어도 하나에 권장되는 이름이 없는 경우에만 발생할 수 있습니다. 잘 알려진 버스 이름 뒤에 ".service"가 붙음).

`<standard_session_servicedirs/>`

<standard_session_servicedirs/>는 표준 세션 서비스 디렉토리 세트를 요청합니다. 그 효과는 여기에 주어진 순서대로 각 데이터 디렉토리에 대해 일련의 <servicedir/> 요소를 지정하는 것과 유사합니다. 현재 디렉토리 모니터링을 비활성화하거나 <servicedir/>에 대해 엄격한 서비스 파일 이름을 지정하는 방법이 없기 때문에 정확히 동일하지 않습니다.

<servicedir/> 요소와 마찬가지로 특정 서비스가 둘 이상의 서비스 디렉토리에서 발견되면 첫 번째 디렉토리가 우선합니다. 동일한 잘 알려진 버스 이름을 제공하는 두 개의 서비스 파일이 동일한 디렉토리에서 발견되면 어느 것이 선택될지는 임의적입니다(이는 서비스 파일 중 적어도 하나에 권장되는 이름이 없는 경우에만 발생할 수 있습니다. 잘 알려진 버스 이름 뒤에 ".service"가 붙음).

Unix에서 표준 세션 서비스 디렉토리는 다음과 같습니다:

$XDG_RUNTIME_DIR/dbus-1/services, XDG_RUNTIME_DIR이 설정된 경우(XDG_RUNTIME_DIR에 대한 자세한 내용은 XDG 기본 디렉토리 사양 참조): 이 위치는 시스템 생성기에 의해 런타임에 생성된 임시 서비스에 적합합니다(systemd.generator(7) 참조), 세션 관리자 또는 기타 세션 인프라. dbus-daemon의 참조 구현에서 제공하는 확장이며 D-Bus 사양에서 표준화되어 있지 않습니다.

다른 표준 세션 서비스 디렉토리와 달리 이 디렉토리는 서비스 파일에 대해 엄격한 이름 지정을 적용합니다. 파일 이름은 정확히 잘 알려진 서비스 버스 이름이어야 하며 그 뒤에 ".service"가 와야 합니다.

또한 다른 표준 세션 서비스 디렉토리와 달리 이 디렉토리는 inotify(7) 또는 유사한 API로 모니터링되지 않습니다. dbus-daemon이 실행되는 동안 이 디렉토리에 서비스 파일을 생성하는 프로그램은 변경 후 dbus-daemon의 ReloadConfig() 메서드를 호출해야 합니다.
$XDG_DATA_HOME/dbus-1/services, 여기서 XDG_DATA_HOME의 기본값은 ~/.local/share (XDG 기본 디렉토리 사양 참조): 이 위치는 D-Bus 사양에 의해 지정되며 사용자별 로컬 설치 소프트웨어에 적합합니다.
XDG_DATA_DIRS의 각 디렉토리에 대한 directory/dbus-1/services. 여기서 XDG_DATA_DIRS는 기본적으로 /usr/local/share:/usr/share로 설정됩니다 (XDG 기본 디렉토리 사양 참조). 이러한 위치는 D-Bus 사양에 의해 지정됩니다. 기본값은 시스템 관리자가 로컬로 설치한 소프트웨어 (/usr/local/share) 또는 운영 체제 패키지에서 설치한 소프트웨어 (/usr/share) 에 적합합니다. XDG_DATA_DIRS 환경 변수를 설정하는 사용자별 또는 시스템 전체 구성은 이 검색 경로를 확장하여 다른 위치의 설치를 포함할 수 있습니다. 예를 들어 flatpak(1)이 사용되는 경우 ~/.local/share/flatpak/exports/share/ 및 /var/lib/flatpak/exports/share/입니다.
dbus가 컴파일될때 지정된 ${datadir}에 대한 ${datadir}/dbus-1/services, 일반적으로 /usr/share: 이 위치는 참조 dbus-daemon 구현에서 제공하는 확장이며 소프트웨어 스택에 적합합니다. dbus-daemon과 함께 설치됩니다.

"XDG 기본 디렉토리 사양"이 이동하지 않은 경우 http://freedesktop.org/wiki/Standards/basedir-spec에서 찾을 수 있으며, 그렇지 않으면 즐겨 찾는 검색 엔진을 사용해 보십시오.

Windows에서 표준 세션 서비스 디렉토리는 다음과 같습니다:
%CommonProgramFiles%가 설정된 경우 %CommonProgramFiles%/dbus-1/services: 이 위치는 시스템 전체에 설치된 소프트웨어 패키지에 적합합니다.
dbus-daemon과 동일한 디렉토리 계층 구조(접두사)에 있는 share/dbus-1/services 디렉토리: 이 위치는 dbus-daemon과 함께 설치된 소프트웨어 스택에 적합합니다.

<standard_session_servicedirs/> 옵션은 /usr/local/etc/dbus-1/session.conf에 정의된 사용자별 세션 버스 데몬에만 관련됩니다. 다른 구성 파일에 넣는 것은 아마도 넌센스일 것입니다.

`<standard_system_servicedirs/>`

<standard_system_servicedirs/>는 서비스 파일을 검색해야 하는 표준 시스템 전체 활성화 디렉토리를 지정합니다. 세션 서비스와 마찬가지로 나열된 첫 번째 디렉토리가 가장 높은 우선 순위를 갖습니다.

Unix에서 표준 세션 서비스 디렉토리는 다음과 같습니다:

/usr/local/share/dbus-1/system-services: 이 위치는 D-Bus 사양에 의해 지정되며 시스템 관리자가 로컬로 설치한 소프트웨어에 적합합니다.
/usr/share/dbus-1/system-services: 이 위치는 D-Bus 사양에 의해 지정되며 운영 체제 패키지에 의해 설치된 소프트웨어에 적합합니다.
dbus가 컴파일될 때 지정된 ${datadir}에 대한 **$ {datadir}/dbus-1/system-services**, 일반적으로 /usr/share: 이 위치는 참조 dbus-daemon 구현에서 제공하는 확장이며 dbus-daemon과 함께 설치된 소프트웨어 스택에 적합합니다.
/lib/dbus-1/system-services: 이 위치는 D-Bus 사양에 의해 지정되며 운영 체제 패키지에 의해 설치되고 초기 부팅 중에 사용되는 소프트웨어를 위한 것입니다 (그러나 참조 dbus-daemon은 초기 부팅 중에 사용할 수 있도록 설계되지 않았습니다)

Windows에는 표준 시스템 버스가 없으므로 표준 시스템 버스 디렉토리도 없습니다.

<standard_system_servicedirs/> 옵션은 /usr/local/share/dbus-1/system.conf에 정의된 시스템별 버스 데몬에만 관련이 있습니다. 다른 구성 파일에 넣는 것은 아마도 넌센스일 것입니다.

`<servicehelper/>`

<servicehelper/>는 대체 사용자로 시스템 데몬을 시작하는데 사용되는 setuid 도우미를 지정합니다. 일반적으로 이것은 libexec에 있는 dbus-daemon-launch-helper 실행 파일이어야 합니다.

<servicehelper/> 옵션은 /usr/local/share/dbus-1/system.conf에 정의된 시스템별 버스 데몬에만 관련이 있습니다. 다른 구성 파일에 넣는 것은 아마도 넌센스일 것입니다.

`<limit>`

<limit>는 리소스 제한을 설정합니다. 예를 들어:

<limit name="max_message_size">64</limit>
<limit name="max_completed_connections">512</limit>

이름 속성은 필수입니다. 사용 가능한 제한 이름은 다음과 같습니다:

"max_incoming_bytes"

단일 연결에서 들어오는 메시지의 총 크기(바이트)
"max_incoming_unix_fds"

단일 연결에서 들어오는 메시지의 총 유닉스 fds 수
"max_outgoing_bytes"

단일 연결을 위해 대기 중인 메시지의 총 크기(바이트)
"max_outgoing_unix_fds"

단일 연결을 위해 대기 중인 Unix fds의 총 메시지 수
"max_message_size"

단일 메시지의 최대 크기(바이트)
"max_message_unix_fds"

단일 메시지의 최대 유닉스 fds
"service_start_timeout"

시작된 서비스가 연결되어야 할 때까지 밀리초(천분의 일)
"auth_timeout"

밀리초(1000분의 1초)의 연결이 인증을 위해 제공됩니다.
"pending_fd_timeout"

밀리초(천분의 1초) fd가 연결을 끊기 전에 dbus-daemon에 전송되도록 주어집니다.
"max_completed_connections"

인증된 연결의 최대 수
"max_incomplete_connections"

인증되지 않은 최대 연결 수
"max_connections_per_user"

동일한 사용자로부터 완료된 연결의 최대 수(Unix OS에서만 시행됨)
"max_pending_service_starts"

동시에 진행 중인 최대 서비스 시작 수
"max_names_per_connection"

단일 연결이 소유할 수 있는 최대 이름 수
"max_match_rules_per_connection"

단일 연결에 대한 최대 일치 규칙 수
"max_replies_per_connection"

연결당 보류 중인 메서드 응답의 최대 수(진행 중인 호출 수)
"reply_timeout"

메서드 호출 시간이 초과될 때까지 밀리초(천분의 일)
"max_containers"

총 앱 컨테이너에서 사용할 수 있는 제한된 서버의 최대 수
"max_containers_per_user"

Unix uid당 최대 앱 컨테이너 수
"max_container_metadata_bytes"

각 앱 컨테이너에 저장할 메타데이터의 최대 바이트 수
"max_connections_per_container"

각 앱 컨테이너에 대한 최대 연결 수(인증 또는 비인증)

최대 수신/발신 대기열 크기를 사용하면 1바이트가 최대치 미만으로 남아 있는 경우 새 메시지를 대기열에 추가할 수 있습니다. 따라서 실제로 max_message_size만큼 최대값을 초과할 수 있습니다.

max_completed_connections를 max_connections_per_user로 나눈 값은 시스템 전체 버스의 모든 연결을 사용하여 다른 모든 사용자에게 서비스 거부를 위해 함께 작업할 수 있는 사용자 수입니다.

제한은 일반적으로 사용자 세션 버스가 아닌 시스템 전체 버스에만 관심이 있습니다.

`<policy>`

<policy> 요소는 버스에 대한 특정 연결 집합에 적용할 보안 정책을 정의합니다. 정책은 <allow> 및 <deny> 요소로 구성됩니다. 정책은 일반적으로 시스템 전체 버스와 함께 사용됩니다. 예상 트래픽을 허용하고 예기치 않은 트래픽을 방지한다는 점에서 방화벽과 유사합니다.

현재 시스템 버스에는 메서드 호출을 보내고 버스 이름을 소유하기 위한 기본 거부 정책과 메시지 수신, 신호 보내기 및 NO_REPLY 플래그가 없는 각 메서드 호출에 대한 단일 성공 또는 오류 응답 보내기를 위한 기본 허용 정책이 있습니다. 예상 회신 수를 초과하여 보내는 것은 허용되지 않습니다.

일반적으로 시스템 서비스는 자체 프로세스에서 실행되고 단일 버스 이름을 제공하는 작은 대상 프로그램으로 유지하는 것이 가장 좋습니다. 그런 다음, 프로세스가 버스 이름을 요구할 수 있도록하는 "own" 권한에 대한 <allow> 규칙과 일부 또는 모든 uid에서 당신의 서비스로의 트래픽을 허용하는 "send_destination" 규칙만 있으면 됩니다.

<policy> 요소에는 다음 네 가지 속성 중 하나가 있습니다:

context="(default|mandatory)"
at_console="(true|false)"
user="username or userid"
group="group name or gid"

정책은 다음과 같이 연결에 적용됩니다:

모든 context="default" 정책이 적용됩니다.
모든 group="connection's user's group" 정책은 정의되지 않은 순서로 적용됩니다.
모든 user="connection's auth user" 정책은 정의되지 않은 순서로 적용됩니다.
모든 at_console="true" 정책이 적용됩니다.
모든 at_console="false" 정책이 적용됩니다.
모든 context="mandatory" 정책이 적용됩니다.

나중에 적용된 정책은 정책이 겹치는 경우 이전에 적용된 정책보다 우선 적용됩니다. 동일한 user/group/context를 가진 여러 정책은 구성 파일에 나타나는 순서대로 적용됩니다.

`<deny>` | `<allow>`

<deny> 요소는 <policy> 요소 아래에 나타나며 일부 작업을 금지합니다. <allow> 요소는 이전 <deny> 문에 대한 예외를 만들고 <deny>처럼 작동하지만 반대의 의미로 작동합니다.

이러한 요소의 가능한 속성은 다음과 같습니다:

send_interface="interface_name" | "*"
send_member="method_or_signal_name" | "*"
send_error="error_name" | "*"
send_broadcast="true" | "false"
send_destination="name" | "*"
send_destination_prefix="name"
send_type="method_call" | "method_return" | "signal" | "error" | "*"
send_path="/path/name" | "*"

receive_interface="interface_name" | "*"
receive_member="method_or_signal_name" | "*"
receive_error="error_name" | "*"
receive_sender="name" | "*"
receive_type="method_call" | "method_return" | "signal" | "error" | "*"
receive_path="/path/name" | "*"

send_requested_reply="true" | "false"
receive_requested_reply="true" | "false"

eavesdrop="true" | "false"

own="name" | "*"
own_prefix="name"
user="username" | "*"
group="groupname" | "*"

Examples:

<deny send_destination="org.freedesktop.Service" send_interface="org.freedesktop.System" send_member="Reboot"/>
<deny send_destination="org.freedesktop.System"/>
<deny receive_sender="org.freedesktop.System"/>
<deny user="john"/>
<deny group="enemies"/>

<deny> 요소의 속성은 거부가 특정 작업과 "일치(matches)"하는지 여부를 결정합니다. 일치하면 작업이 거부됩니다 (구성 파일의 이후 규칙에서 허용하지 않는 한).

하나 이상의 send_* 속성 패밀리가 있는 규칙은 연결이 메시지 전송을 시도할 때 순서대로 확인됩니다. 메시지와 일치하는 마지막 규칙은 메시지를 보낼 수 있는지 여부를 결정합니다. 잘 알려진 세션 버스는 일반적으로 모든 메시지를 보낼 수 있습니다. 잘 알려진 시스템 버스는 일반적으로 모든 신호, dbus-daemon에 대한 선택된 메소드 호출, 그리고 이전에 전송된 각 메소드 호출(성공 또는 오류)에 대해 정확히 하나의 응답을 보내는 것을 허용합니다. 이들 중 하나는 구성에 의해 재정의될 수 있습니다. 시스템 버스에서 메소드 호출을 수신할 서비스는 일반적으로 <policy context="default"><allow send_destination="…"/><policy> 형식의 규칙을 통해 이를 허용하는 구성을 설치해야 합니다.

하나 이상의 receive_* 속성 패밀리를 포함하거나 엿듣기 속성만 포함하고 다른 것은 포함하지 않는 규칙은 메시지의 각 수신자에 대해 확인됩니다. (메시지가 브로드캐스트이거나 연결이 엿듣기 중인 경우 수신자가 두 명 이상 있을 수 있음). 메시지와 일치하는 마지막 규칙은 메시지를 받을 수 있는지 여부를 결정합니다. 잘 알려진 세션 버스는 일반적으로 엿듣기을 포함한 모든 메시지 수신을 허용합니다. 잘 알려진 시스템 버스는 일반적으로 엿듣기가 포함되지 않은 모든 메시지 수신을 허용합니다. (수신자에게 주소가 지정된 모든 유니캐스트 메시지 및 브로드캐스트 메시지).

엿듣기, minfds 및 max_fds 속성은 send 또는 receive_ 규칙에 적용할 수 있는 수정자이며 아래에 설명되어 있습니다.

send_destination 및 receive_sender 규칙은 지정된 이름의 *소유자*에게 메시지를 보내거나 받을 수 없음을 의미하며 *해당 이름*으로 메시지를 보낼 수 없다는 의미는 아닙니다. 즉, 연결이 서비스 A, B, C를 소유하고 A로의 전송이 거부된 경우 B 또는 C로의 전송도 작동하지 않습니다. 특별한 경우로 send_destination="*"은 모든 메시지와 일치하고 (목적지가 지정되었는지 여부에 관계없이) receive_sender="*"는 모든 메시지와 유사하게 일치합니다.

send_destination_prefix 규칙은 전송을 위해 전체 네임스페이스를 열거나 닫습니다. 이는 메시지가 기본 소유자인지 대기 중인 소유자인지에 관계없이 접두사와 일치하는 이름의 소유자에게 전송될 수도 있고 전송되지 않을 수도 있음을 의미합니다. 즉, <allow send_destination_prefix="a.b"/> 규칙 및 이름 "a.b", "a.b.c" 및 "a.b.c.d"가 버스에 있는 경우 세 개의 개별 규칙이 <allow send_destination ="a.b"/>, <allow send_destination="a.b.c"/> 및 <allow send_destination="a.b.c.d"/>가 정의되었습니다. 이름 일치에 대한 규칙은 own_prefix(아래 참조)에서와 같습니다. 접두사 "a.b"는 이름 "a.b" 또는 "a.b.c" 또는 "a.b.c.d"와 일치하지만 "a.bc" 또는 "a.c"는 일치하지 않습니다. send_destination_prefix 속성은 동일한 규칙에서 send_destination 속성과 결합될 수 없습니다.

send_broadcast="true"인 규칙은 대상(브로드캐스트)이 없는 신호 메시지와 일치합니다. send_broadcast="false"인 규칙은 반대입니다. 모든 유니캐스트 대상(모든 메서드 호출, 응답 및 오류와 함께 유니캐스트 신호)과 일치하지만 대상이 없는 메시지(브로드캐스트)와 일치하지 않습니다. 이는 대상이 있는지 여부에 관계없이 보낸 메시지와 일치하는 send_destination="*"과 다릅니다.

다른 send* 및 receive 속성은 허용되는 속성의 경우 *가 모든 메시지와 일치한다는 점을 제외하고 메시지 헤더의 지정된 필드에 대해 순전히 텍스트/값별 일치입니다(관련 헤더 필드가 있는지 여부에 관계없이). 예를 들어 send_interface="*"는 인터페이스 헤더 필드가 포함되지 않은 경우에도 전송된 모든 메시지와 일치합니다. foo.bar. 와 같은 더 복잡한 glob 일치는 허용되지 않습니다.

"Eavesdropping"는 애플리케이션이 소유하지 않은 이름으로 명시적으로 주소가 지정된 메시지를 수신하거나 그러한 메시지에 대한 응답일때 발생합니다. 따라서 엿듣기는 서비스로 지정된 메시지에만 적용되고 해당 메시지에 응답합니다 (즉, 신호에는 적용되지 않음).

<allow>의 경우 eavesdrop="true"는 엿듯기 중에도 규칙이 일치함을 나타냅니다. eavesdrop="false"는 기본값이며 규칙이 메시지가 지정된 수신자에게만 가는 것을 허용함을 의미합니다. <deny>의 경우 eavesdrop="true"는 엿듣기할 때만 규칙이 일치함을 나타냅니다. eavesdrop="false"는 <deny>의 기본값이기도 하지만 여기에서는 엿듣기하지 않을 때도 규칙이 항상 적용된다는 의미입니다. 엿듣기 속성은 보내기 및 받기 규칙(send* 및 receive* 속성 포함)과만 결합할 수 있습니다.

[send|receive]_requested_reply 속성은 엿듣기 속성과 유사하게 작동합니다. <deny> 또는 <allow>가 예상되는 응답과 일치하는지 여부를 제어합니다(이전 메서드 호출 메시지에 해당). 이 속성은 응답 메시지(오류 및 메서드 반환)에만 의미가 있으며 다른 메시지 유형에서는 무시됩니다.

<allow>의 경우 [send|receive]_requested_reply="true"가 기본값이며 규칙에서 요청된 응답만 허용됨을 나타냅니다. [send|receive]_requested_reply="false"는 규칙이 예기치 않은 경우에도 응답을 허용함을 의미합니다.

<deny>의 경우 [send|receive]_requested_reply="false"가 기본값이지만 응답이 요청되지 않은 경우에만 규칙이 일치함을 나타냅니다. [send|receive]_requested_reply="true"는 보류 중인 응답 상태에 관계없이 규칙이 항상 적용됨을 나타냅니다.

minfds 및 max_fds 속성은 send 또는 receive_ 규칙을 수정합니다. min_fds 속성이 있는 규칙은 메시지에 적어도 그만큼 많은 Unix 파일 설명자가 첨부되어 있는 경우에만 메시지와 일치합니다. 반대로 max_fds 속성이 있는 규칙은 첨부된 파일 설명자가 그보다 많지 않은 경우에만 메시지와 일치합니다. 실제로 이러한 속성을 가진 규칙은 <allow send_destination="…" max_fds="0"/>, <deny send_destination="…" min_fds="1"/> 또는 <deny receive_sender="*" min_fds="1"/>.

사용자 또는 그룹 속성이 있는 규칙은 메시지 버스에 대한 새 연결이 설정될 때 확인되고 연결을 계속할 수 있는지 여부를 제어합니다. 이러한 각 속성은 다른 속성과 결합할 수 없습니다. 특별한 경우로 user="*" 및 group="*"은 모든 연결과 일치합니다. 이 형식의 규칙이 없는 경우 기본값은 dbus-daemon 프로세스를 소유한 동일한 사용자 ID의 연결을 허용하는 것입니다. 잘 알려진 세션 버스는 일반적으로 기본 동작을 사용하는 반면 잘 알려진 시스템 버스는 일반적으로 모든 연결을 허용합니다.

own 또는 own_prefix 속성이 있는 규칙은 연결이 잘 알려진 버스 이름을 소유하려고 할 때 확인됩니다. 특별한 경우로 own="*"은 잘 알려진 버스 이름과 일치합니다. 잘 알려진 세션 버스는 일반적으로 모든 연결이 모든 이름을 소유할 수 있도록 허용하는 반면 잘 알려진 시스템 버스는 추가 구성에서 허용하는 경우를 제외하고 일반적으로 어떤 연결도 이름을 소유하는 것을 허용하지 않습니다. 이름을 소유할 시스템 서비스는 일반적으로 <policy user="some-system-user"><allow own="…"/></policy> 형식의 규칙을 통해 이를 허용하는 구성을 설치해야 합니다.

<allow own_prefix="a.b"/>를 사용하면 이름 "a.b" 또는 점으로 구분된 첫 번째 요소가 "a.b"인 이름을 소유할 수 있습니다. 특히 "a.b.c" 또는 "a.b.c.d"는 소유할 수 있지만 "a.bc" 또는 "ac" 는 소유할 수 없습니다. 이것은 Telepathy 및 ReserveDevice와 같은 서비스가 org.freedesktop.Telepathy.ConnectionManager.(anything) 및 org.freedesktop.ReserveDevice1.(anything)과 같이 잘 알려진 이름의 하위 트리에 대한 의미를 정의할 때 유용합니다.

사용자 또는 그룹에 대한 <policy> 내부의 사용자 또는 그룹을 거부하는 것은 의미가 없습니다. 사용자/그룹 거부는 context="default" 또는 context="mandatory" 정책 내에서만 가능합니다.

단일 <deny> 규칙은 send_destination 및 send_interface 및 send_type과 같은 속성의 조합을 지정할 수 있습니다. 이 경우 거부는 두 속성이 거부되는 메시지와 일치하는 경우에만 적용됩니다. 예를 들어 <deny send_interface="foo.bar" send_destination="foo.blah"/>는 주어진 인터페이스와 주어진 버스 이름을 가진 메시지를 거부합니다. OR 효과를 얻으려면 여러 <deny> 규칙을 지정합니다.

"메시지를 보낼 수 있는지 여부"와 "수신할 수 있는지 여부"가 별도로 평가되기 때문에 동일한 규칙에 send 및 receive 속성을 모두 포함할 수 없습니다.

메시지의 인터페이스 필드는 선택 사항이므로 send_interface/receive_interface에 주의하십시오. 특히 <deny send_interface="org.foo.Bar"/>를 지정하지 마십시오! 이로 인해 모든 서비스에 대해 인터페이스 없음 메시지가 차단되며 이는 의도한 것과 거의 다릅니다. 항상 <deny send_interface="org.foo.Bar" send_destination="org.foo.Service"/> 형식의 규칙을 사용하세요.

`<selinux>`

<selinux> 요소에는 보안 강화 Linux와 관련된 설정이 포함되어 있습니다. 자세한 내용은 아래에 있습니다.

`<associate>`

<associate> 요소는 <selinux> 요소 아래에 나타나 매핑을 생성합니다. 지금은 한 종류의 연결만 가능합니다:

<associate own="org.freedesktop.Foobar" context="foo_t"/>

즉, 연결이 "org.freedesktop.Foobar"라는 이름을 소유하도록 요청하면 소스 컨텍스트가 연결 컨텍스트가 되고 대상 컨텍스트가 "foo_t"가 됩니다. 아래 SELinux에 대한 간략한 설명을 참조하세요.

여기서 컨텍스트는 이름을 요청할 때의 대상 컨텍스트이며 이름을 소유한 연결 컨텍스트가 아닙니다.

현재로서는 어떤 이름을 소유하기 위한 기본값을 설정할 수 있는 방법이 없습니다. 이 구문을 추가하면 다음과 같이 보일 것입니다:

<associate own="*" context="foo_t"/>

이것이 유용한 이유를 찾으면 개발자에게 알려주십시오. 현재 기본값은 버스 자체의 보안 컨텍스트입니다.

두 개의 <associate> 요소가 동일한 이름을 지정하면 구성 파일에 나중에 나타나는 요소가 사용됩니다.

`<apparmor>`

요소는 버스에서 AppArmor 중개를 구성하는 데 사용됩니다. 여기에는 중개 모드를 지정하는 하나의 속성이 포함될 수 있습니다:

<apparmor mode="(enabled|disabled|required)"/>

기본 모드는 "enabled"입니다. "enabled" 모드에서는 커널에서 AppArmor 지원을 사용할 수 있는 경우 AppArmor 조정이 수행됩니다. 사용할 수 없는 경우 dbus-daemon이 시작되지만 AppArmor 중개는 발생하지 않습니다. "disabled" 모드에서는 AppArmor 조정이 비활성화됩니다. "required" 모드에서 AppArmor 지원을 사용할 수 있는 경우 AppArmor 중재가 활성화되고, 그렇지 않으면 dbus-daemon이 시작을 거부합니다.

버스가 시작된 후에는 버스의 AppArmor 중개 모드를 변경할 수 없습니다. 구성 파일에서 모드를 수정하고 SIGHUP 신호를 데몬에 보내는 것은 중개 모드에 영향을 주지 않습니다.

Appendix

SELinux

SELinux에 대한 자세한 내용은 http://www.nsa.gov/selinux/를 참조하십시오. 몇 가지 유용한 발췌문들은 다음과 같습니다:

Note:
상기 링크는 무효합니다. 대신 https://www.nsa.gov/Portals/70/documents/what-we-do/research/selinux/documentation/presentations/2005-flexible-support-for-security-policies-into-linux-os-presentation.pdf 문서나 위키피디아 (https://en.wikipedia.org/wiki/Security-Enhanced_Linux)를 참고하십시오.

시스템의 모든 주체(프로세스)와 객체(예: 파일, 소켓, IPC 객체 등)에는 보안 컨텍스트라고 하는 보안 속성 모음이 할당됩니다. 보안 컨텍스트는 보안 정책과 관련된 특정 주체 또는 객체와 관련된 모든 보안 속성을 포함합니다.

보안 컨텍스트를 더 잘 캡슐화하고 효율성을 높이기 위해 SELinux의 정책 시행 코드는 일반적으로 보안 컨텍스트가 아닌 SID(보안 식별자)를 처리합니다. SID는 런타임 시 보안 서버에 의해 보안 컨텍스트에 매핑되는 정수입니다.

보안 결정이 필요할 때 정책 시행 코드는 한 쌍의 SID (일반적으로 주체의 SID와 객체의 SID이지만 때로는 한 쌍의 주체 SID 또는 객체 SID 쌍)와 객체 보안 클래스를 전달합니다. 보안 서버에. 객체 보안 클래스는 객체의 종류를 나타냅니다. 프로세스, 일반 파일, 디렉토리, TCP 소켓 등

액세스 결정은 지정된 SID 및 클래스 쌍에 대한 권한 부여 여부를 지정합니다. 각 개체 클래스에는 해당 클래스가 있는 개체에 대한 작업을 제어하기 위해 정의된 관련 권한 집합이 있습니다.

D-Bus는 두 곳에서 SELinux 보안 검사를 수행합니다.

첫째, 메시지가 한 연결에서 다른 연결로 라우팅될 때마다 버스 데몬은 첫 번째 연결의 보안 컨텍스트를 소스로, 두 번째 연결의 보안 컨텍스트를 대상으로, 개체 클래스 "dbus" 및 요청된 권한 "send_msg"을 사용하여 권한을 확인 합니다.

연결에 보안 컨텍스트를 사용할 수 없는 경우 (UNIX 도메인 소켓을 사용할 때는 불가능), 사용되는 대상 컨텍스트는 버스 데몬 자체의 컨텍스트입니다. UNIX 도메인 소켓만 시스템 전체 버스에 연결하는 데 사용된다고 가정하기 때문에 현재 이 기본값을 변경할 방법이 없습니다. 이것이 변경되면 기본 연결 컨텍스트를 설정하는 방법을 추가할 것입니다.

둘째, 연결이 이름을 소유하도록 요청할 때마다 버스 데몬은 연결의 보안 컨텍스트를 소스로, 구성 파일의 이름에 대해 지정된 보안 컨텍스트를 대상으로, 개체 클래스 "dbus" 및 요청된 권한 "acquire_svc"을 사용하여 권한을 확인합니다.

버스 이름에 대한 보안 컨텍스트는 이 문서의 앞부분에서 설명한 <associate> 요소로 지정됩니다. 이름에 구성 파일과 관련된 보안 컨텍스트가 없으면 버스 데몬 자체의 보안 컨텍스트가 사용됩니다.

AppArmor

AppArmor 제한 컨텍스트는 애플리케이션이 버스에 연결될 때 저장됩니다. 제한 컨텍스트는 레이블과 제한 모드로 구성됩니다. 보안 결정이 필요할 때 데몬은 제한 컨텍스트를 사용하여 AppArmor 정책을 쿼리하여 작업을 허용 또는 거부해야 하는지 여부와 작업을 감사해야 하는지 여부를 결정합니다.

데몬은 세 곳에서 AppArmor 보안 검사를 수행합니다.

첫째, 메시지가 한 연결에서 다른 연결로 라우팅될 때마다 버스 데몬은 버스 이름과 함께 첫 번째 연결의 레이블을 소스로, 레이블 및/또는 두 번째 연결의 연결 이름을 대상으로 사용하여 권한을 확인합니다. 경로 이름, 인터페이스 이름 및 구성원 이름. method_return 및 오류 메시지와 같은 응답 메시지는 이미 허용된 메시지에 대한 응답인 경우 암시적으로 허용됩니다.

둘째, 연결이 이름을 소유하도록 요청할 때마다 버스 데몬은 버스 이름과 함께 연결 레이블을 소스로, 요청된 이름을 대상으로 사용하여 권한을 확인합니다.

셋째, 연결이 도청을 시도할 때마다 버스 데몬은 버스 이름과 함께 연결 레이블을 소스로 사용하여 권한을 확인합니다.

버스 조정을 위한 AppArmor 규칙은 버스 구성 파일에 저장되지 않습니다. 애플리케이션의 AppArmor 프로필에 저장됩니다. 자세한 내용은 apparmor.d(5)를 참조하십시오.

Note: AppArmor ("Application Armor")는 시스템 관리자가 프로그램 프로필 별로 프로그램의 역량을 제한할 수 있게 해주는 리눅스 커널 보안 모듈입니다. 자세한 사항은 위키피디아를 참고 하시기 바랍니다. (https://ko.wikipedia.org/wiki/AppArmor)

freejack

Learns until die

이전 포스트

systemd for Administrators [번역]

다음 포스트

DBUS Configuration File Description

`<busconfig>`

`<type>`

`<include>`

`<includedir>`

`<user>`

`<fork>`

`<keep_umask>`

`<syslog>`

`<pidfile>`

`<allow_anonymous>`

`<listen>`

`<auth>`

`<servicedir>`

`<standard_session_servicedirs/>`

`<standard_system_servicedirs/>`

`<servicehelper/>`

`<limit>`

`<policy>`

`<deny>` | `<allow>`

`<selinux>`

`<associate>`

`<apparmor>`

Appendix

SELinux

AppArmor

systemd for Administrators [번역]

GNU make

0개의 댓글

DBUS Configuration File Description

<busconfig>

<type>

<include>

<includedir>

<user>

<fork>

<keep_umask>

<syslog>

<pidfile>

<allow_anonymous>

<listen>

<auth>

<servicedir>

<standard_session_servicedirs/>

<standard_system_servicedirs/>

<servicehelper/>

<limit>

<policy>

<deny> | <allow>

<selinux>

<associate>

<apparmor>

Appendix

SELinux

AppArmor

systemd for Administrators [번역]

GNU make

0개의 댓글

`<busconfig>`

`<type>`

`<include>`

`<includedir>`

`<user>`

`<fork>`

`<keep_umask>`

`<syslog>`

`<pidfile>`

`<allow_anonymous>`

`<listen>`

`<auth>`

`<servicedir>`

`<standard_session_servicedirs/>`

`<standard_system_servicedirs/>`

`<servicehelper/>`

`<limit>`

`<policy>`

`<deny>` | `<allow>`

`<selinux>`

`<associate>`

`<apparmor>`