Tâches de protection élémentaires

Liste des accès utilisateur

Les exemples qui suivent montrent comment est composée la liste des utilisateurs susceptibles d'accéder aux dépôts, systèmes hôte cibles, répertoires racine cible et à l'ensemble des produits.

Autorisation donnée aux utilisateurs de gérer les produits d'un dépôt

Les utilisateurs qui conditionnent des produits sont susceptibles d'avoir besoin d'accéder aux dépôts SD-UX pour les stocker.

Dans les ACL, a est une notation abrégée correspondant à l'ensemble des droits (crwit).

Pour autoriser l'utilisateur marie à ajouter de nouveaux produits au dépôt :

swacl -l depot -M user:marie:a [@ hôte:dépôt]

Pour autoriser l'utilisateur marie à modifier les produits existants d'un dépôt :

swacl -l product -M user:marie:a \* [@ hôte]

Pour modifier le modèle de telle sorte que l'utilisateur marie puisse modifier les nouveaux produits créés par d'autres dans le dépôt :

swacl -l global_product_template -M user:marie:a [@ hôte]

Dans les exemples précédents, remplacez user par group et utilisez un nom de groupe pour ajouter l'accès d'un groupe aux structures de dépôt.

Autorisation donnée aux utilisateurs de gérer les répertoires racines (Installation/Suppression)

Pour attribuer à l'utilisateur (marie) les droits requis pour l'autoriser à installer ou supprimer un logiciel sur le système hôte monsys:

swacl -l root -M user:marie:a @ monsys

Pour autoriser l'utilisateur marie à installer un logiciel sur le répertoire racine par défaut :

swacl -l root -M user:marie:ri

Pour donner à l'utilisateur marie l'autorisation d'ouvrir le répertoire racine en lecture :

swacl -l root -M user:marie:r

Pour autoriser l'utilisateur marie à installer un nouveau logiciel dans l'objet racine :

swacl -l root -M user:marie:i

Pour permettre à l'utilisateur distant allen@swelter de gérer complètement le système de fichiers racine de swcrunch:

swacl -l root -M user:allen@swelter:a

Dans les exemples précédents, remplacez user par group et utilisez un nom de groupe pour ajouter l'accès d'un groupe aux structures de dépôt.

	REMARQUE : Du fait que l'installation d'un logiciel implique généralement la modification des fichiers système pour les opérations de configuration, l'installation des logiciels et les scripts de configuration sont exécutés sous l'identification de superutilisateur. De ce fait, accorder à un utilisateur le droit d'écriture dans un répertoire racine revient essentiellement à lui attribuer les droits d'un superutilisateur pour la gestion du logiciel.

Restriction des accès aux dépôts

Pour restreindre l'accès en lecture à un dépôt, vous devez d'abord supprimer l'accès any_other du dépôt et des produits contenus dans le dépôt et du modèle chargé de contrôler les produits du dépôt.

Il est possible de restreindre l'accès au dépôt alpine sur le système hôte drgw:

# swacl -l depot -D any_other @ drgw:/alpine
# swacl -l product -D any_other \* @ drgw:/alpine
# swacl -l global_product_template -D any_other \* \
      @ drgw:/alpine

Il sera alors nécessaire d'ajouter des utilisateurs spécifiques (et donc des systèmes hôtes) avec accès en lecture après avoir supprimé le mode any_other de la protection du dépôt. Les commandes suivantes ajoutent un accès en lecture au dépôt, aux produits contenus dans le dépôt et aux produits futurs, respectivement, pour les utilisateurs du système hôteA.

# swacl -l depot -M other:@hôteA:r @ drgw:/alpine
# swacl -l product -M other:@hôteA:r \* @ drgw:/alpine
# swacl -l global_product_template -M other:@hôteA:r \
      @ drgw:/alpine

Dans l'exemple qui suit, le superutilisateur local empêche les utilisateurs distants d'accéder à /simple_1.depot sur swelter, mais autorise les utilisateurs locaux à accéder au dépôt :

# swacl -l depot -D any_other @ /simple_1.depot
# swacl -l depot -M other:r @ /simple_1.depot
# swacl -l depot @ /simple_1.depot

#
# swacl    liste de contrôle d'accès au dépôt
#
# Pour le dépôt :  swelter:/simple_1.depot
#
# Date :  Vendredi 1 décembre 2000 11:55:17
#
# Propriété des objets :  Utilisateur= allen
#                         Group=users
#                         Realm=swelter.fc.hp.com
#
# default_realm=swelter.fc.hp.com
object_owner:crwit
other:-r---

Les utilisateurs locaux peuvent désormais accéder à ce dépôt du fait de l'ACL other, mais les utilisateurs distants ne le peuvent pas.

Pour permettre au seul utilisateur shelly du système hôte swcrunch d'accéder au logiciel d'un dépôt situé sur swelter, l'ajout d'une ACL d'utilisateur pour shelly peut s'avérer suffisant :

swacl -l depot -M user:shelly@swcrunch:r @ /simple_1.depot

Toutefois, cette condition n'est pas suffisante. Toute tentative d'accès par shelly à ce dépôt échouera avec une violation de sécurité. Ceci provient du fait que SD-UX exige également que les agents SD (le processus swagent) en contact avec le serveur dépôt soit autorisé par le biais d'une ACL host entry_type:

swacl -l depot -M host:swcrunch:r @ /simple_1.depot

(Notez que l'utilisateur shelly demande également des autorisations d'ACL appropriées pour installer un logiciel sur swcrunch.)

	REMARQUE : Le droit r (read) autorise l'utilisateur à accéder au dépôt et aux produits et le droit t (test) permet à l'utilisateur de lister les ACL.

Ajout de systèmes hôtes cible

Pour les commandes swinstall et swcopy, l'utilisateur et le système hôte cible sont tous deux validés (en d'autres termes, pour se prémunir contre la transformation d'utilisateurs non autorisés sur les systèmes hôtes distants en utilisateurs autorisés). La commande qui suit permet d'ajouter un droit de lecture pour le système hôte nommé target au dépôt par défaut situé sur le système hôte local, les produits stockés dans le dépôt et tout produit ultérieur ajouté au dépôt (en utilisant le paramètre global_product_template).

# swacl -l depot -M host:target:r
# swacl -l product -M host:target:r \*
# swacl -l global_product_template -M host:target:r

Du fait que l'utilisateur est toujours validé, il existe une variante destinée à faciliter la gestion d'un grand nombre de systèmes hôtes : elle consiste à donner l'autorisation en lecture à tous les systèmes hôtes :

# swacl -l depot -M host:*:r
# swacl -l product -M host:*:r \*
# swacl -l global_product_template -M host:*:r

	REMARQUE : “*” est une valeur reconnue pour le type d'ACL host .

Restriction temporaire des accès

Une méthode simple pour restreindre l'accès au seul superutilisateur local sans modification des ACL consiste à annuler l'enregistrement du dépôt.

swreg -u -l depot [@ dépôt]

Il pourra par la suite faire l'objet d'un nouvel enregistrement :

swreg -l depot [@ dépôt]

Fermeture du réseau SD-UX

Le secret SD-UX est utilisé comme preuve d’authenticité des certificats de l’appelant. Il s’agit d’un mot de passe utilisé par SD-UX pour vérifier l’authenticité du système hôte de l’appelant. La zone de secret par défaut est établie en fabrication pour correspondre à la configuration par défaut du contrôleur HP-UX. Tous les secrets (c'est-à-dire le contrôleur, les cibles et les dépôts) doivent être identiques.

	REMARQUE : Ne modifiez en aucun cas la zone de secret par défaut sauf si vous avez également modifié le secret par défaut sur le contrôleur HP-UX SD-UX. Ces deux secrets doivent concorder.

Il est possible de restreindre les systèmes hôtes susceptibles d'être reconnus par SD-UX en modifiant le secret par défaut des contrôleurs et systèmes hôtes cibles SD-UX du réseau. Le secret par défaut est défini dans le fichier/var/adm/sw/security/secrets.

Il est possible de modifier le secret par défaut indiqué dans ce fichier :

default      nouveau secret

Pour de plus amples informations, voir « Sécurité entre systèmes hôtes : Fichier de secrets partagés ».

Modification d'une ACL

Lorsque la commande swacl est exécutée sans l'option -M, -D, ou -F, elle lit l'ACL spécifiée, la convertit en texte normal et l'affiche sur le fichier standard de sortie stdout. Le résultat de la commande peut également être redirigé vers un fichier susceptible ensuite d'être imprimé ou modifié. Une fois que vous avez modifié le fichier, vous pouvez utiliser l'option -F fichier décrite ci-dessus pour remplacer l'ancienne ACL. Cette procédure vous offre toutes les fonctions de modification d'ACL.

Vous devez avoir l'autorisation de « test » dans l'ACL afin de produire le fichier de modification (lister l'ACL) ainsi que l'autorisation de « contrôle » afin de la modifier au moyen des options -F, -D ou -M. Toute entrée d'ACL doit comporter le droit de test.

Si la nouvelle ACL ne contient aucune erreur détectable et que vous disposez des droits d'accès nécessaires, le remplacement s'effectue avec succès. En revanche, s'il échoue parce que vos droits d'accès sont insuffisants pour la modification, un message d'erreur est émis et l'objet n'est pas modifié.

Vous pouvez modifier ou supprimer des entrées existantes, ou encore ajouter des entrées additionnelles à l'ACL.

	REMARQUE : Il est possible de modifier l'ACL de façon que vous ne puissiez y accéder vous-même ! Soyez très prudent pour éviter de supprimer accidentellement votre propre autorisation de contrôle d'ACL. Par mesure de sécurité, les ACL SD-UX devraient toujours être modifiées par le superutilisateur local.

Voici quelques exemples fondés sur l'ACL suivante, protégeant un produit (FORTRAN) créé par l'utilisateur martin sur l'hôte local lehi.fc.hp.com:

# swacl    liste de contrôle d’accès au produit
#
# Pour l’hôte :  lehi:/
#
# Date :  Vendredi 1 décembre 2000 11:55:19
#
# Pour le produit :      FORTRAN,r=9.0,v=HP # Propriété des objets : Utilisateur=root
#                        Groupe=sys
#                        Realm=lehi.fc.hp.com
#default_realm=lehi.fc.hp.com
object_owner:crwit
user:barb:-rt
user:ramon:-rt
group:swadm:crwit
host:alma.fc.hp.com:-rt
any_other:-rt

Vous pouvez répertorier les ACL du produit FORTRAN dans le dépôt /var/spool/sw (dépôt par défaut) et les préparer avant modification :

# swacl -l product FORTRAN >acl_tmp

La commande a pour effet de copier l'ACL ci-dessus dans le fichier temporaire acl_tmp que vous pouvez ensuite modifier. Modifiez le fichier acl_tmp avec un éditeur de texte quelconque.

Pour remplacer toutes les entrées d'ACL du produit FORTRAN, tapez :

# swacl -l product -F acl_tmp FORTRAN

Pour modifier le modèle de produit par défaut dans le dépôt /var/spool/sw_dev, tapez :

# swacl -l product_template @ /var/spool/sw_dev >fichier_tmp

Modifiez ensuite le fichier fichier_tmp et remplacez l'ACL en tapant :

# swacl -l product_template -F fichier_tmp \
      @ /var/spool/sw_dev

Pour supprimer les entrées de l'utilisateur barb et du groupe swadm, utilisez :

# swacl -D user:barb  -D group:swadm -l product FORTRAN

Pour donner à l'utilisateur ramon le droit de modification du produit FORTRAN, tapez :

# swacl -M user:ramon:trw -l product FORTRAN

Pour ajouter une entrée pour l’utilisateur pam avec des droits de gestion complète ("a" est la forme abrégée de "crwit"), utilisez :

# swacl -M user:pam:a  

Pour ajouter une entrée accordant à tous les utilisateurs du groupe swadm sur les hôtes distants dewd et stewd la gestion complète du produit FORTRAN dans le dépôt local par défaut, utilisez la commande suivante :

# swacl -M group:swadm@dewd:a -M group:swadm@stewd:a \
      -l product FORTRAN

Pour lister l'ACL protégeant le dépôt par défaut sur l'hôte dewd, tapez :

# swacl -l depot @ dewd