☰

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-sendCookieファイルを読み取ろうとしないことを示しているので、リンクされていない理由を理解しています。

また、別のコンピュータに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クッキーが見つからないと文句を言います。 Cookieファイルをコピーしたら、notify-sendリモートコンピュータで作業できます。

ローカルコンピュータがDebian wheezyを実行しています。リモートコンピュータがFreeBSD 10.1を実行しています。

D-Bus認証と承認がどのように機能するか理解できません。

  1. 私が知っている限り、リモートコンピュータの資格情報なしで盗聴できるのはなぜですか？ D-BusをTCP接続に渡すときに何を公開しますか？dbus-monitorの承認と他の理由は何ですかnotify-send？
  2. 抽象ソケットまたはTCP接続を介して同じコンピュータ上の他のアカウントの内容を垣間見ることができないのはなぜですか？
  3. Cookieファイルが数分ごとに変更されることを確認しました（まだ定期的であることを確認できませんでした）。なぜ？

（私はTCPを聞くD-Busデーモンを起動できることを知っています。それは私の質問の目的ではありません。

ベストアンサー1

D-BusはここでMagic Cookieファイルを使用せずにUNIXドメインソケット（）を介して資格情報を渡しますSCM_CREDENTIALS。

マジッククッキーファイルは、いくつかのD-Bus認証メカニズムの1つにすぎません。 D-Busの実装SASL- 互換性のあるインターフェース（参照RFC4422) さまざまな認証メカニズムをサポートします。これらのメカニズムの1つを「外部」認証と呼びます。これは、トランスポートチャネル自体を使用して認証を保証する必要があることを意味します。少なくともUNIXソケットを介したD-Busの場合、これが試みられた最初の認証メカニズムのようです。

D-Bus仕様では：

特別な資格情報 - NULLバイト転送

クライアントはサーバーに接続した直後に nul バイトを送信する必要があります。このバイトには、SCM_CREDSまたはSCM_CREDENTIALSでsendmsg（）を使用してUNIXドメインソケットを介して資格情報を渡す一部のオペレーティングシステムの資格情報が含まれている場合があります。ただし、他の種類のソケットと資格情報を送信するためにバイトを送信する必要がないオペレーティングシステムでも、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. これは、古い/期限切れのCookieを新しいCookieに置き換えるD-Busサーバーです。 ~によるとDBUS_COOKIE_SHA1D-Bus仕様の一部によれば、クッキーは作成時間とともに保存され、サーバーは古すぎると思われるクッキーを削除する必要があります。明らかに、寿命は「かなり短いかもしれません。」

おすすめ記事