Améliorations liées à la sécurité

Cette section décrit les nouvelles fonctions de l'environnement d'exploitation Solaris 8 qui affectent la sécurité système et la propriété des systèmes de fichiers et des répertoires.

Solaris Smart Cards

La fonction Solaris Smart Card met en oeuvre le standard OCF (Open Card Framework) 1.1. Les responsables de la sécurité peuvent utiliser cette technologie pour protéger le bureau d'un ordinateur ou une application particulière en demandant aux utilisateurs de procéder eux-mêmes à une authentification au moyen d'une carte à puce. Toutes les machines protégées par Solaris Smart Cards doivent être équipées d'un lecteur de carte. Pour avoir accès aux bureaux et aux applications sécurisés, les utilisateurs doivent d'abord insérer leur carte à puce dans le lecteur, puis entrer le numéro d'identification personnel associé à leur carte. Les machines hôte utilisent les numéros d'identification personnels et les mots de passe des utilisateurs intégrés aux cartes pour vérifier l'identité de ces derniers.

Solaris Smart Cards prend en charge deux lecteurs de carte externes : Sun Smart Card Reader I et iButton Reader. Trois cartes à puce sont prises en charge : la carte compatible Java iButton, les cartes Cyberflex et la carte à puce Payflex.

Le document Solaris Smart Cards Administration Guide indique aux responsables de la sécurité comment configurer la prise en charge des cartes à puce sur leur site. Il présente également la technologie des cartes à puce aux utilisateurs.

Autorisations par défaut des systèmes de fichiers et des répertoires

La plupart des systèmes de fichiers et des répertoires de Solaris 8 utilisent des autorisations de propriété par défaut plus strictes que dans les versions précédentes. Les modifications apportées à la propriété et aux autorisations par défaut sont les suivantes :

• La propriété par défaut des fichiers et des répertoires est passée de bin à root.

• Les fichiers et répertoires qui dépendaient auparavant du numéro d'autorisation par défaut 775 dépendent désormais du numéro d'autorisation par défaut de 755.

• Les fichiers et répertoires qui dépendaient auparavant du numéro d'autorisation par défaut 664 dépendent désormais du numéro d'autorisation par défaut de 644.

• La valeur umask par défaut du système est 022.

Gardez à l'esprit les remarques suivantes lorsque vous créez un module destiné à être ajouté à un système exécutant Solaris 8 :

• Le propriétaire par défaut de tous les fichiers et répertoires doit être root.

• Le numéro d'autorisation par défaut des répertoires et des fichiers exécutables doit être 555 ou 755.

• Le numéro d'autorisation par défaut des fichiers ordinaires doit être 644 ou 444.

• Les fichiers set-uid et set-gid ne peuvent pas être modifiés par leur propriétaire sauf si ce dernier est le superutilisateur.

Ces modifications ne s'appliquent pas à tous les fichiers et répertoires de cette version (par exemple, elles ne concernent pas les fichiers et répertoires OpenWindows et CDE).

Contrôle d'accès basé sur les rôles

Les systèmes traditionnels de type superutilisateur accordent tous les pouvoirs du superutilisateur à toute personne pouvant devenir superutilisateur. Avec le contrôle d'accès basé sur les rôles (RBAC) de l'environnement d'exploitation Solaris 8, les administrateurs peuvent attribuer des capacités administratives limitées aux utilisateurs standard. Pour cela, ils utilisent trois nouvelles fonctions :

• les autorisations ; droits d'utilisateur qui autorisent l'accès à une fonction limitée ;

• les profils d'exécution : mécanismes d'association permettant de regrouper des autorisations et des commandes répondant à des attributs spéciaux, généralement l'ID de superutilisateur ;

• les rôles : types spéciaux de comptes utilisateur destinés à exécuter un ensemble de tâches administratives.

L'administrateur crée un profil d'exécution contenant des autorisations et des commandes privilégiées pour une tâche ou un ensemble de tâches spécifique. Ce profil peut être attribué directement à un utilisateur ou à un rôle. Les rôles sont eux-mêmes attribués aux utilisateurs. Pour avoir accès à un rôle qui lui a été attribué, l'utilisateur exécute la commande su. Les rôles présentent l'avantage d'être des comptes partagés qui n'ont pas besoin d'être mis à jour lorsque les responsabilités individuelles changent. Les nouveaux fichiers qui assurent la prise en charge de RBAC sont les suivants :

• /etc/user_attr : stocke les attributs de sécurité étendus liés aux utilisateurs et aux rôles ;

• /etc/security/auth_attr : répertorie et décrit les autorisations ;

• /etc/security/prof_attr : répertorie les profils d'exécution et les autorisations associées ;

• /etc/security/exec_attr : associe des attributs d'exécution aux profils d'exécution ;

• /etc/security/policy.conf : fournit la configuration de la stratégie de sécurité aux attributs de niveau utilisateur.

Pour plus d'informations, reportez-vous au document System Administration Guide, Volume 2

Gestion centralisée des événements d'audit utilisateur

Le fichier, /etc/security/audit_user, qui stocke les classes de présélection d'audit des utilisateurs et des rôles, n'est pas pris en charge dans le commutateur de noms. Il n'est plus nécessaire de configurer les événements d'audit par défaut pour un utilisateur sur chaque système auquel l'utilisateur a accès.

Prise en charge client Sun Enterprise Authentication Mechanism (Kerberos V5)

Cette fonction fournit une infrastructure Kerberos 5 côté client, une extension au module PAM (Pluggable Authentication Module), ainsi que des utilitaires permettant de sécuriser les applications basées RPC, telles que le service NFS. Kerberos permet une prise en charge sélectionnable améliorée de l'authentification, de la confidentialité et de l'intégrité au niveau utilisateur ou serveur. Les clients Kerberos peuvent être utilisés avec le mécanisme d'authentification SEAM (Sun Enterprise Authentication Mechanism), qui fait partie de SEAS 3.0, ou avec d'autres logiciels Kerberos V5 (par exemple, la distribution du MIT) pour créer une solution complète de signature réseau unique.

Pour plus d'informations, reportez-vous au document System Administration Guide, Volume 2.