dbus-daemon - En ligne dans le Cloud

PROGRAMME:

Nom

dbus-daemon - Démon de bus de messages

SYNOPSIS

dbus-démon

dbus-démon [--version] [--session] [--system] [--config-file=DOSSIER]
[--imprimer-adresse [=DESCRIPTEUR]] [--print-pid [=DESCRIPTEUR]] [--fourchette]

DESCRIPTION

dbus-démon est le démon du bus de messages D-Bus. Voir http://www.freedesktop.org/software/dbus/
pour plus d'informations sur la grande image. D-Bus est d'abord une bibliothèque qui fournit
communication individuelle entre deux applications quelconques ; dbus-démon est une application qui
utilise cette bibliothèque pour implémenter un démon de bus de messages. Plusieurs programmes se connectent au
démon de bus de messages et peuvent échanger des messages entre eux.

Il existe deux instances de bus de messages standard : le bus de messages à l'échelle du système (installé sur
de nombreux systèmes comme le service d'initialisation « messagebus ») et le bus de messages par session de connexion utilisateur
(démarré chaque fois qu'un utilisateur se connecte). dbus-démon est utilisé pour ces deux cas, mais
avec un fichier de configuration différent.

L'option --session est équivalente à "--config-file=/usr/share/dbus-1/session.conf"Et
l'option --system est équivalente à "--config-file=/usr/share/dbus-1/system.conf". Par
en créant des fichiers de configuration supplémentaires et en utilisant l'option --config-file,
des démons de bus de messages spéciaux pourraient être créés.

Le démon à l'échelle du système est normalement lancé par un script d'initialisation, appelé par défaut simplement
"messagebus".

Le démon à l'échelle du système est largement utilisé pour la diffusion d'événements système, tels que les modifications apportées à
la file d'attente de l'imprimante ou ajouter/supprimer des périphériques.

Le démon par session est utilisé pour diverses communications interprocessus entre les ordinateurs de bureau
applications (cependant, il n'est en aucun cas lié à X ou à l'interface graphique).

SIGHUP obligera le démon D-Bus à recharger PARTIELLEMENT son fichier de configuration et à vider
ses caches d'informations sur les utilisateurs/groupes. Certains changements de configuration nécessiteraient de tout supprimer
des applications dans le bus ; ils ne prendront donc effet que si vous redémarrez le démon. Changements de politique
devrait prendre effet avec SIGHUP.

OPTIONS

Les options suivantes sont prises en charge :

--config-file=FICHIER
Utilisez le fichier de configuration donné.

--fourchette
Forcer le bus de messages à bifurquer et devenir un démon, même si le fichier de configuration le fait
pas préciser qu'il devrait. Dans la plupart des contextes, le fichier de configuration obtient déjà ceci
à droite, cependant. Cette option n'est pas prise en charge sous Windows.

--pas de fourchette
Forcer le bus de messages à ne pas bifurquer et devenir un démon, même si le fichier de configuration
précise qu'il le devrait. Sous Windows, le dbus-daemon ne bifurque jamais, donc cette option est
autorisé mais ne fait rien.

--print-address[=DESCRIPTEUR]
Imprimer l'adresse du bus de messages sur la sortie standard ou sur le fichier donné
descripteur. Ceci est utilisé par les programmes qui lancent le bus de messages.

--print-pid[=DESCRIPTEUR]
Imprimer l'ID de processus du bus de messages sur la sortie standard ou sur le fichier donné
descripteur. Ceci est utilisé par les programmes qui lancent le bus de messages.

--session
Utilisez le fichier de configuration standard pour le bus de messages par session de connexion.

--système
Utilisez le fichier de configuration standard pour le bus de messages à l'échelle du système.

--version
Imprimez la version du démon.

--introspection
Imprimez les informations d'introspection pour toutes les interfaces internes D-Bus.

--adresse[=ADRESSE]
Définissez l'adresse d'écoute. Cette option remplace l'adresse configurée dans le
fichier de configuration.

--systemd-activation
Activez l'activation du service de style systemd. Uniquement utile en conjonction avec le systemd
gestionnaire de système et de session sous Linux.

--nopidfile
N'écrivez pas de fichier PID même s'il est configuré dans les fichiers de configuration.

CONFIGURATION DOSSIER

Un démon de bus de messages a un fichier de configuration qui le spécialise pour un
application. Par exemple, un fichier de configuration peut configurer le bus de messages pour qu'il soit un
bus de messages à l'échelle du système, tandis qu'un autre peut le configurer pour être un bus de session de connexion par utilisateur.

Le fichier de configuration établit également les limites de ressources, les paramètres de sécurité, etc.
en avant.

Le fichier de configuration ne fait partie d'aucune spécification d'interopérabilité et
la compatibilité n'est pas garantie ; ce document est une documentation, pas une spécification.

Les configurations standard du bus de messages à l'échelle du système et par session sont configurées dans les fichiers
"/usr/share/dbus-1/system.conf" et "/usr/share/dbus-1/session.conf". Ces fichiers normalement
un system-local.conf ou session-local.conf dans /etc/dbus-1; vous pouvez mettre local
remplace dans ces fichiers pour éviter de modifier les fichiers de configuration principaux.

Le fichier de configuration est un document XML. Il doit avoir la déclaration doctype suivante :

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

Les éléments suivants peuvent être présents dans le fichier de configuration.

·

Élément racine.

·

Le type bien connu du bus de messages. Les valeurs actuellement connues sont « système » et « session » ;
si d'autres valeurs sont définies, elles doivent être soit ajoutées à la spécification D-Bus, soit
espace de noms. Le dernier l'élément "gagne" (les valeurs précédentes sont ignorées). Cet élément
contrôle uniquement quelles variables d'environnement spécifiques au bus de messages sont définies dans activé
clientes. La plupart des règles qui distinguent un bus de session du bus système sont
contrôlé à partir des autres éléments du fichier de configuration.

Si le type bien connu du bus de messages est "session", alors le DBUS_STARTER_BUS_TYPE
la variable d'environnement sera définie sur "session" et l'environnement DBUS_SESSION_BUS_ADDRESS
variable sera définie sur l'adresse du bus de session. De même, si le type de
le bus de message est "système", alors la variable d'environnement DBUS_STARTER_BUS_TYPE sera définie
à "système" et la variable d'environnement DBUS_SESSION_BUS_ADDRESS sera définie sur le
l'adresse du bus système (qui est normalement bien connue de toute façon).

Exemple: session

·

Inclure un fichier nom de fichier.conf À ce point. Si le nom de fichier est
relatif, il est situé par rapport au fichier de configuration faisant l'inclus.

a un attribut facultatif "ignore_missing=(yes|no)" qui est par défaut "no" si
pas fourni. Cet attribut contrôle s'il s'agit d'une erreur fatale pour le fichier inclus à
être absent.

·

Inclure tous les fichiers dans nourriture À ce point. Fichiers dans le répertoire
sont inclus dans un ordre indéfini. Seuls les fichiers se terminant par ".conf" sont inclus.

Ceci est destiné à permettre l'extension du bus système par des packages particuliers. Par exemple,
si CUPS veut pouvoir envoyer une notification des changements de file d'attente d'impression, il pourrait
installer un fichier dans /usr/share/dbus-1/system.d ou /etc/dbus-1/system.d qui a permis à toutes les applications
de recevoir ce message et a autorisé l'utilisateur du démon d'imprimante à l'envoyer.

·

Le compte d'utilisateur sous lequel le démon doit s'exécuter, en tant que nom d'utilisateur ou UID. Si le démon
ne peut pas changer cet UID au démarrage, il se fermera. Si cet élément n'est pas présent, le
le démon ne changera pas ou ne se souciera pas de son UID.

Le dernier entrée dans le fichier "wins", les autres sont ignorés.

L'utilisateur est changé une fois que le bus a terminé l'initialisation. Donc les prises etc. seront
créé avant de changer d'utilisateur, mais aucune donnée ne sera lue à partir des clients avant de changer d'utilisateur.
Cela signifie que les sockets et les fichiers PID peuvent être créés dans un emplacement qui nécessite la racine
privilèges pour l'écriture.

·

S'il est présent, le démon de bus devient un vrai démon (fourche en arrière-plan, etc.). Cette
est généralement utilisé plutôt que l'option de ligne de commande --fork.

·

S'il est présent, le démon de bus conserve son umask d'origine lors du bifurcation. Cela peut être utile pour
éviter d'affecter le comportement des processus enfants.

·

S'il est présent, le démon de bus se connectera à syslog.

·

S'il est présent, le démon de bus écrira son pid dans le fichier spécifié. Le --nopidfile
L'option de ligne de commande est prioritaire sur ce paramètre.

·

Le cas échéant, les connexions authentifiées à l'aide du mécanisme ANONYME seront
autorisé à se connecter. Cette option n'a d'effet pratique que si le mécanisme ANONYME
a également été activé à l'aide de la élément, décrit ci-dessous.

·

Ajoutez une adresse sur laquelle le bus doit écouter. L'adresse est au format standard D-Bus
qui contient un nom de transport ainsi que des paramètres/options possibles.

Exemple: unix:chemin=/tmp/foo

Exemple: tcp:host=localhost,port=1234

S'il y a plusieurs éléments, puis le bus écoute sur plusieurs adresses. Les
bus transmettra son adresse aux services démarrés ou à d'autres parties intéressées avec le dernier
adresse indiquée dans premier. C'est-à-dire que les applications essaieront de se connecter au dernier
adresse en premier.

Les sockets tcp peuvent accepter des adresses IPv4, des adresses IPv6 ou des noms d'hôtes. Si un nom d'hôte se résout
à plusieurs adresses, le serveur se liera à toutes. La famille=ipv4 ou la famille=ipv6
les options peuvent être utilisées pour le forcer à se lier à un sous-ensemble d'adresses

Exemple: tcp:host=localhost,port=0,family=ipv4

Un cas particulier est l'utilisation d'un numéro de port de zéro (ou l'omission du port), ce qui signifie
choisissez un port disponible sélectionné par le système d'exploitation. Le numéro de port choisi peut être
obtenu avec le paramètre de ligne de commande --print-address et sera présent dans d'autres
cas où le serveur signale sa propre adresse, comme lorsque DBUS_SESSION_BUS_ADDRESS est
défini.

Exemple: tcp:host=localhost,port=0

Les adresses tcp/nonce-tcp permettent également une option bind=hostname, utilisée dans une adresse écoutable pour
configurer l'interface sur laquelle le serveur va écouter : soit le hostname est l'IP
l'adresse d'une des interfaces de la machine locale (le plus souvent 127.0.0.1), un nom DNS
qui se résout à l'une de ces adresses IP, '0.0.0.0' pour écouter sur toutes les interfaces IPv4
simultanément, ou '::' pour écouter simultanément sur toutes les interfaces IPv4 et IPv6 (si
pris en charge par le système d'exploitation). S'il n'est pas spécifié, la valeur par défaut est la même que "hôte".

Exemple: tcp:host=localhost,bind=0.0.0.0,port=0

·

Répertorie les mécanismes d'autorisation autorisés. Si cet élément n'existe pas, alors tout est connu
les mécanismes sont autorisés. S'il y a plusieurs éléments, tous les mécanismes énumérés
sont autorisés. L'ordre dans lequel les mécanismes sont répertoriés n'a pas de sens.

Exemple: EXTERNE

Exemple: DBUS_COOKIE_SHA1

·

Ajoute un répertoire pour rechercher les fichiers .service. Les répertoires sont analysés en commençant par le
premier à apparaître dans le fichier de configuration (le premier fichier .service trouvé qui fournit un
service particulier sera utilisé).

Les fichiers de service indiquent au bus comment démarrer automatiquement un programme. Ils sont principalement utilisés
avec le bus par session utilisateur, pas le bus à l'échelle du système.

·

équivaut à spécifier une série de
éléments pour chacun des répertoires de données dans la « Spécification du répertoire de base XDG » avec
le sous-répertoire "dbus-1/services", donc par exemple "/usr/share/dbus-1/services" serait
parmi les répertoires recherchés.

La « Spécification du répertoire de base XDG » se trouve à l'adresse
http://freedesktop.org/wiki/Standards/basedir-spec s'il n'a pas bougé, sinon essayez votre
moteur de recherche préféré.

Les l'option n'est pertinente que pour le bus par session utilisateur
démon défini dans /etc/dbus-1/session.conf. Le mettre dans n'importe quel autre fichier de configuration
serait probablement absurde.

·

spécifie les répertoires d'activation standard à l'échelle du système
qui doit être recherché pour les fichiers de service. Cette option est par défaut
/usr/share/dbus-1/system-services.

Les l'option n'est pertinente que pour le démon de bus par système
défini dans /usr/share/dbus-1/system.conf. Le mettre dans n'importe quel autre fichier de configuration
probablement être un non-sens.

·

spécifie l'assistant setuid qui est utilisé pour lancer les démons système avec un
autre utilisateur. Typiquement, cela devrait être l'exécutable dbus-daemon-launch-helper dans
situé à libexec.

Les L'option n'est pertinente que pour le démon de bus par système défini dans
/usr/share/dbus-1/system.conf. Le mettre dans n'importe quel autre fichier de configuration serait probablement
être un non-sens.

·

établit une limite de ressources. Par exemple:

64
512

L'attribut name est obligatoire. Les noms de limites disponibles sont :

"max_incoming_bytes" : taille totale en octets des messages
entrant à partir d'une seule connexion
"max_incoming_unix_fds" : nombre total de fds unix de messages
entrant à partir d'une seule connexion
"max_outgoing_bytes" : taille totale en octets des messages
mis en file d'attente pour une seule connexion
"max_outgoing_unix_fds" : nombre total de fds unix de messages
mis en file d'attente pour une seule connexion
"max_message_size" : taille maximale d'un seul message dans
octets
"max_message_unix_fds" : max fds unix d'un seul message
"service_start_timeout" : millisecondes (millièmes) jusqu'à
un service démarré doit se connecter
"auth_timeout" : millisecondes (millièmes) a
la connexion est donnée à
authentifier
"pending_fd_timeout" : millisecondes (millièmes) a
fd est donné pour être transmis à
dbus-daemon avant de déconnecter le
connexion
"max_completed_connections" : nombre maximum de connexions authentifiées
"max_incomplete_connections" : nombre maximum de non authentifiés
liens
"max_connections_per_user" : nombre maximum de connexions terminées depuis
le même utilisateur
"max_pending_service_starts" : nombre maximum de lancements de service dans
progresser en même temps
"max_names_per_connection" : nombre maximum de noms par simple
connexion peut posséder
"max_match_rules_per_connection": nombre maximum de règles de correspondance pour un seul
connexion
"max_replies_per_connection" : nombre maximum de méthode en attente
réponses par connexion
(nombre d'appels en cours)
"reply_timeout" : millisecondes (millièmes)
jusqu'à ce qu'un appel de méthode expire

Les tailles maximales de file d'attente entrante/sortante permettent à un nouveau message d'être mis en file d'attente s'il reste un octet
en dessous du max. Vous pouvez donc en fait dépasser le max de max_message_size.

max_completed_connections divisé par max_connections_per_user est le nombre d'utilisateurs qui
peuvent travailler ensemble pour déni de service tous les autres utilisateurs en utilisant toutes les connexions sur le
bus à l'échelle du système.

Les limites ne sont normalement intéressantes que sur le bus à l'échelle du système, pas sur les bus de session utilisateur.

·

Les L'élément définit une politique de sécurité à appliquer à un ensemble particulier de
liaisons avec le bus. Une politique se compose de et éléments. Les politiques sont
normalement utilisé avec le bus à l'échelle du système ; ils sont analogues à un pare-feu en ce qu'ils permettent
trafic attendu et empêcher le trafic inattendu.

Actuellement, le bus système a une politique de refus par défaut pour envoyer des appels de méthode et posséder
noms de bus. Tout le reste, en particulier les messages de réponse, les chèques de réception et les signaux a
une politique d'autorisation par défaut.

En général, il est préférable de conserver les services système sous la forme de petits programmes ciblés qui s'exécutent dans
leur propre processus et fournissent un nom de bus unique. Ensuite, il suffit d'un
règle pour l'autorisation « propre » de laisser le processus réclamer le nom du bus, et une
Règle "send_destination" pour autoriser le trafic de certains ou de tous les uids vers votre service.

Les élément a l'un des quatre attributs :

context="(défaut|obligatoire)"
at_console="(vrai|faux)"
user="nom d'utilisateur ou ID d'utilisateur"
group="nom du groupe ou gid"

Les stratégies sont appliquées à une connexion comme suit :

- toutes les politiques context="default" sont appliquées
- toutes les politiques group="connection's user's group" sont appliquées
dans un ordre indéfini
- toutes les politiques user="connection's auth user" sont appliquées
dans un ordre indéfini
- toutes les politiques at_console="true" sont appliquées
- toutes les politiques at_console="false" sont appliquées
- toutes les politiques context="mandatory" sont appliquées

Les politiques appliquées plus tard remplaceront celles appliquées plus tôt, lorsque les politiques se chevauchent.
Plusieurs politiques avec le même utilisateur/groupe/contexte sont appliquées dans l'ordre dans lequel elles apparaissent
le fichier de configuration.




UNE l'élément apparaît sous un élément et interdit certaines actions. Les
élément fait une exception à la précédente déclarations, et fonctionne comme mais
avec le sens inverse.

Les attributs possibles de ces éléments sont :

send_interface="interface_name"
send_member="method_or_signal_name"
send_error="nom_erreur"
envoyer_destination="nom"
send_type="method_call" | "méthode_retour" | « signaler » | "Erreur"
send_path="/chemin/nom"

recevoir_interface="interface_name"
receive_member="method_or_signal_name"
recevoir_erreur="nom_erreur"
receive_sender="nom"
recevoir_type="method_call" | "méthode_retour" | « signaler » | "Erreur"
recevoir_chemin="/chemin/nom"

send_requested_reply="true" | "faux"
receive_requested_reply="true" | "faux"

eavesdrop="true" | "faux"

propre="nom"
own_prefix="nom"
user="nom d'utilisateur"
groupe="nom du groupe"

Exemples :







Les les attributs de l'élément déterminent si le refus "correspond" à une action particulière.
S'il correspond, l'action est refusée (à moins que des règles ultérieures du fichier de configuration ne l'autorisent).

Les règles send_destination et receive_sender signifient que les messages ne peuvent pas être envoyés à ou
reçus du *propriétaire* du nom donné, non pas qu'ils ne puissent pas être envoyés *à ce nom*.
Autrement dit, si une connexion possède les services A, B, C et que l'envoi à A est refusé, l'envoi à B
ou C ne fonctionnera pas non plus.

Les autres attributs send_* et receive_* sont des correspondances purement textuelles/par valeur avec le
champ donné dans l'en-tête du message.

L'"écoute clandestine" se produit lorsqu'une application reçoit un message qui a été explicitement
adressé à un nom que l'application ne possède pas, ou est une réponse à un tel message.
L'écoute clandestine ne s'applique donc qu'aux messages adressés aux services et aux réponses aux
de tels messages (c'est-à-dire qu'il ne s'applique pas aux signaux).

Pour , eavesdrop="true" indique que la règle correspond même en cas d'écoute clandestine.
eavesdrop="false" est la valeur par défaut et signifie que la règle permet uniquement aux messages d'aller à
leur destinataire spécifié. Pour , eavesdrop="true" indique que la règle correspond
uniquement en cas d'écoute clandestine. eavesdrop="false" est la valeur par défaut pour aussi, mais ici il
signifie que la règle s'applique toujours, même lorsqu'il n'y a pas d'écoute clandestine. L'attribut d'écoute
ne peut être combiné qu'avec les règles d'envoi et de réception (avec les attributs send_* et receive_*).

L'attribut [send|receive]_requested_reply fonctionne de manière similaire à l'attribut eavesdrop.
Il contrôle si le ou correspond à une réponse attendue (correspond à
un message d'appel de méthode précédent). Cet attribut n'a de sens que pour les messages de réponse
(erreurs et retours de méthode) et est ignoré pour les autres types de message.

Pour , [send|receive]_requested_reply="true" est la valeur par défaut et indique que seul
les réponses demandées sont autorisées par la règle. [envoyer|recevoir]_requested_reply="false" signifie
que la règle permet toute réponse même si inattendue.

Pour , [send|receive]_requested_reply="false" est la valeur par défaut mais indique que le
la règle correspond uniquement lorsque la réponse n'a pas été demandée. [envoyer|recevoir]_requested_reply="true"
indique que la règle s'applique toujours, quel que soit l'état de réponse en attente.

les refus d'utilisateur et de groupe signifient que l'utilisateur ou le groupe donné peut ne pas se connecter au message
autobus.

Pour "nom", "nom d'utilisateur", "nom de groupe", etc. le caractère "*" peut être remplacé, ce qui signifie
"tout." Les globs complexes comme "foo.bar.*" ne sont pas autorisés pour l'instant car ils seraient du travail pour
mettre en œuvre et peut-être encourager une sécurité bâclée de toute façon.

vous permet de posséder le nom "ab" ou tout nom dont le premier
les éléments séparés par des points sont "ab": en particulier, vous pouvez posséder "abc" ou "abcd", mais pas
"a.bc" ou "ac". Ceci est utile lorsque des services comme Telepathy et ReserveDevice définissent un
sens pour les sous-arbres de noms bien connus, tels que
org.freedesktop.Telepathy.ConnectionManager.(n'importe quoi) et
org.freedesktop.ReserveDevice1.(n'importe quoi).

Cela n'a pas de sens de refuser un utilisateur ou un groupe à l'intérieur d'un pour un utilisateur ou un groupe ;
les refus d'utilisateur/groupe ne peuvent être qu'à l'intérieur des politiques context="default" ou context="mandatory".

Un seul La règle peut spécifier des combinaisons d'attributs tels que send_destination et
send_interface et send_type. Dans ce cas, le refus ne s'applique que si les deux attributs
correspond au message refusé. par exemple
send_destination="foo.blah"/> refuserait les messages avec l'interface donnée ET la donnée
nom de l'autobus. Pour obtenir un effet OU, vous spécifiez plusieurs règles.

Vous ne pouvez pas inclure à la fois les attributs send_ et receive_ dans la même règle, car « si le
message peut être envoyé" et "s'il peut être reçu" sont évalués séparément.

Soyez prudent avec send_interface/receive_interface, car le champ d'interface dans les messages
est facultatif. En particulier, ne précisez PAS ! Cette volonté
bloquer les messages sans interface pour tous les services, ce qui n'est certainement pas le cas
ce que vous vouliez. Utilisez toujours des règles de la forme :
send_destination="org.foo.Service"/>

·

Les L'élément contient les paramètres liés à Security Enhanced Linux. Plus de détails
ci-dessous.

·

Un l'élément apparaît sous un élément et crée un mappage. À l'heure actuelle
un seul type d'association est possible :



Cela signifie que si une connexion demande à posséder le nom "org.freedesktop.Foobar", alors le
le contexte source sera le contexte de la connexion et le contexte cible sera
"foo_t" - voir la brève discussion de SELinux ci-dessous.

Notez que le contexte ici est le contexte cible lors de la demande d'un nom, PAS le contexte de
la connexion possédant le nom.

Il n'y a actuellement aucun moyen de définir une valeur par défaut pour posséder un nom, si nous ajoutons cette syntaxe, il
ressemblera:



Si vous trouvez une raison pour laquelle cela est utile, informez-en les développeurs. À l'heure actuelle, la valeur par défaut sera
être le contexte de sécurité du bus lui-même.

Si deux éléments spécifient le même nom, l'élément apparaissant plus tard dans le
fichier de configuration sera utilisé.

·

Les L'élément est utilisé pour configurer la médiation AppArmor sur le bus. Il peut contenir
un attribut qui spécifie le mode de médiation :



Le mode par défaut est "activé". En mode « activé », la médiation AppArmor sera effectuée si
La prise en charge d'AppArmor est disponible dans le noyau. S'il n'est pas disponible, dbus-daemon
démarrer, mais la médiation AppArmor n'aura pas lieu. En mode "désactivé", la médiation AppArmor est
désactivée. En mode « requis », la médiation AppArmor sera activée si la prise en charge d'AppArmor est
disponible, sinon dbus-daemon refusera de démarrer.

Le mode de médiation AppArmor du bus ne peut pas être modifié après le démarrage du bus. Modifier
le mode dans le fichier de configuration et l'envoi d'un signal SIGHUP au démon n'a aucun effet
sur le mode médiation.

SÉLINUX

See http://www.nsa.gov/selinux/ pour plus de détails sur SELinux. Quelques extraits utiles :

Chaque sujet (processus) et objet (par exemple, fichier, socket, objet IPC, etc.) dans le système est
attribué une collection d'attributs de sécurité, connue sous le nom de contexte de sécurité. Une sécurité
contexte contient tous les attributs de sécurité associés à un sujet particulier ou
objet qui sont pertinents pour la politique de sécurité.

Afin de mieux encapsuler les contextes de sécurité et de fournir une plus grande efficacité, le
le code d'application des politiques de SELinux gère généralement les identifiants de sécurité (SID) plutôt
que les contextes de sécurité. Un SID est un entier mappé par le serveur de sécurité à un
contexte de sécurité au moment de l'exécution.

Lorsqu'une décision de sécurité est requise, le code d'application de la politique transmet une paire de SID
(généralement le SID d'un sujet et le SID d'un objet, mais parfois une paire de sujets
SID ou une paire de SID d'objet) et une classe de sécurité d'objet au serveur de sécurité. Les
la classe de sécurité de l'objet indique le type d'objet, par exemple un processus, un fichier normal, un
répertoire, un socket TCP, etc.

Les décisions d'accès spécifient si une autorisation est accordée ou non pour une paire donnée de SID
et classe. Chaque classe d'objets a un ensemble d'autorisations associées définies pour contrôler
opérations sur les objets avec cette classe.

D-Bus effectue des contrôles de sécurité SELinux à deux endroits.

Premièrement, chaque fois qu'un message est acheminé d'une connexion à une autre, le bus
le démon vérifiera les permissions avec le contexte de sécurité de la première connexion comme source,
contexte de sécurité de la deuxième connexion comme cible, classe d'objet "dbus" et demandé
autorisation "envoyer_msg".

Si un contexte de sécurité n'est pas disponible pour une connexion (impossible en utilisant le domaine UNIX
sockets), alors le contexte cible utilisé est le contexte du démon de bus lui-même. Il y a
actuellement aucun moyen de modifier cette valeur par défaut, car nous supposons que seul le domaine UNIX
sockets seront utilisés pour se connecter au bus du système. Si cela change, nous ajouterons probablement
un moyen de définir le contexte de connexion par défaut.

Deuxièmement, chaque fois qu'une connexion demande à posséder un nom, le démon de bus vérifiera les autorisations
avec le contexte de sécurité de la connexion comme source, le contexte de sécurité spécifié pour
le nom dans le fichier de configuration comme cible, la classe d'objet "dbus" et l'autorisation demandée
"acquérir_svc".

Le contexte de sécurité pour un nom de bus est spécifié avec le élément décrit
plus tôt dans ce document. Si un nom n'a pas de contexte de sécurité associé dans le
de configuration, le contexte de sécurité du démon de bus lui-même sera utilisé.

APPAREIL

Le contexte de confinement AppArmor est stocké lorsque les applications se connectent au bus. Les
contexte de confinement se compose d'une étiquette et d'un mode de confinement. Lorsqu'une décision de sécurité
est requis, le démon utilise le contexte de confinement pour interroger la stratégie AppArmor afin de
déterminer si l'action doit être autorisée ou refusée et si l'action doit être auditée.

Le démon effectue des contrôles de sécurité AppArmor à trois endroits.

Premièrement, chaque fois qu'un message est acheminé d'une connexion à une autre, le bus
démon vérifiera les autorisations avec l'étiquette de la première connexion comme source, étiquette
et/ou le nom de la connexion de la deuxième connexion comme cible, ainsi que le nom du bus, le
chemin, le nom de l'interface et le nom du membre. Messages de réponse, tels que method_return
et les messages d'erreur, sont implicitement autorisés s'ils sont en réponse à un message qui a
déjà été autorisé.

Deuxièmement, chaque fois qu'une connexion demande à posséder un nom, le démon de bus vérifiera les autorisations
avec le libellé de la connexion comme source, le nom demandé comme cible, ainsi que le
nom de l'autobus.

Troisièmement, chaque fois qu'une connexion tente d'écouter, le démon du bus vérifiera les autorisations
avec le libellé de la connexion comme source, ainsi que le nom du bus.

Les règles AppArmor pour la médiation de bus ne sont pas stockées dans les fichiers de configuration de bus. Elles sont
stocké dans le profil AppArmor de l'application. S'il te plait regarde apparmor.d(5) pour plus de détails.

DÉBOGAGE

Si vous essayez de savoir où vont vos messages ou pourquoi vous ne recevez pas
messages, vous pouvez essayer plusieurs choses.

N'oubliez pas que le bus système est fortement verrouillé et si vous n'avez pas installé de
fichier de politique de sécurité pour permettre à votre message de passer, cela ne fonctionnera pas. Pour le bus de session,
ce n'est pas un souci.

Le moyen le plus simple de comprendre ce qui se passe dans le bus est de lancer le dbus-moniteur
programme, qui est fourni avec le package D-Bus. Vous pouvez également envoyer des messages de test avec
dbus-envoi. Ces programmes ont leurs propres pages de manuel.

Si vous voulez savoir ce que fait le démon lui-même, vous pouvez envisager d'exécuter un
copie du démon à tester. Cela vous permettra de mettre le démon sous un
débogueur, ou exécutez-le avec une sortie détaillée, sans gâcher votre session et votre système réels
démons.

Pour exécuter une copie de test distincte du démon, par exemple, vous pouvez ouvrir un terminal et taper :

DBUS_VERBOSE=1 dbus-daemon --session --print-address

L'adresse du démon de test sera imprimée au démarrage du démon. Tu devras
copier-coller cette adresse et l'utiliser comme valeur de DBUS_SESSION_BUS_ADDRESS
variable d'environnement lorsque vous lancez les applications que vous souhaitez tester. Cela provoquera
ces applications à se connecter à votre bus de test au lieu du DBUS_SESSION_BUS_ADDRESS de
votre véritable bus de session.

DBUS_VERBOSE=1 n'aura AUCUN EFFET à moins que votre copie de D-Bus n'ait été compilée avec verbose
mode activé. Ceci n'est pas recommandé dans les versions de production en raison de l'impact sur les performances. Tu
peut avoir besoin de reconstruire D-Bus si votre copie n'a pas été construite en pensant au débogage. (DBUS_VERBOSE
affecte également la bibliothèque D-Bus et donc les applications utilisant D-Bus ; il peut être utile de voir
sortie détaillée à la fois du côté client et du démon.)

Si vous voulez faire preuve de fantaisie, vous pouvez créer une configuration de bus personnalisée pour votre bus de test (voir
les fichiers session.conf et system.conf qui définissent les deux configurations par défaut pour
Exemple). Cela vous permettrait de spécifier un répertoire différent pour les fichiers .service, par exemple
Exemple.

Utiliser dbus-daemon en ligne à l'aide des services onworks.net