PAMPersonalServer

Wiki.PAMPersonalServer History

Hide minor edits - Show changes to output

Changed lines 4-9 from:
- Je veux pouvoir proposer plusieurs services tels que ssh, openvpn, mail, ftp, samba, apache ... et globalement tout ce qui supporte l'authentification par PAM
- Je veux pouvoir gérer des politiques par défaut, ainsi que pouvoir définir finement qui à le droit de faire quoi.
- Je veux éviter un maximum la redondance de donnée: utiliser un mot de passe unique, utiliser la gestion des groupes unix ([@/etc/groups@]), et éviter la gestion de tout ça par des fichiers supplémentaires (pas de pam_accesslist donc)
- Je veux pouvoir faire une selection au niveau des groupes au niveau de mon applicatif. Typiquement, on peut vérifier l'appartenance d'un utilisateur à un groupe pour l'authentiifcation Apache, au délà même de l'idenditification.
- Je veux quelque chose d'élégant et qui s'approche de la philosophie UNIX
to:
* Je veux pouvoir proposer plusieurs services tels que ssh, openvpn, mail, ftp, samba, apache ... et globalement tout ce qui supporte l'authentification par PAM
* Je veux pouvoir gérer des politiques par défaut, ainsi que pouvoir définir finement qui à le droit de faire quoi.
* Je veux éviter un maximum la redondance de donnée: utiliser un mot de passe unique, utiliser la gestion des groupes unix ([@/etc/groups@]), et éviter la gestion de tout ça par des fichiers supplémentaires (pas de pam_accesslist donc)
* Je veux pouvoir faire une selection au niveau des groupes au niveau de mon applicatif. Typiquement, on peut vérifier l'appartenance d'un utilisateur à un groupe pour l'authentiifcation Apache, au délà même de l'idenditification.
* Je veux quelque chose d'élégant et qui s'approche de la philosophie UNIX
Changed lines 11-13 from:
- Ajout du module pam_access pour les services que je veux controller
- Définition d'un fichier [@access-<service>.conf@] par service. Il n'y a pas vraiment d'autres moyen de faire, c'est dommage.
- Chaque configuration access va aller vérifier selon ses règles si l'utilisateur appartient bien au group authorisé pour utiliser ce service.
to:
* Ajout du module pam_access pour les services que je veux controller
* Définition d'un fichier [@access-<service>.conf@] par service. Il n'y a pas vraiment d'autres moyen de faire, c'est dommage.
* Chaque configuration access va aller vérifier selon ses règles si l'utilisateur appartient bien au group authorisé pour utiliser ce service.
Changed lines 34-37 from:
Au niveau de la conf PAM, il va falloire intervenir sur chaqu'un des services dont on veut gérer l'accès. Typqiement, on va utiliser les règles [@account@], car selon le manuel:[@
account:
This module type performs non-authentication based account management. It is typically used to restrict/permit access to a service based on the time of day, currently available system resources (maximum number of users) or perhaps the location of the applicant user -- 'root' login only on the console.
@]
to:
Au niveau de la conf PAM, il va falloire intervenir sur chaqu'un des services dont on veut gérer l'accès. Typqiement, on va utiliser les règles [@account@], car selon le manuel:
->account:
->This module type performs non-authentication based account management. It is typically used to restrict/permit access to a service based on the time of day, currently available system resources (maximum number of users) or perhaps the location of the applicant user -- 'root' login only on the console.
Changed lines 28-30 from:
 - pam: préfixe mot clé, juste pour dire que ces groupes seront utilisés par PAM. Ca évite de foutre le bordel partout.
 - <service>: c'est le service qui utilisera ce groupe
 - <groupe>: quand le service peut vérifier à quel groupe appartient l'utilisateur. ce n'st pas à proprement utiliser par PAM, mais plutot par le service qui demande l'authentification.
to:
# pam: préfixe mot clé, juste pour dire que ces groupes seront utilisés par PAM. Ca évite de foutre le bordel partout.
# <service>: c'est le service qui utilisera ce groupe
# <groupe>: quand le service peut vérifier à quel groupe appartient l'utilisateur. ce n'st pas à proprement utiliser par PAM, mais plutot par le service qui demande l'authentification.
Changed lines 51-53 from:
 * Si l'utilisateur appartient au groupe [@pam_deny@], il est '''refusé'''
 * Si l'utilisateur est root ou s'il appartient au groupe @@pam_sshd@@, il est '''accepté'''
 * Dans tous les autres cas, il est '''refusé'''
to:
# Si l'utilisateur appartient au groupe [@pam_deny@], il est '''refusé'''
# Si l'utilisateur est root ou s'il appartient au groupe @@pam_sshd@@, il est '''accepté'''
# Dans tous les autres cas, il est '''refusé'''
Changed lines 20-21 from:
pam_ssh:x:5001:jez
pam_smb:x:5002:jez,coco,chacha
to:
pam_sshd:x:5001:jez
pam_samba:x:5002:jez,coco,chacha
Changed line 30 from:
 - <groupe>: quand le service peut vérifier à quel groupe appartient l'utilisateur
to:
 - <groupe>: quand le service peut vérifier à quel groupe appartient l'utilisateur. ce n'st pas à proprement utiliser par PAM, mais plutot par le service qui demande l'authentification.
Changed line 41 from:
account required        pam_access.so  accessfile=/etc/security/access-ssh.conf
to:
account required        pam_access.so  accessfile=/etc/security/access-sshd.conf
Changed lines 43-44 from:
account required        pam_access.so  accessfile=/etc/security/access-ssh.conf debug@]
Concernant le fichier [@/etc/security/access-ssh.conf debug@]:[@
to:
account required        pam_access.so  accessfile=/etc/security/access-sshd.conf debug@]
Concernant le fichier [@/etc/security/access-sshd.conf debug@]:[@
Changed line 47 from:
+: root (pam_ssh) : ALL
to:
+: root (pam_sshd) : ALL
Changed line 52 from:
 * Si l'utilisateur est root ou s'il appartient au groupe @@pam_ssh@@, il est '''accepté'''
to:
 * Si l'utilisateur est root ou s'il appartient au groupe @@pam_sshd@@, il est '''accepté'''
Added lines 16-17:

!!! Groupes
Added line 33:
!!! Configuration PAM: services
Added lines 38-39:

!!! Configuration PAM: ACL par services
Changed line 35 from:
On va donc placer la conf spécifique pour chacun de nos services [@/etc/pam.d/sshd@], globalement, on placera toujours cette directive en haut de la pile de traitement, car on veut qu'elle soit traitée en premier. Si notre module n'est pas satisfait, ça sert à rien de continuer à traiter les autres modules:
to:
On va donc placer la conf spécifique pour chacun de nos services [@/etc/pam.d/sshd@], globalement, on placera toujours cette directive en haut de la pile de traitement, car on veut qu'elle soit traitée en premier. Si notre module n'est pas satisfait, ça sert à rien de continuer à traiter les autres modules:[@
Added lines 1-53:
Je vais détailler dans cet article un moyen de mettre en place un système d'ACL pour un petit serveur personnel. L'idée est de pouvoir centraliser un maximum l'authentification, et ce en utilisant le plus les mécanismes fournis par Linux, et plus particulièrement PAM.

!!! De mon cahier des charges:
- Je veux pouvoir proposer plusieurs services tels que ssh, openvpn, mail, ftp, samba, apache ... et globalement tout ce qui supporte l'authentification par PAM
- Je veux pouvoir gérer des politiques par défaut, ainsi que pouvoir définir finement qui à le droit de faire quoi.
- Je veux éviter un maximum la redondance de donnée: utiliser un mot de passe unique, utiliser la gestion des groupes unix ([@/etc/groups@]), et éviter la gestion de tout ça par des fichiers supplémentaires (pas de pam_accesslist donc)
- Je veux pouvoir faire une selection au niveau des groupes au niveau de mon applicatif. Typiquement, on peut vérifier l'appartenance d'un utilisateur à un groupe pour l'authentiifcation Apache, au délà même de l'idenditification.
- Je veux quelque chose d'élégant et qui s'approche de la philosophie UNIX

!!! La solution technique choisie:
- Ajout du module pam_access pour les services que je veux controller
- Définition d'un fichier [@access-<service>.conf@] par service. Il n'y a pas vraiment d'autres moyen de faire, c'est dommage.
- Chaque configuration access va aller vérifier selon ses règles si l'utilisateur appartient bien au group authorisé pour utiliser ce service.

!! Mise en place des ACLs
Création des groupes ([@/etc/groups@]):[@
pam_deny:x:5000: coco
pam_ssh:x:5001:jez
pam_smb:x:5002:jez,coco,chacha
pam_vpn:x:5003:jez
pam_sftp:x:5003:
pam_http_home:5010:jez,coco
pam_http_extra:5011:
pam_http_admin:5012:jez@]
J'identifie ici mes groupes de services, en suivant la convention que je me suis imposée: [@pam_<service>_<groupe>@]:
 - pam: préfixe mot clé, juste pour dire que ces groupes seront utilisés par PAM. Ca évite de foutre le bordel partout.
 - <service>: c'est le service qui utilisera ce groupe
 - <groupe>: quand le service peut vérifier à quel groupe appartient l'utilisateur
J'ai aussi crée un groupe 'pam_deny' qui permet de bloquer l'accès à tous les services à un utilisateur. Au cas où il aurait pas payé son hébergement :-°.

Au niveau de la conf PAM, il va falloire intervenir sur chaqu'un des services dont on veut gérer l'accès. Typqiement, on va utiliser les règles [@account@], car selon le manuel:[@
account:
This module type performs non-authentication based account management. It is typically used to restrict/permit access to a service based on the time of day, currently available system resources (maximum number of users) or perhaps the location of the applicant user -- 'root' login only on the console.
@]
On va donc placer la conf spécifique pour chacun de nos services [@/etc/pam.d/sshd@], globalement, on placera toujours cette directive en haut de la pile de traitement, car on veut qu'elle soit traitée en premier. Si notre module n'est pas satisfait, ça sert à rien de continuer à traiter les autres modules:
account required        pam_access.so  accessfile=/etc/security/access-ssh.conf
# OU
account required        pam_access.so  accessfile=/etc/security/access-ssh.conf debug@]
Concernant le fichier [@/etc/security/access-ssh.conf debug@]:[@
# SSH rules
-: (pam_deny) : ALL
+: root (pam_ssh) : ALL
-: ALL : ALL
@]
L'ordre des directives importe, car c'est la première qui match qui est retournée. Pour expliquer ça:
 * Si l'utilisateur appartient au groupe [@pam_deny@], il est '''refusé'''
 * Si l'utilisateur est root ou s'il appartient au groupe @@pam_ssh@@, il est '''accepté'''
 * Dans tous les autres cas, il est '''refusé'''




Page last modified on November 30, 2013, at 08:17 PM EST