Provided by: manpages-fr_4.27.0-1_all 
NOM
systemd-analyze — Analyser et déboguer le gestionnaire du système
SYNOPSIS
systemd-analyze [OPTIONS...] [time]
systemd-analyze [OPTIONS...] blame
systemd-analyze [OPTIONS...] critical-chain [UNITÉ...]
systemd-analyze [OPTIONS...] dump [MOTIF...]
systemd-analyze [OPTIONS...] plot [>fichier.svg]
systemd-analyze [OPTIONS...] dot [MOTIF...] [>fichier.dot]
systemd-analyze [OPTIONS...] unit-files
systemd-analyze [OPTIONS...] unit-paths
systemd-analyze [OPTIONS...] exit-status [ÉTAT...]
systemd-analyze [OPTIONS...] capability [CAPACITÉ...| {-m | --mask} MASQUE]
systemd-analyze [OPTIONS...] condition CONDITION...
systemd-analyze [OPTIONS...] syscall-filter [ENSEMBLE...]
systemd-analyze [OPTIONS...] filesystems [ENSEMBLE...]
systemd-analyze [OPTIONS...] calendar SPEC...
systemd-analyze [OPTIONS...] timestamp HORODATAGE...
systemd-analyze [OPTIONS...] timespan DURÉE...
systemd-analyze [OPTIONS...] cat-config NOM|CHEMIN...
systemd-analyze [OPTIONS...] compare-versions VERSION1 [OP] VERSION2
systemd-analyze [OPTIONS...] verify FICHIER...
systemd-analyze [OPTIONS...] security [UNITÉ...]
systemd-analyze [OPTIONS...] inspect-elf FICHIER...
systemd-analyze [OPTIONS...] malloc [D-BUS SERVICE...]
systemd-analyze [OPTIONS...] fdstore UNITÉ...
systemd-analyze [OPTIONS...] image-policy POLITIQUE...
systemd-analyze [OPTIONS...] has-tpm2
systemd-analyze [OPTIONS...] pcrs [PCR...]
systemd-analyze [OPTIONS...] srk [>FICHIER]
systemd-analyze [OPTIONS...] architectures [NOM...]
systemd-analyze [OPTIONS...] smbios11
DESCRIPTION
systemd-analyze peut être utilisée pour déterminer les statistiques de performance du démarrage du
système et récupérer d'autres informations d'état et de traçage du système et du gestionnaire de
services, et vérifier la justesse des fichiers d'unité. Elle est aussi utilisée pour accéder à des
fonctions spéciales utiles au débogage avancé du gestionnaire du système.
Si aucune commande n'est passée, systemd-analyze-time est implicite.
systemd-analyze time
Cette commande affiche le temps écoulé dans le noyau avant que l'espace utilisateur n'ait été atteint, le
temps écoulé dans l'initrd avant que l'espace utilisateur normal du système ne soit atteint, et le temps
pris par l'espace utilisateur normal du système pour s'initialiser. Notez que ces mesures ne font que
mesurer le temps écoulé jusqu'au moment où tous les services du système ont été lancés, mais pas
nécessairement jusqu'à ce qu'ils aient terminé leur initialisation ou que le disque soit inactif.
Exemple 1. Afficher la durée de l'amorçage (boot)
# dans un conteneur
$ systemd-analyze time
Startup finished in 296ms (userspace)
multi-user.target reached after 275ms in userspace
# sur une vraie machine
$ systemd-analyze time
Startup finished in 2.584s (kernel) + 19.176s (initrd) + 47.847s (userspace) = 1min 9.608s
multi-user.target reached after 47.820s in userspace
systemd-analyze blame
Cette commande affiche une liste de toutes les unités en service, classées en fonction du temps passé à
s'initialiser. Cette information peut être utilisée pour optimiser les temps d'amorçage. Prenez en compte
que la sortie peut être trompeuse étant donné que l'initialisation d'un service peut apparaître lente
simplement parce qu'il attend l'initialisation d'un autre service pour se finaliser. Notez aussi :
systemd-analyze blame n'affiche pas de résultats pour les services avec Type=simple, car systemd
considère de tels services comme démarrant immédiatement, ce qui fait qu'aucune mesure de délai
d'initialisation ne peut être faite. Notez aussi que cette commande ne montre que le temps pris par les
unités pour démarrer, elle ne montre pas combien de temps ont passé les tâches de l'unité dans la file
d'attente d'exécutions. Cela montre en particulier le temps que l'unité a passé en état « actif », lequel
n'est pas défini pour les unités telles que les unités périphériques qui effectuent une transition
directement d'« inactive » à « active ». Cette commande donne ainsi une impression de la performance du
code du programme, mais ne peut refléter avec exactitude la latence introduite par l'attente du matériel
et d'évènements similaires.
Exemple 2. Afficher quelles unités prennent le plus de temps lors de l'amorçage
$ systemd-analyze blame
32.875s pmlogger.service
20.905s systemd-networkd-wait-online.service
13.299s dev-vda1.device
...
23ms sysroot.mount
11ms initrd-udevadm-cleanup-db.service
3ms sys-kernel-config.mount
systemd-analyze critical-chain [UNITÉ...]
Cette commande affiche un arbre de la chaîne de temps critique d'unités (pour chacune des UNITÉs
indiquées ou pour la cible par défaut sinon). Le temps écoulé pour que l'unité soit active ou démarrée
est affiché après le caractère « @ ». Le temps pris par l'unité pour démarrer est affiché après le
caractère « + ». Notez que la sortie peut être inexacte dans la mesure où l'initialisation de services
pourrait dépendre de l'activation d'un socket et à cause de l'exécution en parallèle d'unités. Aussi, à
l'instar de la commande blame, cette commande ne prend en compte que le temps passé par les unités en
état d'« activation », et donc ne couvre pas les unités qui ne sont jamais passées par un état
d'« activation » (telles les unités de périphériques d'unité qui passent directement de l'état
« inactif » à « actif »). En outre, elle ne montre pas d'information sur les tâches (et en particulier
sur les tâches achevées).
Exemple 3. systemd-analyze critical-chain
$ systemd-analyze critical-chain
multi-user.target @47.820s
└─pmie.service @35.968s +548ms
└─pmcd.service @33.715s +2.247s
└─network-online.target @33.712s
└─systemd-networkd-wait-online.service @12.804s +20.905s
└─systemd-networkd.service @11.109s +1.690s
└─systemd-udevd.service @9.201s +1.904s
└─systemd-tmpfiles-setup-dev.service @7.306s +1.776s
└─kmod-static-nodes.service @6.976s +177ms
└─systemd-journald.socket
└─system.slice
└─-.slice
systemd-analyze dump [motif...]
Sans aucun paramètre, cette commande renvoie une sérialisation lisible (habituellement très longue) de
l'état complet du gestionnaire de services. Un motif global (glob) facultatif peut être spécifié,
limitant la sortie aux unités dont les noms correspondent à l'un des motifs. Le format de sortie est
susceptible d'être modifié sans préavis et ne devrait pas être soumis à l'analyse par des applications.
Cette commande a un débit limité pour les utilisateurs non privilégiés.
Exemple 4. Afficher l'état interne du gestionnaire utilisateur
$ systemd-analyze --user dump
Timestamp userspace: Thu 2019-03-14 23:28:07 CET
Timestamp finish: Thu 2019-03-14 23:28:07 CET
Timestamp generators-start: Thu 2019-03-14 23:28:07 CET
Timestamp generators-finish: Thu 2019-03-14 23:28:07 CET
Timestamp units-load-start: Thu 2019-03-14 23:28:07 CET
Timestamp units-load-finish: Thu 2019-03-14 23:28:07 CET
-> Unit proc-timer_list.mount:
Description: /proc/timer_list
...
-> Unit default.target:
Description: Main user target
...
systemd-analyze malloc [D-Bus service...]
Cette commande peut être utilisée pour demander la sortie de l'état de la mémoire interne (comme renvoyé
par malloc_info(3)) d'un service D-Bus. Si aucun service n'est indiqué, la demande sera envoyée à
org.freedesktop.systemd1 (le gestionnaire de services système ou utilisateur). La stabilité du format de
sortie n'est pas garantie et ne devrait pas être analysé par les applications.
Le service doit implémenter l'interface org.freedesktop.MemoryAllocation1. Dans la suite systemd, elle
est actuellement implémentée seulement par le gestionnaire.
systemd-analyze plot
Cette commande affiche un graphique SVG détaillant quels services du système ont démarré à quel moment,
mettant en évidence le temps passé à leur initialisation, ou les données horaires brutes en format JSON
ou tableau.
Exemple 5. Tracer un graphique d'amorçage
$ systemd-analyze plot >bootup.svg
$ eog bootup.svg&
Il convient de noter que ce graphique est basé sur les données les plus récentes relatives à la
synchronisation des unités chargées. Cela signifie que si une unité démarre, est stoppée et redémarre
encore, les informations affichées ne couvriront que le cycle de démarrage le plus récent, pas le
premier. Par conséquent, il est conseillé de consulter ces informations peu de temps après l'amorçage,
pour que cette distinction importe peu. En outre, les unités qui ne sont référencées par aucune autre
unité par le biais d'une dépendance peuvent être déchargées par le gestionnaire de service une fois
qu'elles se terminent (et qu'elles n'ont pas échoué). Ces unités n'apparaîtront pas dans le graphique.
systemd-analyze dot [motif...]
Cette commande génère une description textuelle du graphe de dépendances au format dot pour un traitement
ultérieur avec l'outil GraphViz dot(1). Utilisez une ligne de commande telle que systemd-analyze dot |
dot -Tsvg >systemd.svg pour générer un arbre de dépendances graphique. À moins que --order ou --require
ne soit passées, le graphe obtenu montrera à la fois les dépendances d'ordre et d'exigence. Le motif
optionnel de spécifications de style globbing (par exemple *.cible) peut être donné à la fin. Une
dépendance d'unité n'est inclue dans le graphe que si l'un des motifs correspond à la fois au nœud
d'origine ou de destination.
Exemple 6. Tracer toutes les dépendances des unités dont le nom commence avec « avahi-daemon »
$ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg >avahi.svg
$ eog avahi.svg
Exemple 7. Tracer les dépendances entre toutes les unités cibles connues
$ systemd-analyze dot --to-pattern='*.cible' --from-pattern='*.cible' \
| dot -Tsvg >cibles.svg
$ eog cibles.svg
systemd-analyze unit-paths
Cette commande affiche une liste de tous les répertoires desquels les fichiers d'unité, .d overrides, et
les liens symboliques .wants, .requires doivent être chargés. À combiner avec -- user pour retrouver la
liste pour l'instance du gestionnaire utilisateur, et -- global pour la configuration globale des
instances du gestionnaire utilisateur.
Exemple 8. Afficher tous les chemins pour les unités générées
$ systemd-analyze unit-paths | grep '^/run'
/run/systemd/system.control
/run/systemd/transient
/run/systemd/generator.early
/run/systemd/system
/run/systemd/system.attached
/run/systemd/generator
/run/systemd/generator.late
Remarquez que cette commande affiche la liste qui est compilée à l'intérieur de systemd-analyze et ne
communique pas avec le gestionnaire en cours d'exécution. Utilisez
systemctl [--user] [--global] show -p UnitPath --value
pour retrouver la liste réellement utilisée par le gestionnaire, avec tout répertoire vide omis.
systemd-analyze exit-status [ÉTAT...]
Cette commande affiche une liste des codes de retour avec leur « classe », c'est-à-dire la source de la
définition (une parmi « glibc », « systemd », « LSB » ou « BSD »), voir la section des codes retour des
processus dans systemd.exec(5). Si aucun autre argument n'est indiqué, tous les états connus sont
affichés. Sinon, seules les définitions pour les codes indiqués sont affichées.
Exemple 9. Afficher quelques exemples de noms d'état de retour
$ systemd-analyze exit-status 0 1 {63..65}
NAME STATUS CLASS
SUCCESS 0 glibc
FAILURE 1 glibc
- 63 -
USAGE 64 BSD
DATAERR 65 BSD
systemd-analyze capability [CAPACITÉ... | {-m | --mask} MASQUE]
Cette commande affiche une liste des capacités (capabilities) de Linux avec leur identifiant numérique.
Consulter capabilities(7) pour les détails. Si aucun argument n'est indiqué, la liste entière des
capacités connues du gestionnaire de services et du noyau est affichée. Les capacités définies par le
noyau, mais inconnues du gestionnaire de services sont affichées en tant que « cap_??? ». En option, si
des arguments sont spécifiés, ils doivent se référer aux capacités spécifiées par leur nom ou identifiant
numérique, auquel cas seules les capacités indiquées sont montrées dans la table.
De façon alternative, si --mask est passé, un argument numérique unique doit être indiqué, qui est
interprété comme un masque de capacités hexadécimal. Dans ce cas, seules les capacités présentes dans le
masque sont affichées dans la table. Ce mode est conçu pour aider à décoder les réglages de capacités
disponibles avec diverses interfaces de débogage (par exemple « /proc/PID/status »).
Exemple 10. Afficher quelques exemples de noms de capacité
$ systemd-analyze capability 0 1 {30..32}
NAME NUMBER
cap_chown 0
cap_dac_override 1
cap_audit_control 30
cap_setfcap 31
cap_mac_override 32
Exemple 11. Décoder un masque de capacités extrait de /proc
$ systemd-analyze capability -m 0000000000003c00
NAME NUMBER
cap_net_bind_service 10
cap_net_broadcast 11
cap_net_admin 12
cap_net_raw 13
systemd-analyze condition CONDITION...
Cette commande évaluera les affectations Condition*=... et Assert*=... et affichera leurs valeurs et la
valeur résultante de l'ensemble de conditions jointes. Consulter systemd.unit(5) pour une liste des
conditions disponibles et assertions.
Exemple 12. Évaluer les conditions qui vérifient les versions du noyau
$ systemd-analyze condition 'ConditionKernelVersion = ! <4.0' \
'ConditionKernelVersion = >=5.1' \
'ConditionACPower=|false' \
'ConditionArchitecture=|!arm' \
'AssertPathExists=/etc/os-release'
test.service: AssertPathExists=/etc/os-release succeeded.
Asserts succeeded.
test.service: ConditionArchitecture=|!arm succeeded.
test.service: ConditionACPower=|false failed.
test.service: ConditionKernelVersion=>=5.1 succeeded.
test.service: ConditionKernelVersion=!<4.0 succeeded.
Conditions succeeded.
systemd-analyze syscall-filter [ENSEMBLE...]
Cette commande listera tous les appels système contenus dans l'ensemble des appels système indiqué
ENSEMBLE, ou tout ensemble si aucun ensemble n'est spécifié. L'argument ENSEMBLE doit inclure le préfixe
« @ ».
systemd-analyze filesystems [ENSEMBLE...]
Cette commande listera les systèmes de fichiers dans l'ensemble de systèmes de fichiers indiqué ENSEMBLE,
ou tout ensemble connu si aucun ensemble n'est spécifié. L'argument ENSEMBLE doit inclure le préfixe
« @ ».
systemd-analyze calendar EXPRESSION...
Cette commande va analyser et normaliser les événements calendaires répétitifs et calculera la prochaine
échéance. Elle prend la même entrée que le OnCalendar= défini dans systemd.timer(5), en suivant la
syntaxe décrite dans systemd.time(7). Seule la prochaine échéance de l'expression moment calendaire à
survenir est montrée par défaut : utiliser -- iterations= pour afficher le nombre de fois indiqué des
prochaines échéances où l'expression se produira. Chaque moment où l'expression se déroule forme un
horodatage, voir le verbatim timestamp ci-dessous.
Exemple 13. Afficher les jours bissextiles dans un futur proche
$ systemd-analyze calendar --iterations=5 '*-2-29 0:0:0'
Original form: *-2-29 0:0:0
Normalized form: *-02-29 00:00:00
Next elapse: Sat 2020-02-29 00:00:00 UTC
From now: 11 months 15 days left
Iter. #2: Thu 2024-02-29 00:00:00 UTC
From now: 4 years 11 months left
Iter. #3: Tue 2028-02-29 00:00:00 UTC
From now: 8 years 11 months left
Iter. #4: Sun 2032-02-29 00:00:00 UTC
From now: 12 years 11 months left
Iter. #5: Fri 2036-02-29 00:00:00 UTC
From now: 16 years 11 months left
systemd-analyze timestamp HORODATAGE...
Cette commande analyse un horodatage (c'est-à-dire un simple point dans le temps) et renvoie la forme
normalisée et la différence entre cet horodatage et maintenant. L'horodatage doit se conformer à la
syntaxe documentée dans systemd.time(7), section « PARSING TIMESTAMPS » (analyse des horodatages).
Exemple 14. Afficher l'analyse d'horodatages
$ systemd-analyze timestamp yesterday now tomorrow
Original form: yesterday
Normalized form: Mon 2019-05-20 00:00:00 CEST
(in UTC): Sun 2019-05-19 22:00:00 UTC
UNIX seconds: @15583032000
From now: 1 day 9h ago
Original form: now
Normalized form: Tue 2019-05-21 09:48:39 CEST
(in UTC): Tue 2019-05-21 07:48:39 UTC
UNIX seconds: @1558424919.659757
From now: 43us ago
Original form: tomorrow
Normalized form: Wed 2019-05-22 00:00:00 CEST
(in UTC): Tue 2019-05-21 22:00:00 UTC
UNIX seconds: @15584760000
From now: 14h left
systemd-analyze timespan EXPRESSION...
Cette commande analyse un laps de temps (timespan) (c'est-à-dire la différence entre deux horodatages) et
renvoie la forme normalisée et la valeur équivalente en microsecondes. La durée doit se conformer à la
syntaxe documentée dans systemd.time(7), section « PARSING TIME SPANS » (analyse de durées). Les valeurs
sans unité sont analysées comme étant des secondes.
Exemple 15. Afficher l'analyse des durées
$ systemd-analyze timespan 1s 300s '1year 0.000001s'
Original: 1s
μs: 1000000
Human: 1s
Original: 300s
μs: 300000000
Human: 5min
Original: 1year 0.000001s
μs: 31557600000001
Human: 1y 1us
systemd-analyze cat-config NOM|CHEMIN...
Cette commande est similaire à systemctl cat, mais opère sur les fichiers de configuration. Elle copiera
les contenus d'un fichier de configuration et autres bagatelles dans la sortie standard, en utilisant
l'ensemble des répertoires et des règles de priorité habituel de systemd. Chaque argument doit être soit
un chemin absolu incluant le préfixe (tel que /etc/systemd/logind.conf ou /usr/lib/systemd/logind.conf)
ou un nom relatif au préfixe (tel que systemd/logind.conf).
Exemple 16. Afficher la configuration de logind
$ systemd-analyze cat-config systemd/logind.conf
# /etc/systemd/logind.conf
...
[Login]
NAutoVTs=8
...
# /usr/lib/systemd/logind.conf.d/20-test.conf
... quelque dérogation d'un autre paquet
# /etc/systemd/logind.conf.d/50-override.conf
... quelque dérogation d'un administrateur
systemd-analyze compare-versions VERSION1 [OP] VERSION2
Cette commande a deux modes opératoires distincts, selon que l'opérateur OP est spécifié ou non.
Dans le premier mode — lorsque OP n'est pas indiqué —, cette commande comparera les deux chaînes de
version et affichera soit « VERSION1 < VERSION2 », ou « VERSION1 == VERSION2 », ou
« VERSION1 > VERSION2 » en fonction du résultat.
Le code retour est 0 si les versions sont identiques, 11 si la version de droite est plus petite et 12 si
la version de gauche est plus petite (cela correspond à la convention utilisée par rpmdev-vercmp).
Dans le second mode (lorsque OP est indiqué), cette commande comparera les deux chaînes de version en
utilisant l'opération OP et renverra 0 (succès) si les conditions sont satisfaites, et 1 (échec) sinon .
OP peut être it, te, eq, ne, ge, gt. Dans ce mode, aucun retour n'est affiché (cela correspond à la
convention utilisée par dpkg(1) --compare-versions).
Exemple 17. Comparer les versions d'un paquet
$ systemd-analyze compare-versions systemd-250~rc1.fc36.aarch64 systemd-251.fc36.aarch64
systemd-250~rc1.fc36.aarch64 < systemd-251.fc36.aarch64
$ echo $?
$ systemd-analyze compare-versions 1 lt 2; echo $?
0
$ systemd-analyze compare-versions 1 ge 2; echo $?
1
systemd-analyze verify FICHIER...
Cette commande chargera les fichiers d'unité et affichera des avertissements si des erreurs sont
détectées. Les fichiers indiqués sur la ligne de commande seront chargés, mais aussi toute autre unité
référencée par eux. Un nom d'unité sur disque peut être remplacé en spécifiant un alias après un
« deux-points » ; voir ci-dessous pour un exemple. Le chemin de recherche complet de l'unité est formé en
combinant les répertoires de tous les arguments de la ligne de commande et les chemins habituels de
chargement des unités. La variable $SYSTEMD_UNIT_PATH est prise en charge et peut être utilisée pour
remplacer ou augmenter l'ensemble compilé des chemins des unités chargées ; consulter systemd.unit(5).
Tous les fichiers présents dans les répertoires contenant les arguments de ligne de commande seront
utilisés en préférence aux autres chemins. Si une unité modèle n'a pas de nom d'instance indiqué (par
exemple truc@.service), « test_instance » sera utilisé comme nom d'instance, ce dernier pouvant être
contrôlé par l'option --instance=.
Les erreurs suivantes sont souvent détectées :
• instructions et sections inconnues ;
• dépendances nécessaires au démarrage de l'unité donnée manquantes ;
• pages de manuel listées dans Documentation= qui sont introuvables dans le système ;
• commandes listées dans ExecStart= et similaires qui sont introuvables dans le système ou non
exécutables.
Exemple 18. Directives mal écrites
$ cat ./user.slice
[Unit]
WhatIsThis=11
Documentation=man:nosuchfile(1)
Requires=different.service
[Service]
Description=x
$ systemd-analyze verify ./user.slice
[./user.slice:9] Unknown lvalue 'WhatIsThis' in section 'Unit'
[./user.slice:13] Unknown section 'Service'. Ignoring.
Error: org.freedesktop.systemd1.LoadFailed:
Unit different.service failed to load:
No such file or directory.
Failed to create user.slice/start: Invalid argument
user.slice: man nosuchfile(1) command failed with code 16
Exemple 19. Unités de service manquantes
$ tail ./a.socket ./b.socket
==> ./a.socket <==
[Socket]
ListenStream=100
==> ./b.socket <==
[Socket]
ListenStream=100
Accept=yes
$ systemd-analyze verify ./a.socket ./b.socket
Service a.service not loaded, a.socket cannot be started.
Service b@0.service not loaded, b.socket cannot be started.
Exemple 20. Faire un alias d'une unité
$ cat /tmp/source
[Unit]
Description=Hostname printer
[Service]
Type=simple
ExecStart=/usr/bin/echo %H
MysteryKey=true
$ systemd-analyze verify /tmp/source
Failed to prepare filename /tmp/source: Invalid argument
$ systemd-analyze verify /tmp/source:alias.service
alias.service:7: Unknown key name 'MysteryKey' in section 'Service', ignoring.
systemd-analyze security [UNITÉ...]
Cette commande analyse la sécurité et l'ensemble des bacs à sable pour une ou plusieurs unités de
service. Si au moins un nom d'unité est spécifié, les réglages des unités du service spécifiées sont
inspectés et une analyse détaillée est affichée. Si aucun nom d'unité n'est spécifié, toutes les unités
de service chargées et en fonctionnement sont inspectées et un tableau succinct des résultats est
affiché. La commande vérifie différents réglages relatifs à la sécurité du service, assignant à chacun
une valeur de « niveau d'exposition », en fonction de l'importance du réglage. Elle calcule ensuite un
niveau d'exposition global pour l'ensemble de l'unité, qui est une estimation dans l'intervalle de
0.0...10.0 indiquant le degré d'exposition d'un service en matière de sécurité. Des degrés d'exposition
élevés indiquent un « bac à sable » très peu appliqué. Les faibles niveaux d'exposition indiquent une
application du bac à sable serrée et des restrictions de sécurité très strictes. Notez que cette commande
n'analyse que les fonctionnalités de sécurité par service que systemd lui-même met en œuvre. Cela
signifie que tout mécanisme de sécurité supplémentaire appliqué par le code du service lui-même n'est pas
pris en compte. Le niveau d'exposition déterminé de cette manière ne doit pas être mal compris : un haut
niveau d'exposition ne signifie pas qu'il n'y a pas de bac à sable effectif appliqué par le code du
service lui-même, ni que le service est réellement vulnérable à des attaques à distance ou locales. De
hauts niveaux d'exposition indiquent que le service pourrait bénéficier de réglages supplémentaires.
Veuillez prendre en compte que la plupart des réglages individuels pour le bac à sable ou la sécurité
peuvent être contournés — à moins d'être combinés avec d'autres. Par exemple, si un service conserve le
privilège d'établir ou de démonter des points de montage, beaucoup des options du bac à sable peuvent
être défaites par le code du service lui-même. C'est pour cela qu'il est essentiel que chaque service use
de réglages de bac à sable et de sécurité les plus exhaustifs et stricts possibles. L'outil prendra en
compte quelques-unes de ces combinaisons et relations entre les réglages, mais pas toutes. Remarquez
aussi que les réglages de bac à sable et de sécurité analysés ici ne concernent que les opérations faites
par le code du service lui-même. Si un service a accès à un système IPC (tel que D-Bus), il pourrait
nécessiter des opérations de la part d'autres services qui ne sont pas astreints aux mêmes restrictions.
Toute analyse exhaustive de bac à sable et de sécurité est donc incomplète si la politique d'accès IPC
n'est pas aussi validée.
Exemple 21. Analyser systemd-logind.service
$ systemd-analyze security --no-pager systemd-logind.service
NAME DESCRIPTION EXPOSURE
✗ PrivateNetwork= Service has access to the host's network 0.5
✗ User=/DynamicUser= Service runs as root user 0.4
✗ DeviceAllow= Service has no device ACL 0.2
✓ IPAddressDeny= Service blocks all IP address ranges
...
→ Overall exposure level for systemd-logind.service: 4.1 OK 🙂
systemd-analyze inspect-elf FICHIER...
Cette commande charge les fichiers spécifiés et, s'ils sont des objets ELF (exécutables, bibliothèques,
fichier core, etc.), elle analysera les métadonnées d'empaquetage incorporées, si présentes et les
affichera dans une table ou au format json. Voir la documentation Packaging Metadata[1] pour plus
d'information.
Exemple 22. Afficher les informations d'un fichier core au format JSON
$ systemd-analyze inspect-elf --json=pretty \
core.fsverity.1000.f77dac5dc161402aa44e15b7dd9dcf97.58561.1637106137000000
{
"elfType" : "coredump",
"elfArchitecture" : "AMD x86-64",
"/home/bluca/git/fsverity-utils/fsverity" : {
"type" : "deb",
"name" : "fsverity-utils",
"version" : "1.3-1",
"buildId" : "7c895ecd2a271f93e96268f479fdc3c64a2ec4ee"
},
"/home/bluca/git/fsverity-utils/libfsverity.so.0" : {
"type" : "deb",
"name" : "fsverity-utils",
"version" : "1.3-1",
"buildId" : "b5e428254abf14237b0ae70ed85fffbb98a78f88"
}
}
systemd-analyze fdstore UNITÉ...
Cette commande liste les contenus actuels du magasin de descripteurs de fichier de l'unité de service
spécifiée et affiche les noms, les types d'inœud, les numéros de périphérique, les numéros d'inœud, les
chemins et les modes d'ouverture des descripteurs de fichier ouverts. Les unités indiquées doivent avoir
FileDescriptorStoreMax= activé ; consultez systemd.service(5) pour les détails.
Exemple 23. Sortie sous forme de table
$ systemd-analyze fdstore systemd-journald.service
FDNAME TYPE DEVNO INODE RDEVNO PATH FLAGS
stored sock 0:8 4218620 - socket:[4218620] ro
stored sock 0:8 4213198 - socket:[4213198] ro
stored sock 0:8 4213190 - socket:[4213190] ro
...
Remarque : la colonne « DEVNO » désigne les numéros majeur/mineur du nœud du périphérique associé au
système de fichiers dans lequel se trouve le nœud du descripteur de fichier. La colonne « RDEVNO »
désigne les numéros majeur/mineur du nœud du périphérique lui-même, si le descripteur de fichier s'y
réfère. Comparer avec les champs correspondants à .st_dev et .st_rdev dans struct stat (voir stat(2) pour
les détails). Les numéros d'inœuds de la colonne « INODE » sont sur le système de fichiers indiqué par
« DEVNO ».
systemd-analyze image-policy POLITIQUE...
Cette commande analyse la chaîne de politique de l'image indiquée, comme pour systemd.image-policy(7).
Cette politique est normalisée et simplifiée. Pour chaque identifiant de partition défini actuellement
(comme pour la Spécification des Partitions Détectables[2]) l'effet de la chaîne de politique de l'image
est affiché sous la forme de tableau.
Exemple 24. Exemple de sortie
$ systemd-analyze image-policy swap=encrypted:usr=read-only-on+verity:root=encrypted
Analyzing policy: root=encrypted:usr=verity+read-only-on:swap=encrypted
Long form: root=encrypted:usr=verity+read-only-on:swap=encrypted:=unused+absent
PARTITION MODE READ-ONLY GROWFS
root encrypted - -
usr verity yes -
home ignore - -
srv ignore - -
esp ignore - -
xbootldr ignore - -
swap encrypted - -
root-verity ignore - -
usr-verity unprotected yes -
root-verity-sig ignore - -
usr-verity-sig ignore - -
tmp ignore - -
var ignore - -
default ignore - -
systemd-analyze has-tpm2
Indique si le système est équipé d'un périphérique TPM2 utilisable. Si un périphérique TPM2 a été
découvert, qu'il est pris en charge et utilisé par le micrologiciel, par les pilotes du noyau du système
d'exploitation et par l'espace utilisateur (c'est-à-dire systemd), cette commande affiche « yes » et
quitte avec un code de retour de zéro. Si aucun périphérique n'est découvert/pris en charge/utilisé,
« no » s'affiche. Sinon, « partial » est affiché. Dans les deux cas, la sortie est un code retour
différent de zéro. Cette commande montre aussi cinq lignes indiquant séparément si le micrologiciel, les
pilotes, le système, le noyau et les bibliothèques ont découvert/géré/utilisé TPM2. Actuellement, les
bibliothèques requises sont libtss2-esys.so.0, libtss2-rc.so.0 et libtss2-mu.so.0. Ces prérequis pourront
changer dans le futur.
Notez que cela ne vérifie que les périphériques TPM 2.0, et ignore totalement les périphériques TPM 1.2.
Combiner avec --quiet pour supprimer la sortie.
Exemple 25. Exemple de sortie
yes
+firmware
+driver
+system
+subsystem
+libraries
+libtss2-esys.so.0
+libtss2-rc.so.0
+libtss2-mu.so.0
Ajouté dans la version 257.
systemd-analyze pcrs [PCR...]
Cette commande affiche les PCR TPM2 connus avec leurs noms d’identification et leurs valeurs actuelles.
Exemple 26. Exemple de sortie
$ systemd-analyze pcrs
NR NAME SHA256
0 platform-code bcd2eb527108bbb1f5528409bcbe310aa9b74f687854cc5857605993f3d9eb11
1 platform-config b60622856eb7ce52637b80f30a520e6e87c347daa679f3335f4f1a600681bb01
2 external-code 1471262403e9a62f9c392941300b4807fbdb6f0bfdd50abfab752732087017dd
3 external-config 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
4 boot-loader-code 939f7fa1458e1f7ce968874d908e524fc0debf890383d355e4ce347b7b78a95c
5 boot-loader-config 864c61c5ea5ecbdb6951e6cb6d9c1f4b4eac79772f7fe13b8bece569d83d3768
6 - 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
7 secure-boot-policy 9c905bd9b9891bfb889b90a54c4b537b889cfa817c4389cc25754823a9443255
8 - 0000000000000000000000000000000000000000000000000000000000000000
9 kernel-initrd 9caa29b128113ef42aa53d421f03437be57211e5ebafc0fa8b5d4514ee37ff0c
10 ima 5ea9e3dab53eb6b483b6ec9e3b2c712bea66bca1b155637841216e0094387400
11 kernel-boot 0000000000000000000000000000000000000000000000000000000000000000
12 kernel-config 627ffa4b405e911902fe1f1a8b0164693b31acab04f805f15bccfe2209c7eace
13 sysexts 0000000000000000000000000000000000000000000000000000000000000000
14 shim-policy 0000000000000000000000000000000000000000000000000000000000000000
15 system-identity 0000000000000000000000000000000000000000000000000000000000000000
16 debug 0000000000000000000000000000000000000000000000000000000000000000
17 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
18 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
19 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
20 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
21 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
22 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
23 application-support 0000000000000000000000000000000000000000000000000000000000000000
systemd-analyze srk [>FICHIER]
Cette commande lit la clé racine de stockage (SRK) du dispositif TPM2 et l'écrit au format TPM2B_PUBLIC
sérialisée sur la sortie. La sortie est une donnée non imprimable, et devrait donc être redirigée dans un
fichier ou un tube.
Exemple 27. Sauvegarder la clef racine de stockage (Storage Root Key) dans srk.tpm2b_public
systemd-analyze srk >srk.tpm2b_public
systemd-analyze architectures [NOM...]
Lister toutes les architectures connues de CPU et lesquelles sont natives. Les noms d'architectures
listées sont ceux pris en charge par ConditionArchitecture=, voir systemd.unit(5) pour les détails. Si
des noms d'architectures sont spécifiés, seuls ceux indiqués sont listés.
Exemple 28. Sortie sous forme de table
$ systemd-analyze architectures
NAME SUPPORT
alpha foreign
arc foreign
arc-be foreign
arm foreign
arm64 foreign
...
sparc foreign
sparc64 foreign
tilegx foreign
x86 secondary
x86-64 native
systemd-analyze smbios11
Afficher une liste des chaînes SMBIOS Type #11 passées au système. Consultez aussi smbios-type-11(7).
Exemple 29. Exemple de sortie
$ systemd-analyze smbios11
io.systemd.stub.kernel-cmdline-extra=console=ttyS0
io.systemd.credential.binary:ssh.ephemeral-authorized_keys-all=c3NoLWVkMjU1MTkgQUFBQUMzTnphQzFsWkRJMU5URTVBQUFBSURGd20xbFp4WlRGclJteG9ZQlozOTYzcE1uYlJCaDMwM1MxVXhLSUM2NmYgbGVubmFydEB6ZXRhCg==
io.systemd.credential:vmm.notify_socket=vsock-stream:2:254570042
3 SMBIOS Type #11 strings passed.
Ajouté dans la version 257.
OPTIONS
Les options suivantes sont comprises :
--system
Agir sur l'instance systemd du système. C'est l'option implicite par défaut.
Ajouté dans la version 206.
--user
Agir sur l'instance systemd de l'utilisateur.
Ajouté dans la version 186.
--global
Agir sur la configuration de l'ensemble du système pour l'instance systemd de l'utilisateur.
Ajouté dans la version 238.
--order, --require
Ces options sélectionnent quelles dépendances seront montrées dans le graphe de dépendances,
lorsqu'utilisées conjointement à la commande dot (voir ci-dessus). Si --order est passée, seules les
dépendances du type After= ou Before= sont affichées. Si --require est passée, seules les dépendances
du type Requires=, Requisite=, BindsTo=, Wants= et Conflicts= sont affichées. Si aucune n'est passée,
les dépendances de tous ces types seront affichées.
Ajouté dans la version 198.
--from-pattern=, --to-pattern=
Ces options sélectionnent quelles relations sont montrées dans le graphe de dépendances
lorsqu'utilisées avec la commande dot (voir ci-dessus). Les deux options nécessitent un motif glob(7)
comme argument qui sera comparé au côté droit et au côté gauche, respectivement, des nœuds de la
relation.
Chacune d'elles peut être utilisée plus d'une fois, auquel cas le nom de l'unité doit correspondre à
l'une de ces valeurs. Une relation doit passer les deux tests pour être affichée lorsque les tests
pour les deux côtés de la relation sont présents. Quand les motifs sont aussi spécifiés comme
argument de position, ils doivent correspondre a minima à l'un des côtés de la relation. En d'autres
termes, les motifs indiqués dans ces deux options réduiront la liste des extrémités correspondant aux
arguments de position, s'il y en a de donnés, et détermineront totalement la liste des extrémités qui
seront affichées sinon.
Ajouté dans la version 201.
--fuzz=durée
Lorsqu'utilisée conjointement avec la commande critical-chain (voir ci-dessus), cette option montrera
aussi les unités qui ont fini leur durée avant la dernière unité sur le même niveau. L'unité de la
durée est la seconde, à moins qu'une unité différente soit spécifiée, par exemple « 50ms ».
Ajouté dans la version 203.
--man=no
Ne pas invoquer man(1) pour vérifier la présence de pages de manuel listées dans Documentation=.
Ajouté dans la version 235.
--generators
Invoquer les générateurs d'unités, consulter systemd.generator(7). Certains générateurs nécessitent
les privilèges du superutilisateur. Fonctionner avec les générateurs activés en tant qu'utilisateur
normal résultera en général en plusieurs avertissements.
Ajouté dans la version 235.
--instance=NOM
Indiquer un nom d'instance de secours pour les unités modèle. À utiliser lorsqu’une ou plusieurs
unités modèle sans nom d'instance (par exemple truc@.service) sont indiquées par systemd-analyze
condition avec --unit=, systemd-analyze security et systemd-analyze verify. Si non indiqué,
« test_instance » sera utilisé.
Ajouté dans la version 257.
--recursive-errors=MODE
Contrôler la vérification des unités et leurs dépendances et si systemd-analyze verify finit avec un
code de retour différent de zéro ou pas. Avec yes, renvoyer un code de retour de processus différent
de zéro lorsque des avertissements surviennent pendant la vérification de l'unité spécifiée ou de
l'une de ses dépendances associées. Avec no, renvoyer un code de retour de processus différent de
zéro lorsque des avertissements surviennent durant la vérification de l'unité spécifiée uniquement.
Avec one, renvoyer un code de retour de processus différent de zéro lorsque des avertissements
surviennent lors de la vérification de l'unité indiquée ou de ses dépendances immédiates. Si cette
option n'est pas spécifiée, zéro est renvoyé comme code de retour, que des avertissements surviennent
ou pas lors de la vérification.
Ajouté dans la version 250.
--root=CHEMIN
Avec cat-config, verify, condition et security lorsqu'utilisés avec --offline=, opérer sur les
fichiers sous le chemin racine spécifié CHEMIN.
Ajouté dans la version 239.
--image=CHEMIN
Avec cat-config, verify, condition et security lorsqu'utilisés avec --offline=, opérer sur les
fichiers dans le chemin d'image spécifié CHEMIN.
Ajouté dans la version 250.
--image-policy=politique
Cette option prend pour argument une image de chaine de politique, comme pour
systemd.image-policy(7). La politique est imposée lors d'une opération sur l'image disque indiquée
par --image=, voir ci-dessus. C'est par défaut la politique « * » si rien n'est indiqué, c'est-à-dire
tous les systèmes de fichiers reconnus de l'image sont utilisés.
--offline=BOOL
Avec security, effectuer un audit de sécurité hors-ligne des fichiers d'unité spécifiés, c'est-à-dire
ne pas dépendre du PID 1 pour avoir des informations de sécurité sur les fichiers de la même façon
que la commande security lorsqu'utilisée seule. Cela signifie que --offline= peut être utilisée aussi
bien avec --root= qu'avec --image=. Si le niveau d'exposition global d'une unité est plus élevé que
ce qui est défini par --threshold= (dont la valeur par défaut est 100), --offline= enverra une
erreur.
Ajouté dans la version 250.
--profile=CHEMIN
Avec security --offline=, prend en considération le profil portable indiqué lors de l'accession aux
réglages de l'unité. Le profil peut être passé sous la forme d'un nom, auquel cas son emplacement
connu sur le système sera cherché, ou il peut être un chemin complet vers un fichier de remplacement
spécifique.
Ajouté dans la version 250.
--threshold=NOMBRE
Avec security, autorise l'utilisateur à définir une valeur personnalisée à comparer au niveau
d'exposition global pour les fichiers d'unité indiqués. Si le niveau d'exposition global d'une unité
est supérieur à ce qui a été défini par l'utilisateur, security renverra une erreur. --threshold=
peut aussi être utilisé avec --offline= et sa valeur par défaut est 100.
Ajouté dans la version 250.
--security-policy=CHEMIN
Avec security, permettre à l'utilisateur de définir un ensemble personnalisé d'exigences formatées
comme un fichier JSON auquel comparer le(s) fichier(s) d'unité spécifié(s) et déterminer leur niveau
d'exposition global aux menaces de sécurité.
Table 1. Identificateurs de test d'évaluation acceptés
┌──────────────────────────────────────────────────────────┐
│ Identificateurs de test d'évaluation │
├──────────────────────────────────────────────────────────┤
│ UserOrDynamicUser │
├──────────────────────────────────────────────────────────┤
│ SupplementaryGroups │
├──────────────────────────────────────────────────────────┤
│ PrivateMounts │
├──────────────────────────────────────────────────────────┤
│ PrivateDevices │
├──────────────────────────────────────────────────────────┤
│ PrivateTmp │
├──────────────────────────────────────────────────────────┤
│ PrivateNetwork │
├──────────────────────────────────────────────────────────┤
│ PrivateUsers │
├──────────────────────────────────────────────────────────┤
│ ProtectControlGroups │
├──────────────────────────────────────────────────────────┤
│ ProtectKernelModules │
├──────────────────────────────────────────────────────────┤
│ ProtectKernelTunables │
├──────────────────────────────────────────────────────────┤
│ ProtectKernelLogs │
├──────────────────────────────────────────────────────────┤
│ ProtectClock │
├──────────────────────────────────────────────────────────┤
│ ProtectHome │
├──────────────────────────────────────────────────────────┤
│ ProtectHostname │
├──────────────────────────────────────────────────────────┤
│ ProtectSystem │
├──────────────────────────────────────────────────────────┤
│ RootDirectoryOrRootImage │
├──────────────────────────────────────────────────────────┤
│ LockPersonality │
├──────────────────────────────────────────────────────────┤
│ MemoryDenyWriteExecute │
├──────────────────────────────────────────────────────────┤
│ NoNewPrivileges │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_SYS_ADMIN │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_SET_UID_GID_PCAP │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_SYS_PTRACE │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_SYS_TIME │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_NET_ADMIN │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_SYS_RAWIO │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_SYS_MODULE │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_AUDIT │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_SYSLOG │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_SYS_NICE_RESOURCE │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_MKNOD │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_CHOWN_FSETID_SETFCAP │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_DAC_FOWNER_IPC_OWNER │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_KILL │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_NET_BIND_SERVICE_BROADCAST_RAW │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_SYS_BOOT │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_MAC │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_LINUX_IMMUTABLE │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_IPC_LOCK │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_SYS_CHROOT │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_BLOCK_SUSPEND │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_WAKE_ALARM │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_LEASE │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_SYS_TTY_CONFIG │
├──────────────────────────────────────────────────────────┤
│ CapabilityBoundingSet_CAP_BPF │
├──────────────────────────────────────────────────────────┤
│ UMask │
├──────────────────────────────────────────────────────────┤
│ KeyringMode │
├──────────────────────────────────────────────────────────┤
│ ProtectProc │
├──────────────────────────────────────────────────────────┤
│ ProcSubset │
├──────────────────────────────────────────────────────────┤
│ NotifyAccess │
├──────────────────────────────────────────────────────────┤
│ RemoveIPC │
├──────────────────────────────────────────────────────────┤
│ Delegate │
├──────────────────────────────────────────────────────────┤
│ RestrictRealtime │
├──────────────────────────────────────────────────────────┤
│ RestrictSUIDSGID │
├──────────────────────────────────────────────────────────┤
│ RestrictNamespaces_user │
├──────────────────────────────────────────────────────────┤
│ RestrictNamespaces_mnt │
├──────────────────────────────────────────────────────────┤
│ RestrictNamespaces_ipc │
├──────────────────────────────────────────────────────────┤
│ RestrictNamespaces_pid │
├──────────────────────────────────────────────────────────┤
│ RestrictNamespaces_cgroup │
├──────────────────────────────────────────────────────────┤
│ RestrictNamespaces_uts │
├──────────────────────────────────────────────────────────┤
│ RestrictNamespaces_net │
├──────────────────────────────────────────────────────────┤
│ RestrictAddressFamilies_AF_INET_INET6 │
├──────────────────────────────────────────────────────────┤
│ RestrictAddressFamilies_AF_UNIX │
├──────────────────────────────────────────────────────────┤
│ RestrictAddressFamilies_AF_NETLINK │
├──────────────────────────────────────────────────────────┤
│ RestrictAddressFamilies_AF_PACKET │
├──────────────────────────────────────────────────────────┤
│ RestrictAddressFamilies_OTHER │
├──────────────────────────────────────────────────────────┤
│ SystemCallArchitectures │
├──────────────────────────────────────────────────────────┤
│ SystemCallFilter_swap │
├──────────────────────────────────────────────────────────┤
│ SystemCallFilter_obsolete │
├──────────────────────────────────────────────────────────┤
│ SystemCallFilter_clock │
├──────────────────────────────────────────────────────────┤
│ SystemCallFilter_cpu_emulation │
├──────────────────────────────────────────────────────────┤
│ SystemCallFilter_debug │
├──────────────────────────────────────────────────────────┤
│ SystemCallFilter_mount │
├──────────────────────────────────────────────────────────┤
│ SystemCallFilter_module │
├──────────────────────────────────────────────────────────┤
│ SystemCallFilter_raw_io │
├──────────────────────────────────────────────────────────┤
│ SystemCallFilter_reboot │
├──────────────────────────────────────────────────────────┤
│ SystemCallFilter_privileged │
├──────────────────────────────────────────────────────────┤
│ SystemCallFilter_resources │
├──────────────────────────────────────────────────────────┤
│ IPAddressDeny │
├──────────────────────────────────────────────────────────┤
│ DeviceAllow │
├──────────────────────────────────────────────────────────┤
│ AmbientCapabilities │
└──────────────────────────────────────────────────────────┘
Voir l'exemple « JSON Policy » ci-dessous.
Ajouté dans la version 250.
--json=MODE
Avec la commande security, générer une sortie formatée JSON de la table d'analyse de sécurité. Le
format est un tableau JSON avec des objets contenant les champs suivants : réglage qui indique si le
réglage est activé ou pas, nom qui est ce qui est utilisé pour se référer au réglage, champ_json qui
est l'identifiant compatible JSON du réglage, description qui est un aperçu de l'état du réglage et
exposition qui est un nombre dans l'intervalle de 0.0...10.0, où une valeur haute correspond à une
menace de sécurité élevée. La version JSON de la table est affichée dans la sortie standard. Le MODE
passé à l'option peut être l'un des trois suivants : off la valeur par défaut, pretty et short qui
renvoient respectivement une version enjolivée ou courte de la version JSON de la table de sécurité.
Avec la commande plot, générer une sortie formatée JSON des données horaires brutes. Le format est un
tableau JSON avec des objets contenant les champs suivant : nom qui est le nom de l'unité, activated
qui est le temps mis par le service pour être activé après le démarrage, activating qui est le temps
mis par le service pour être initialement lancé après le démarrage, time qui est le temps mis par le
service pour s'activer à partir du moment où il a été démarré initialement, desactivated qui est le
temps mis par le service pour se désactiver après le démarrage, desactivating qui est le temps après
lequel il a été initialement demandé au service de se désactiver après le démarrage.
Ajouté dans la version 250.
--iterations=NOMBRE
Lorsqu'utilisée avec la commande calendar, cette option affiche le nombre spécifique d'itérations de
prochaines échéances de l'expression calendaire indiquée. La valeur par défaut est 1.
Ajouté dans la version 242.
--base-time=HORODATAGE
Lorsqu'utilisée avec la commande calendar, cette option affiche les prochaines itérations relatives à
un moment indiqué. Si rien n'est spécifié, ce sera l'heure actuelle par défaut.
Ajouté dans la version 244.
--unit=UNITÉ
Lorsqu'utilisée avec la commande condition, cette option permet d'évaluer toutes les assignations
Condition*=... et Assert*=... dans le fichier de l'unité indiquée. Le chemin complet de recherche de
l'unité est formé en combinant les répertoires de l'unité indiquée avec les chemins habituels de
chargement des unités. La variable $SYSTEMD_UNIT_PATH est prise en charge et peut être utilisée pour
remplacer ou augmenter l'ensemble compilé des chemins de chargement des unités ; consulter
systemd.unit(5). Tous les fichiers d'unités présents dans le répertoire contenant l'unité indiquée
seront utilisés de préférence aux autres chemins. Si une unité modèle sans nom d'instance est
indiquée (par exemple truc@.service), « test_instance » sera utilisé comme nom d'instance, ce dernier
pouvant être contrôlé par l'option --instance=.
Ajouté dans la version 250.
--table
Lorsqu'utilisée avec la commande plot, la sortie des données horaires brutes s'affiche sous la forme
d'un tableau.
Ajouté dans la version 253.
--no-legend
Lorsqu'utilisé avec la commande plot combinée avec soit --table ou --json=, aucune légende ou
indication ne sont inclues dans la sortie.
Ajouté dans la version 253.
-H, --host=
Effectuer l'opération à distance. Indiquer un nom d'hôte, ou un nom d'utilisateur et un nom d'hôte
séparés par un « @ », auquel se connecter. Le nom d'hôte peut, de façon optionnelle, être suffixé par
un port sur lequel ssh écoute, séparé par un « : », puis le nom d'un conteneur, séparé par un « / »,
ce qui connecte alors directement à un conteneur donné sur l'hôte spécifié. SSH sera utilisé pour
dialoguer avec l’instance du gestionnaire de la machine distante. Les noms de conteneur peuvent être
énumérés avec machinectl -H HÔTE. Mettre les adresses IPv6 entre crochets.
-M, --machine=
Effectuer l'opération dans un conteneur local. Préciser le nom d'un conteneur auquel se connecter,
optionnellement préfixé par le nom d'utilisateur sous lequel se connecter et un caractère de
séparation « @ ». Si la chaîne spéciale « .host » est utilisée à la place du nom du conteneur, une
connexion au système local se produit (ce qui est utile pour se connecter au bus utilisateur d'un
utilisateur particulier : « --user --machine=lennart@.host »). Si la syntaxe « @ » n'est pas
utilisée, la connexion est réalisée en tant que superutilisateur. Si la syntaxe « @ » est utilisée,
le côté gauche ou le côté droit peuvent être omis (mais pas les deux à la fois), auquel cas le nom de
l'utilisateur local et « .host » sont implicites.
-q, --quiet
Supprimer les notes et sorties non essentielles.
Ajouté dans la version 250.
--tldr
Avec cat-config, n'afficher que les parties « intéressantes » des fichiers de configuration, sauter
les commentaires et les lignes vides ainsi que les en-têtes de section suivis uniquement de
commentaires et de lignes vides.
Ajouté dans la version 255.
--scale-svg=FACTEUR
Lorsque utilisée avec la commande plot, l'axe des x du tracé peut être étiré par FACTEUR (par
défaut : 1.0).
Ajouté dans la version 257.
--detailed
Lorsque utilisée avec la commande plot, les détails des horodatages d'activation peuvent être
observés dans le tracé SVG.
Ajouté dans la version 257.
-h, --help
Afficher un aide-mémoire succinct et quitter.
--version
Afficher une information de version courte et quitter.
--no-pager
Ne pas rediriger (pipe) la sortie vers un afficheur (pager).
CODE DE RETOUR
Pour la plupart des commandes, 0 est renvoyé en cas de succès et un code d'échec différent de zéro sinon.
Avec le verbatim compare-versions sous la forme de deux arguments, 12, 0 ou 11 est renvoyé si la seconde
chaîne de version est respectivement plus grande, égale ou plus petite que la première. Sous la forme de
trois arguments, 0 ou 1 est renvoyé si la condition est respectivement vraie ou fausse.
La commande has-tpm2 renvoie 0 si un périphérique TPM2 est découvert, géré et utilisé par le
micrologiciel, le pilote et l'espace utilisateur (c'est-à-dire systemd). Sinon, elle renvoie un OU
logique de la valeur 1 (dans le cas où la prise en charge du micrologiciel est manquante), 2 (prise en
charge du pilote manquante) et 4 (prise en charge de l'espace utilisateur manquante). Si aucune prise en
charge TPM2 n'est disponible, une valeur de 7 est renvoyée.
ENVIRONNEMENT
$SYSTEMD_LOG_LEVEL
Le niveau maximal de journalisation de messages émis (messages avec un niveau de journalisation
supérieur, c'est-à-dire les moins importants seront supprimés). Cette variable prend une liste de
valeurs séparées par des virgules. Une valeur peut être (par ordre d'importance décroissante) emerg,
alert, crit, err, warning, notice, info, debug ou un entier dans l’intervalle 0...7. Consultez
syslog(3) pour davantage d'informations. Chaque valeur peut être optionnellement préfixée avec
console, syslog, kmsg ou journal suivi d'un deux-points (:) pour définir le niveau de journalisation
maximal pour la cible spécifique de journal (par exemple SYSTEMD_LOG_LEVEL=debug,console:info indique
de journaliser au niveau debug excepté pour la journalisation vers la console qui doit s'effectuer au
niveau info). Notez que le niveau maximal de journalisation globale est prioritaire sur tout niveau
maximal de journalisation par cible.
$SYSTEMD_LOG_COLOR
Un booléen. Si la valeur est vrai, les messages écrits sur le terminal seront colorés selon la
priorité.
Ce réglage est utile uniquement quand les messages sont écrits directement dans un terminal ou un
fichier parce que journalctl(1) et d'autres outils qui affichent des journaux coloreront par
eux-mêmes les messages selon le niveau de journalisation.
$SYSTEMD_LOG_TIME
Un booléen. Si la valeur est vrai, les messages du journal de la console seront préfixés d'un
horodatage.
Ce réglage est utile uniquement quand les messages sont écrits directement dans un terminal ou un
fichier parce que journalctl(1) et d'autres outils qui affichent des journaux attacheront par
eux-mêmes un horodatage selon les métadonnées de l'entrée.
$SYSTEMD_LOG_LOCATION
Un booléen. Si la valeur est vrai, les messages seront préfixés par un nom de fichier et du numéro de
ligne du code source d'où vient le message.
Notez que l'emplacement du journal est souvent attaché comme métadonnée aux entrées du journal de
toute façon. L'inclure directement dans le texte du message peut néanmoins être opportun lors du
débogage de programmes.
$SYSTEMD_LOG_TID
Un booléen. Si la valeur est vrai, les messages seront préfixés par l'identifiant numérique du thread
actuel (TID).
Notez que cette information est attachée comme métadonnée aux entrées du journal de toute façon.
L'inclure directement dans le texte du message peut néanmoins être opportun lors du débogage de
programmes.
$SYSTEMD_LOG_TARGET
Destination pour journaliser les messages. Une des destinations parmi console (journaliser dans le
terminal attaché), console-prefixed (journaliser dans le terminal attaché, mais avec des préfixes qui
codent le niveau et le « service » de journalisation, consultez syslog(3)), kmsg (journaliser dans le
tampon de journalisation circulaire du noyau), journal (journaliser dans le journal), journal-or-kmsg
(journaliser dans le journal s'il est disponible et sinon dans kmsg), auto (déterminer
automatiquement la cible appropriée de journalisation, c'est la destination par défaut), null
(désactive la sortie de journalisation).
$SYSTEMD_LOG_RATELIMIT_KMSG
Que ce soit pour le taux de requête kmsg ou pas. Prend un booléen. Par défaut « true ». Si désactivé,
systemd ne limitera pas le taux des messages écrits à kmsg.
$SYSTEMD_PAGER, $PAGER
Afficheur à utiliser lorsque --no-pager n'est pas précisé. $SYSTEMD_PAGER est utilisé s'il est
défini ; autrement, $PAGERest utilisé. Si ni $SYSTEMD_PAGER, ni $PAGER n'ont de valeur, un ensemble
d’afficheurs bien connus sont essayés à tour de rôle, incluant less(1) et more(1), jusqu'à ce qu'il y
en ait un qui soit trouvé. Si aucun afficheur n'est trouvé, aucun afficheur n'est appelé. Définir ces
variables d'environnement à une chaîne vide ou à « cat » est équivalent à l'utilisation de
--no-pager.
Remarque : si $SYSTEMD_PAGERSECURE n'est pas défini, $SYSTEMD_PAGER et $PAGER ne peuvent être
utilisés que pour désactiver l'afficheur (avec « cat » ou « "" ») et autrement seront ignorés.
$SYSTEMD_LESS
Outrepasser les options passées à less (par défaut « FRSXMK »).
Les utilisateurs voudront peut-être changer deux options en particulier :
K
Cette option ordonne à l’afficheur de quitter immédiatement lorsque Ctrl+C est entré. Pour
permettre à less de gérer Ctrl+C lui-même le retour à l'invite de commande de l’afficheur, ne pas
fournir cette option.
Si la valeur de $SYSTEMD_LESS n'inclut pas « K » et si l’afficheur appelé est less, Ctrl+C sera
ignoré par l'exécutable et doit être géré par l’afficheur.
X
Cette option ordonne à l’afficheur de ne pas envoyer les chaînes d'initialisation et de
désinitialisation de termcap au terminal. C'est le choix par défaut afin de permettre aux sorties
des commandes de rester visibles dans le terminal même après que l’afficheur soit fermé.
Toutefois, cela empêche quelques fonctionnalités de l’afficheur de fonctionner, en particulier,
il n'est pas possible de faire défiler les sorties affichées avec la souris.
Notez que le réglage de la variable d'environnement $LESS normale n'a aucun effet sur les invocations
de less par les outils de systemd.
Voir less(1) pour plus de détails.
$SYSTEMD_LESSCHARSET
Outrepasser le jeu de caractères passé à less (par défaut « utf-8 », si le terminal invoqué est
compatible avec l'UTF-8).
Notez que le réglage de la variable d'environnement $LESSCHARSET normale n'a aucun effet sur les
invocations de less par les outils de systemd.
$SYSTEMD_PAGERSECURE
Les commandes d'afficheur courantes comme less(1), en plus de « l'affichage », c'est-à-dire le
défilement de la sortie, prennent en charge l'ouverture et l'écriture d'autres fichiers et
l'exécution de commandes d'interpréteur arbitraires. Quand les commandes sont invoquées avec des
privilèges élevés, par exemple sous sudo(8) ou pkexec(1), l'afficheur devient une limite de sécurité.
Il convient de veiller à ce que seuls des programmes avec des fonctionnalités strictement limitées
soient utilisés comme afficheurs et que les fonctionnalités comme l'ouverture ou la création de
nouveaux fichiers ou le démarrage de sous-processus ne soient pas autorisées. Un « mode sécurisé »
pour l'afficher peut être activé comme décrit ci-dessous, si l'afficheur le prend en charge≤ (la
plupart des afficheurs ne sont pas écrits de façon à prendre cela en considération). Il est
recommandé soit d'activer explicitement le « mode sécurisé » soit de désactiver complètement
l'afficheur en utilisant --no-pager ou PAGER=cat lorsque des utilisateurs non fiables sont autorisés
à exécuter des commandes avec des privilèges élevés.
Cette option prend un argument booléen. Lorsqu'elle est définie à vrai, le « mode sécurisé » de
l'afficheur est activé. En « mode sécurisé », LESSSECURE=1 est défini lors de l'invocation de
l'afficheur, ce qui lui indique de désactiver les commandes qui ouvrent ou créent des fichiers, ou
qui démarrent un nouveau sous-processus. Actuellement, seul less(5) est connu pour comprendre cette
variable et implémenter le « mode sécurisé ».
Quand l'option est définie à faux, aucune limitation n'est imposée à l'afficheur. Définir
SYSTEMD_PAGERSECURE=0 ou ne pas le supprimer de l'environnement hérité peut permettre à l'utilisateur
d'invoquer des commandes arbitraires.
Quand $SYSTEMD_PAGERSECURE n'est pas défini, les outils de systemd tentent de déterminer
automatiquement si le « mode sécurisé » doit être activé et si l'afficheur le prend en charge. Le
« mode sécurisé » est activé si l'UID effectif est différent de celui du propriétaire de la session
de connexion (voir geteuid(2)) et sd_pid_get_owner_uid(3)) ou lors de l'exécution sous sudo(8) ou des
outils similaires ($SUDO_UID est défini à [3]). Dans ces cas, SYSTEMD_PAGERSECURE=1 sera défini et
les afficheurs qui ne sont pas connus pour implémenter le « mode sécurisé » ne seront pas du tout
utilisés. Notez que cette détection automatique ne couvre que les mécanismes les plus courants
d'élévation des privilèges et qu'elle est conçue pour faciliter la tâche. Il est recommandé de
définir explicitement $SYSTEMD_PAGERSECURE ou de désactiver l'afficheur.
Notez que si les variables $SYSTEMD_PAGER ou $PAGER doivent être respectées, sauf pour désactiver
l'afficheur, $SYSTEMD_PAGERSECURE doit aussi être défini.
$SYSTEMD_COLORS
Prend un argument booléen. Quand c'est « vrai », systemd et les utilitaires liés utiliseront la
couleur pour leurs sorties, autrement, la sortie sera monochrome. En plus, la variable peut prendre
une des valeurs spéciales suivantes : 16 ou 256 pour limiter l'usage des couleurs aux couleurs ANSI
base 16 ou base 256 respectivement. Cela peut être précisé pour outrepasser la décision automatique
prise sur $TERM et quel que soit ce à quoi la console est connectée.
$SYSTEMD_URLIFY
La valeur doit être un booléen. Contrôle si les liens cliquables doivent être générés dans la sortie
pour des émulateurs de terminaux le prenant en charge. Cela peut être indiqué pour passer outre la
décision faite par systemd basée sur $TERM et d'autres conditions.
EXEMPLES
Exemple 30. Politique JSON
Le fichier JSON passé comme paramètre de chemin à --security-policy= a un objet JSON de haut niveau dont
les clés sont les identifiants des tests d'évaluation mentionnés ci-dessus. Les valeurs dans le fichier
doivent être des objets JSON avec un ou plusieurs des champs suivants : description_na (chaîne),
description_good (chaîne), description_bad (chaîne), weight (entier non signé) et range (entier non
signé). Si l'un de ces champs correspondant à un identifiant spécifique d'un fichier d'unité est manquant
dans l'objet JSON, la valeur du champ interne par défaut correspondant à ce même identifiant est utilisée
comme valeur par défaut pour l'analyse de sécurité. Les champs weight et range sont utilisés pour
déterminer le niveau d'exposition global des fichiers de l'unité : un score de médiocrité est assigné
comme valeur à chaque réglage, qui est multiplié par le poids de la politique et divisé par la plage de
politique pour déterminer l'exposition globale que ce réglage implique. Le degré de médiocrité calculé
est additionné à tous les paramètres du fichier de l'unité, normalisé dans l'intervalle de 1 à 100 et
utilisé pour déterminer le niveau d'exposition global de l'unité. En autorisant les utilisateurs à
manipuler ces champs, la commande « security » leur donne le choix de décider eux-mêmes quels
identifiants sont plus importants et donc susceptibles d'avoir un impact plus grand sur le niveau
d'exposition. Un poids de 0 signifie que le réglage ne sera pas vérifié.
{
"PrivateDevices":
{
"description_good": "Service has no access to hardware devices",
"description_bad": "Service potentially has access to hardware devices",
"weight": 1000,
"range": 1
},
"PrivateMounts":
{
"description_good": "Service cannot install system mounts",
"description_bad": "Service may install system mounts",
"weight": 1000,
"range": 1
},
"PrivateNetwork":
{
"description_good": "Service has no access to the host's network",
"description_bad": "Service has access to the host's network",
"weight": 2500,
"range": 1
},
"PrivateTmp":
{
"description_good": "Service has no access to other software's temporary files",
"description_bad": "Service has access to other software's temporary files",
"weight": 1000,
"range": 1
},
"PrivateUsers":
{
"description_good": "Service does not have access to other users",
"description_bad": "Service has access to other users",
"weight": 1000,
"range": 1
}
}
VOIR AUSSI
systemd(1), systemctl(1)
NOTES
1. Empaquetage de métadonnées
https://systemd.io/COREDUMP_PACKAGE_METADATA/
2. Spécification des partitions détectables
https://uapi-group.org/specifications/specs/discoverable_partitions_specification
3. Il est recommandé pour les autres outils de définir et vérifier $SUDO_UID comme il convient, en le
considérant comme une interface courante.
TRADUCTION
La traduction française de cette page de manuel a été créée par bubu <bubub@no-log.org>
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License
version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à
debian-l10n-french@lists.debian.org.
systemd 257.6 SYSTEMD-ANALYZE(1)