☰

D-Bus 인증 및 승인

tag-icon • tag-icon security authentication tcp d-bus authorization
D-Bus 인증 및 승인

D-Bus에 대한 원격 액세스를 설정하려고 하는데 인증 및 권한 부여(비)가 어떻게 작동하는지 이해가 되지 않습니다.

추상 소켓을 수신하는 D-Bus 서버가 있습니다.

$ echo $DBUS_SESSION_BUS_ADDRESS 
unix:abstract=/tmp/dbus-g5sxxvDlmz,guid=49bd93b893fe40d83604952155190c31

dbus-monitor나는 무슨 일인지 보려고 달려갔다 . 내 테스트 사례는 notify-send hello로컬 컴퓨터에서 실행될 때 작동한다는 것입니다.

동일한 컴퓨터의 다른 계정에서 버스에 연결할 수 없습니다.

otheraccount$ DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-g5sxxvDlmz,guid=49bd93b893fe40d83604952155190c31 dbus-monitor
Failed to open connection to session bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
otheraccount$ DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-g5sxxvDlmz,guid=49bd93b893fe40d83604952155190c31 notify-send hello

탐색 후D 버스 사양, 다른 계정으로 복사했지만 ~/.dbus-keyrings/org_freedesktop_general도움이 되지 않았습니다.

나는 다음에서 영감을 받아 TCP를 통해 D-Bus 소켓을 전달하려고 합니다.스케줄러~의socat을 사용하여 D-Bus에 원격으로 액세스.

socat TCP-LISTEN:8004,reuseaddr,fork,range=127.0.0.1/32 ABSTRACT-CONNECT:/tmp/dbus-g5sxxvDlmz

내 계정에서 TCP 소켓에 연결할 수 있습니다.

DBUS_SESSION_BUS_ADDRESS=tcp:host=127.0.0.1,port=8004 notify-send hello

하지만 다른 계정에서는 안 dbus-monitor되고 notify-send. dbus-monitor추상 소켓에 대해 위와 동일한 오류 메시지가 notify-send이제 추적을 내보냅니다.

otheraccount$ DBUS_SESSION_BUS_ADDRESS=tcp:host=127.0.0.1,port=8004 notify-send hello

** (notify-send:2952): WARNING **: The connection is closed

Stracing은 이 버전이 notify-send쿠키 파일을 읽으려고 시도하지 않는다는 것을 보여 주므로 연결되지 않는 이유를 이해합니다.

또한 다른 컴퓨터에 SSH를 시도하고 TCP 연결을 전달해 보았습니다.

ssh -R 8004:localhost:8004 remotehost

놀랍게도 dbus-monitor쿠키 파일 없이도 작동합니다! 원격 호스트에서 D-Bus 트래픽을 볼 수 있습니다. 내 로컬 인스턴스에서 도청에 대한 알림이 표시됩니다 dbus-monitor.

remotehost$ DBUS_SESSION_BUS_ADDRESS=tcp:host=127.0.0.1,port=8004 dbus-monitor
signal sender=org.freedesktop.DBus -> dest=:1.58 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.58"
method call sender=:1.58 -> dest=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "eavesdrop=true"

notify-send로컬 컴퓨터에서 실행 하면 dbus-monitor원격 호스트에 알림이 표시됩니다. 확실히 인증이 필요한 액세스 수준에 도달했습니다.

notify-send쿠키를 찾을 수 없다고 불평합니다. 쿠키 파일을 복사한 후 notify-send원격 컴퓨터에서 작업할 수 있습니다.

로컬 컴퓨터가 Debian wheezy를 실행 중입니다. 원격 컴퓨터가 FreeBSD 10.1을 실행 중입니다.

D-Bus 인증 및 승인이 어떻게 작동하는지 이해할 수 없습니다.

  1. 내가 아는 한, 원격 컴퓨터의 자격 증명 없이 도청할 수 있는 이유는 무엇입니까? D-Bus를 TCP 연결로 전달할 때 무엇을 노출합니까? dbus-monitor의 승인과 다른 이유는 무엇 입니까 notify-send?
  2. 추상 소켓이나 TCP 연결을 통해 동일한 컴퓨터에 있는 다른 계정의 내용을 엿들을 수 없는 이유는 무엇입니까?
  3. 쿠키 파일이 몇 분마다 변경되는 것을 확인했습니다(아직 주기적인지 확인하지 못했습니다). 왜?

(나는 TCP를 듣는 D-Bus 데몬을 시작할 수 있다는 것을 알고 있습니다. 그것은 내 질문의 목적이 아닙니다. 나는 내가 한 일이 효과가 있었지만 왜 그렇지 않았는지 이해하고 싶습니다.)

답변1

D-Bus는 여기서 매직 쿠키 파일을 사용하지 않고 UNIX 도메인 소켓( )을 통해 자격 증명을 전달합니다 SCM_CREDENTIALS.

매직 쿠키 파일은 여러 D-Bus 인증 메커니즘 중 하나일 뿐입니다. D-Bus 구현SASL- 호환 가능한 인터페이스(참조RFC4422) 다양한 인증 메커니즘을 지원합니다. 이러한 메커니즘 중 하나를 "외부" 인증이라고 합니다. 이는 전송 채널 자체를 사용하여 인증을 보장해야 함을 의미합니다. 적어도 UNIX 소켓을 통한 D-Bus의 경우 이것이 시도된 최초의 인증 메커니즘인 것 같습니다.

D-Bus 사양에서:

특수 자격 증명 - Null 바이트 전달

클라이언트는 서버에 연결한 후 즉시 nul 바이트를 보내야 합니다. 이 바이트에는 SCM_CREDS 또는 SCM_CREDENTIALS와 함께 sendmsg()를 사용하여 UNIX 도메인 소켓을 통해 자격 증명을 전달하는 일부 운영 체제에 대한 자격 증명 정보가 함께 제공될 수 있습니다. 그러나 다른 유형의 소켓 및 자격 증명을 전송하기 위해 바이트를 보낼 필요가 없는 운영 체제에서도 nul 바이트를 보내야 합니다. 이 문서에 설명된 텍스트 프로토콜은 단일 Null 바이트 이후에 시작됩니다. 클라이언트로부터 수신된 첫 번째 바이트가 널 바이트가 아닌 경우 서버는 클라이언트 연결을 끊을 수 있습니다.

초기 바이트 이외의 모든 컨텍스트에서 널 바이트는 오류입니다. 프로토콜은 ASCII만 지원합니다.

nul 바이트로 전송된 자격 증명은 SASL 메커니즘 EXTERNAL과 함께 사용할 수 있습니다.

인스턴스를 추적하면 dbus-daemon인스턴스에 연결할 때 연결하는 사용자의 자격 증명을 확인하는 것을 볼 수 있습니다.

$ strace dbus-daemon --session --nofork
...
accept4(4, {sa_family=AF_LOCAL, NULL}, [2], SOCK_CLOEXEC) = 8
...
recvmsg(8, {msg_name(0)=NULL, msg_iov(1)=[{"\0", 1}], msg_controllen=0, msg_flags=0}, 0) = 1
getsockopt(8, SOL_SOCKET, SO_PEERCRED, {pid=6694, uid=1000, gid=1000}, [12]) = 0

따라서 귀하의 질문에 대답하려면 다음을 수행하십시오.

  1. D-Bus 데몬은 커널 검증 사용자 ID를 사용하여 사용자를 인증합니다. 프록시 연결을 사용하면 socat누구든지 UID를 사용하여 D-Bus 데몬에 연결할 수 있습니다.

  2. 다른 UID에서 소켓에 직접 연결을 시도하면 데몬은 연결된 UID가 연결을 허용해야 하는 UID가 아니라는 것을 인식합니다. 나는 기본적으로 데몬 자신의 UID만 허용된다고 생각하지만, 이는 공식적으로 확인되지 않았습니다. 그러나 다른 사용자를 허용할 수 있습니다. /etc/dbus-1/및 의 구성 파일을 참조하세요 man dbus-daemon.

  3. 이는 오래된/만료된 쿠키를 새로운 쿠키로 교체하는 D-Bus 서버입니다. ~에 따르면DBUS_COOKIE_SHA1D-Bus 사양의 일부에 따르면 쿠키는 생성 시간과 함께 저장되며 서버는 너무 오래되었다고 간주되는 쿠키를 삭제해야 합니다. 분명히 수명은 "상당히 짧을 수 있습니다."

관련 정보