ksu - En ligne dans le Cloud

PROGRAMME:

Nom

ksu - super-utilisateur kerberisé

SYNOPSIS

ksu [ utilisateur_cible ] [ -n nom_principal_cible ] [ -c nom_cache_source ] [ -k ] [ -D ] [
-r temps ] [ -pf ] [ -l durée de vie ] [ -z | Z ] [ -q ] [ -e commander [ arguments ... ] ] [ -a [
arguments ... ] ]

EXIGENCES

Kerberos version 5 doit être installé pour compiler ksu. Doit avoir une version Kerberos 5
serveur en cours d'exécution pour utiliser ksu.

DESCRIPTION

ksu est une version Kerberized du programme su qui a deux missions : l'une est de sécuriser
changer l'ID utilisateur réel et effectif en celui de l'utilisateur cible, et l'autre est de
créer un nouveau contexte de sécurité.

NOTE:
Par souci de clarté, toutes les références et attributs de l'utilisateur invoquant le
programme commencera par "source" (par exemple, "utilisateur source", "cache source", etc.).

De même, toutes les références et attributs du compte cible commenceront par
"cible".

AUTHENTIFICATION

Pour remplir la première mission, ksu opère en deux phases : authentification et
autorisation. La résolution du nom principal cible est la première étape de l'authentification.
L'utilisateur peut soit préciser son nom principal avec le -n option (par exemple, -n
[email protected]) ou un nom principal par défaut sera attribué à l'aide d'une heuristique décrite
dans la section OPTIONS (voir -n option). Le nom d'utilisateur cible doit être le premier argument
à ksu; si elle n'est pas spécifiée, la racine est la valeur par défaut. Si . est spécifié, l'utilisateur cible
être l'utilisateur source (par exemple, ksu .). Si l'utilisateur source est root ou si l'utilisateur cible est le
utilisateur source, aucune authentification ou autorisation n'a lieu. Sinon, ksu recherche un
ticket Kerberos approprié dans le cache source.

Le ticket peut être soit pour le serveur final, soit un ticket d'octroi de ticket (TGT) pour le
domaine du principal cible. Si le ticket pour le serveur final est déjà dans le cache, c'est
décrypté et vérifié. S'il n'est pas dans le cache mais que le TGT l'est, le TGT est utilisé pour
obtenir le ticket pour le serveur final. Le ticket du serveur final est ensuite vérifié. Si ni l'un ni l'autre
ticket est dans le cache, mais ksu est compilé avec le GET_TGT_VIA_PASSWD définir, l'utilisateur
sera invité à saisir un mot de passe Kerberos qui sera ensuite utilisé pour obtenir un TGT. Si la
l'utilisateur est connecté à distance et n'a pas de canal sécurisé, le mot de passe peut être
exposé. Si aucun ticket n'est dans le cache et GET_TGT_VIA_PASSWD n'est pas défini,
l'authentification échoue.

AUTORISATION

Cette section décrit l'autorisation de l'utilisateur source lorsque ksu est invoqué sans le -e
option. Pour une description du -e option, voir la section OPTIONS.

Une fois l'authentification réussie, ksu vérifie si le principal cible est autorisé à
accéder au compte cible. Dans le répertoire personnel de l'utilisateur cible, ksu tente d'accéder
deux fichiers d'autorisation : .k5connexion(5) et .k5users. Dans le fichier .k5login chaque ligne
contient le nom d'un mandant autorisé à accéder au compte.

Par exemple :

[email protected]
jqpublic/[email protected]
jqpublic/[email protected]

Le format de .k5users est le même, sauf que le nom principal peut être suivi d'une liste de
commandes que le principal est autorisé à exécuter (voir le -e option dans les OPTIONS
pour plus de détails).

Ainsi, si le nom principal cible est trouvé dans le fichier .k5login, l'utilisateur source est
autorisé à accéder au compte cible. Sinon, ksu regarde dans le fichier .k5users. Si
le nom principal cible est trouvé sans aucune commande de fin ou suivi uniquement par *
alors l'utilisateur source est autorisé. Si .k5login ou .k5users existent mais qu'un
l'entrée appropriée pour le principal cible n'existe pas, l'accès est refusé. Si
aucun fichier n'existe, le principal se verra accorder l'accès au compte selon
les règles de mappage aname->lname. Sinon, l'autorisation échoue.

EXÉCUTION OF THE CIBLE SHELL

Une fois l'authentification et l'autorisation réussies, ksu procède de la même manière que su.
L'environnement n'est pas modifié à l'exception des variables USER, HOME et SHELL. Si
l'utilisateur cible n'est pas root, USER est défini sur le nom d'utilisateur cible. Sinon UTILISATEUR
reste inchangé. HOME et SHELL sont tous deux définis sur les valeurs par défaut de la connexion cible. Dans
De plus, la variable d'environnement KRB5CCNOM est défini sur le nom du cache cible.
L'ID utilisateur réel et effectif est remplacé par celui de l'utilisateur cible. L'utilisateur cible
shell est alors invoqué (le nom du shell est spécifié dans le fichier de mots de passe). Sur
l'arrêt du shell, ksu supprime le cache cible (à moins que ksu ne soit invoqué avec le -k
option). Ceci est implémenté en faisant d'abord un fork puis un exec, au lieu de simplement
exec, comme fait par su.

CRÉATEUR A NOUVEAU SÛRETÉ CONTEXTE

ksu peut être utilisé pour créer un nouveau contexte de sécurité pour le programme cible (soit la cible
shell, ou commande spécifiée via le -e option). Le programme cible hérite d'un ensemble de
informations d'identification de l'utilisateur source. Par défaut, cet ensemble comprend toutes les informations d'identification dans
le cache source ainsi que toutes les informations d'identification supplémentaires obtenues lors de l'authentification. Les
l'utilisateur source peut limiter les informations d'identification dans cet ensemble en utilisant -z or -Z option. -z
restreint la copie des tickets du cache source vers le cache cible aux seuls
tickets où client == le nom principal cible. Les -Z l'option fournit à l'utilisateur cible
avec un nouveau cache cible (pas de crédits dans le cache). Notez que pour des raisons de sécurité, lorsque
l'utilisateur source est root et l'utilisateur cible n'est pas root, -z l'option est le mode par défaut de
fonctionnement.

Bien qu'aucune authentification n'ait lieu si l'utilisateur source est root ou est le même que le
utilisateur cible, des tickets supplémentaires peuvent toujours être obtenus pour le cache cible. Si -n is
spécifié et aucune information d'identification ne peut être copiée dans le cache cible, l'utilisateur source est
demandé un mot de passe Kerberos (sauf si -Z spécifié ou GET_TGT_VIA_PASSWD n'est pas défini).
En cas de succès, un TGT est obtenu du serveur Kerberos et stocké dans le cache cible.
Sinon, si un mot de passe n'est pas fourni (utilisateur appuyez sur retour), ksu continue en mode normal
de fonctionnement (le cache cible ne contiendra pas le TGT souhaité). Si le mauvais mot de passe
est tapé, ksu échoue.

NOTE:
Lors de l'authentification, seuls les billets pouvant être obtenus sans fournir de
mot de passe sont mis en cache dans le cache source.

OPTIONS

-n nom_principal_cible
Spécifiez un nom de principal cible Kerberos. Utilisé dans l'authentification et l'autorisation
phases de ksu.

Si ksu est invoqué sans -n, un nom principal par défaut est attribué via le
heuristique suivante :

· Cas 1 : l'utilisateur source n'est pas root.

Si l'utilisateur cible est l'utilisateur source, le nom principal par défaut est défini sur le
principal par défaut du cache source. Si le cache n'existe pas, le
le nom principal par défaut est défini sur utilisateur_cible@domaine_local. Si la source et
les utilisateurs cibles sont différents et ni l'un ni l'autre ~utilisateur_cible/.k5users ni
~utilisateur_cible/.k5login existent, le nom principal par défaut est
nom_de_connexion_utilisateur_cible@domaine_local. Sinon, en commençant par le premier principal
ci-dessous, ksu vérifie si le principal est autorisé à accéder à la cible
compte et s'il existe un ticket légitime pour ce principal dans la source
cache. Si les deux conditions sont remplies, ce principal devient la cible par défaut
principal, sinon passez au principal suivant.

une. principal par défaut du cache source

b. utilisateur_cible@domaine_local

c. utilisateur_source@domaine_local

Si ac échoue, essayez n'importe quel principal pour lequel il existe un ticket dans le cache source
et qui est autorisé à accéder au compte cible. Si cela échoue, sélectionnez le
premier principal autorisé à accéder au compte cible à partir de ce qui précède
liste. Si aucun n'est autorisé et que ksu est configuré avec PRINC_LOOK_AHEAD tourné
activé, sélectionnez le principal par défaut comme suit :

Pour chaque candidat de la liste ci-dessus, sélectionnez un directeur d'école autorisé qui a le
même nom de domaine et première partie du nom principal égale au préfixe du
candidat. Par exemple si le candidat a) est [email protected] et
jqpublic/[email protected] est autorisé à accéder au compte cible alors le
Le principal par défaut est défini sur jqpublic/[email protected].

· Cas 2 : l'utilisateur source est root.

Si l'utilisateur cible n'est pas root, le nom principal par défaut est
utilisateur_cible@domaine_local. Sinon, si le cache source existe, le principal par défaut
name est défini sur le principal par défaut du cache source. Si le cache source
n'existe pas, le nom principal par défaut est défini sur racine\@local_realm.

-c nom_cache_source
Spécifiez le nom du cache source (par exemple, -c FICHIER :/tmp/my_cache). Si -c l'option n'est pas utilisée alors
le nom est obtenu de KRB5CCNOM variable d'environnement. Si KRB5CCNOM n'est pas
défini le nom du cache source est défini sur krb5cc_ uid>. Le nom du cache cible est
réglé automatiquement sur krb5cc_ uid>.(gen_sym()), où gen_sym génère un nouveau
nombre tel que le cache résultant n'existe pas déjà. Par exemple:

krb5cc_1984.2

-k Ne supprimez pas le cache cible à l'arrêt du shell cible ou d'une commande
(-e commander). Sans -k, ksu supprime le cache cible.

-D Activez le mode de débogage.

-z Restreindre la copie des tickets du cache source vers le cache cible aux seuls
tickets où client == le nom principal cible. Utilisez le -n possibilité si tu veux
les tickets pour autre que le principal par défaut. Notez que le -z option est
mutuellement exclusif avec le -Z option.

-Z Ne copiez aucun ticket du cache source vers le cache cible. Il suffit de créer un
cache cible frais, où le nom principal par défaut du cache est initialisé à
le nom principal cible. Notez que le -Z l'option est mutuellement exclusive avec la
-z option.

-q Supprimer l'impression des messages d'état.

Options de billets d'octroi de billets :

-l durée de vie -r Paisible -pf
Les options de billet d'octroi de billets ne s'appliquent que dans le cas où il n'y a pas
tickets appropriés dans le cache pour authentifier l'utilisateur source. Dans ce cas si
ksu est configuré pour demander aux utilisateurs un mot de passe Kerberos (GET_TGT_VIA_PASSWD is
défini), les options de ticket d'octroi de ticket qui sont spécifiées seront utilisées lorsque
obtenir un ticket d'octroi de ticket du serveur Kerberos.

-l durée de vie
(durée string.) Spécifie la durée de vie à demander pour le ticket ; si ce
n'est pas spécifiée, la durée de vie par défaut du ticket (12 heures) est utilisée à la place.

-r Paisible
(durée chaîne.) Spécifie que le renouvelable l'option doit être demandée pour le
ticket, et spécifie la durée de vie totale souhaitée du ticket.

-p précise que le procurable l'option doit être demandée pour le billet.

-f option spécifie que le transmissible l'option doit être demandée pour le billet.

-e commander [args ...]
ksu procède exactement de la même manière que s'il était invoqué sans le -e option, sauf
au lieu d'exécuter le shell cible, ksu exécute la commande spécifiée. Exemple
d'utilisation :

ksu bob -e ls -lag

L'algorithme d'autorisation pour -e est comme suit:

Si l'utilisateur source est root ou utilisateur source == utilisateur cible, aucune autorisation ne prend
place et la commande est exécutée. Si l'identifiant de l'utilisateur source != 0, et
~utilisateur_cible/.k5users n'existe pas, l'autorisation échoue. Autrement,
~utilisateur_cible/.k5users le fichier doit avoir une entrée appropriée pour le principal cible à
obtenir l'autorisation.

Le format de fichier .k5users :

Une seule entrée principale sur chaque ligne qui peut être suivie d'une liste de commandes
que le mandant est autorisé à exécuter. Un nom principal suivi d'un *
signifie que l'utilisateur est autorisé à exécuter n'importe quelle commande. Ainsi, dans la suite
Exemple:

[email protected] ls mail /local/kerberos/klist
jqpublic/[email protected] *
jqpublic/[email protected]

[email protected] n'est autorisé à exécuter que ls, E-mail et cliste les commandes.
jqpublic/[email protected] est autorisé à exécuter n'importe quelle commande.
jqpublic/[email protected] n'est autorisé à exécuter aucune commande. Noter que
jqpublic/[email protected] est autorisé à exécuter le shell cible (ksu régulier,
sans -e option) mais [email protected] n'est pas.

Les commandes répertoriées après le nom principal doivent être soit des noms de chemin complets, soit
juste le nom du programme. Dans le deuxième cas, CMD_CHEMIN en précisant l'emplacement de
les programmes autorisés doivent être définis au moment de la compilation de ksu. Quelle commande
est exécuté ?

Si l'utilisateur source est root ou l'utilisateur cible est l'utilisateur source ou l'utilisateur est
autorisé à exécuter toute commande (* entrée) alors la commande peut être soit un full soit un
chemin relatif menant au programme cible. Sinon, l'utilisateur doit spécifier
soit un chemin complet, soit simplement le nom du programme.

-a args
Spécifiez les arguments à transmettre au shell cible. Notez que tous les drapeaux et
les paramètres suivant -a seront passés au shell, ainsi toutes les options destinées à
ksu doit précéder -a.

Le -a L'option peut être utilisée pour simuler le -e option si elle est utilisée comme suit :

-a -c [commande [arguments]].

-c est interprété par le c-shell pour exécuter la commande.

INSTALLATION INSTRUCTIONS

ksu peut être compilé avec les quatre indicateurs suivants :

GET_TGT_VIA_PASSWD
Si aucun ticket approprié n'est trouvé dans le cache source, l'utilisateur sera
invité à entrer un mot de passe Kerberos. Le mot de passe est ensuite utilisé pour obtenir un billet
octroi du ticket du serveur Kerberos. Le danger de configurer ksu avec ça
la macro est si l'utilisateur source est connecté à distance et ne dispose pas d'un
canal, le mot de passe peut être exposé.

PRINC_LOOK_AHEAD
Lors de la résolution du nom principal par défaut, PRINC_LOOK_AHEAD active ksu
pour trouver les noms des principaux dans le fichier .k5users comme décrit dans la section OPTIONS
(voir -n option).

CMD_CHEMIN
Spécifie une liste de répertoires contenant des programmes que les utilisateurs sont autorisés à
exécuter (via le fichier .k5users).

HAVE_GETUSERSHELL
Si l'utilisateur source n'est pas root, ksu insiste pour que le shell de l'utilisateur cible soit
invoqué est un "shell légal". obtenir un shell utilisateur(3) est appelé à obtenir les noms de
"coquilles légales". Notez que le shell de l'utilisateur cible est obtenu à partir du mot de passe
fichier.

Exemple de configuration :

KSU_OPTS = -DGET_TGT_VIA_PASSWD -DPRINC_LOOK_AHEAD -DCMD_PATH='"/ bin /usr/ucb /local/bin"

ksu doit appartenir à root et avoir le bit d'identifiant utilisateur activé.

ksu tente d'obtenir un ticket pour le serveur final tout comme telnet et rlogin Kerberized.
Ainsi, il doit y avoir une entrée pour le serveur dans la base de données Kerberos (par exemple,
hôte/[email protected]). Le fichier keytab doit se trouver dans un emplacement approprié.

CÔTÉ EFFETS

ksu supprime tous les tickets expirés du cache source.

AUTEUR OF KSU

GENADE (ARI) MEDVINSKY

Utiliser ksu en ligne en utilisant les services onworks.net