D- 버스 인증 및 인증

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-Bus 사양을 탐색 한 후 ~/.dbus-keyrings/org_freedesktop_general다른 계정으로 복사 했지만 도움이되지 않습니다.

socat을 사용하여 schedar 의 Access D-Bus 에서 영감을 얻은 TCP를 통해 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 원격 시스템에서 작동합니다.

로컬 머신은 데비안 wheezy를 실행합니다. 원격 시스템은 FreeBSD 10.1을 실행합니다.

D-Bus 인증 및 권한 부여 방법을 이해하지 못합니다.

1. 내가 알 수있는 한 원격 시스템의 자격 증명없이 도청 할 수있는 이유는 무엇입니까? D-Bus를 TCP 연결로 전달할 때 무엇을 노출합니까? 왜에 대한 권한입니다 dbus-monitor및 notify-send다른는?
2. 초록 소켓 또는 TCP 연결을 통해 동일한 컴퓨터의 다른 계정에서 도청 할 수없는 이유는 무엇입니까?
3. 쿠키 파일이 몇 분마다 변경되는 것을 알았습니다 (정기 간격인지 여부는 알지 못했습니다). 왜?

(TCP에서 수신 대기하는 D-Bus 데몬을 시작할 수 있다는 것을 알고 있습니다. 제 질문의 목적이 아닙니다. 왜 내가 한 일과 왜 일하지 않았는지 이해하고 싶습니다.)

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

매직 쿠키 파일은 여러 D-Bus 인증 메커니즘 중 하나 일뿐입니다. D-Bus는 SASL 호환 인터페이스 ( RFC4422 참조 )를 구현 하여 광범위한 인증 메커니즘을 지원합니다. 이러한 메커니즘 중 하나를 "EXTERNAL"인증이라고하며 전송 채널 자체를 사용하여 인증을 보장해야합니다. 최소한 UNIX 소켓을 통한 D-Bus의 경우 시도 된 첫 번째 인증 메커니즘 인 것으로 보입니다.

D- 버스 사양에서 :

특수 자격 증명 통과 널 바이트

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

초기 바이트 이외의 컨텍스트에서 널 바이트는 오류입니다. 프로토콜은 ASCII 전용입니다.

널 바이트와 함께 전송 된 신임 정보는 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 서버입니다. D-Bus 사양 의 DBUS_COOKIE_SHA1 섹션에 따르면 쿠키는 생성 시간과 함께 저장되며 서버는 너무 오래된 쿠키를 삭제해야합니다. 분명히 수명은 "매우 짧을 수 있습니다".