Vous avez deux manières complémentaires de mettre en œuvre ceci:
Octroi aux utilisateurs des autorisations d'utilisation à gitdistance des référentiels
Utilisez gitolite3pour fournir un schéma de référentiels en direct (décrit ici en détail ), qui nécessite essentiellement que vous ayez un bareréférentiel (un référentiel de concentrateur ) pour permettre à vos utilisateurs de pousser / tirer et une version extraite du même référentiel (un repo en direct ) situé dans le chemin approprié /srv/www/html, par exemple, par exemple.
J'aime utiliser gitolite3pour gérer le dépôt du hub , mais ce n'est pas une exigence, bien qu'il soit plutôt pratique d'avoir un contrôle d'accès à grain fin lié à votre LDAP de choix si besoin est. gitolite3peut fournir un contrôle à grain fin jusqu'au niveau de la branche.
Il est également recommandé de limiter les capacités de l' gitolite3utilisateur via sudoet de gérer les hooks au moyen d' sudoappels. Ceci est un exemple de travail utilisant des gitolite3crochets (n'hésitez pas à les adapter -ou à les améliorer / à les fixer- pour répondre à vos besoins):
Le contenu pertinent du /etc/sudoersou /etc/sudoers.d/gitolite3serait quelque chose dans le sens de:
Cmnd_Alias GITOLITE_CMDS = /usr/bin/git, /bin/chown, /bin/find, /usr/bin/xargs, /bin/chmod, /sbin/restorecon, /usr/local/sbin/publisher-hub2live
Cmnd_Alias GITOLITE_APACHE_CMDS = /usr/sbin/apachectl graceful
Defaults:gitolite3 !requiretty
Defaults:gitolite3 lecture=never
gitolite3 ALL = (root)NOPASSWD: GITOLITE_CMDS
gitolite3 APACHE_HOSTS = (root)NOPASSWD: GITOLITE_APACHE_CMDS
post-updatecrochet de repo du moyeu :
#!/bin/sh
echo "****"
echo "**** Calling publisher-hub2live script [Hub's post-update hook]"
echo "****"
sudo /usr/local/sbin/publisher-hub2live "/srv/www/html" "root:apache" "2750" "640"
exit 0
publisher-hub2live scénario:
#!/bin/sh
echo "****"
echo "**** Pulling changes into Live [publisher-hub2live]"
echo "****"
cd "$1" || exit
umask 0022
unset GIT_DIR
/usr/bin/git pull hub master
# custom actions here
# e.g call grunt tasks
/bin/chown -R "$2" "$1"
/bin/find "$1" -type d -exec chmod "$3" {} +
/bin/find "$1" -type f -exec chmod "$4" {} +
/bin/chmod u+x "$1"/.git/hooks/post-commit
/sbin/restorecon -R -v "$1"
exec /usr/bin/git update-server-info
exit 0
Limiter la possibilité d'exécuter des commandes non autorisées dans un shell de connexion
Ce que vous devez mettre en œuvre est une méthode reproductible et vérifiable pour limiter la capacité de l'utilisateur à effectuer des actions autres que celles strictement autorisées.
Ce n'est pas obligatoire mais cela aide si vous avez vos utilisateurs enregistrés dans LDAP, et que vous avez déjà déployé les mécanismes pour effectuer l'authentification LDAP, que ce soit au moyen d'un module PAM, ou en utilisant freeIPA et sssd.
Pour implémenter ce scénario, ce que je fais actuellement est le suivant (sachez que ce type de restrictions nécessite que plusieurs conditions soient remplies, sinon la restriction peut être facilement contournée):
- Les utilisateurs n'appartiennent pas au
wheelgroupe, le seul autorisé à utiliser su(appliqué via PAM). Habituellement, un utilisateur non LDAP ( sysadm) existe pour permettre aux administrateurs de confiance d'effectuer des actions en cas de reprise après sinistre ou d'indisponibilité LDAP.
Les utilisateurs reçoivent un fichier correctement sécurisé rbashavec un PATH en lecture seule pointant vers un privé ~/bin, ce ~/bin/répertoire contient des liens vers toutes les commandes autorisées, par exemple:
$ ll ~/bin
total 0
lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 clear -> /usr/bin/clear*
lrwxrwxrwx. 1 root dawud 7 Sep 17 08:58 df -> /bin/df*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 egrep -> /bin/egrep*
lrwxrwxrwx. 1 root dawud 8 Sep 17 08:58 env -> /bin/env*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 fgrep -> /bin/fgrep*
lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 git -> /usr/bin/git*
lrwxrwxrwx. 1 root dawud 9 Sep 17 08:58 grep -> /bin/grep*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 rview -> /bin/rview*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 sudo -> /usr/bin/sudo*
lrwxrwxrwx. 1 root dawud 17 Sep 17 08:58 sudoedit -> /usr/bin/sudoedit*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 tail -> /usr/bin/tail*
lrwxrwxrwx. 1 root dawud 11 Sep 17 08:58 wc -> /usr/bin/wc*
les utilisateurs bénéficient d' un environnement restreint, en lecture seule (pensez des choses comme LESSSECURE, TMOUT, HISTFILEvariables). C'est pour éviter les shelléchappements de commandes comme lesset assurer l'auditabilité.
le seul éditeur autorisé est rvim, pour la même raison. Les utilisateurs peuvent uniquement exécuter sudoedit, qui est configuré pour s'exécuter rvimdans la sudoconfiguration:
Defaults editor=/usr/bin/rvim
si des restrictions MAC sont en place (la distribution GNU / Linux spécifique que vous utilisez a SELinux activé), les utilisateurs sont mappés à l'utilisateur SELinux staff_uet ont le droit d'exécuter des commandes en tant qu'autre utilisateur comme requis via sudo. Le spécifique sudorulesautorisé doit être soigneusement examiné pour empêcher l'utilisateur de contourner ces limitations, et peut également être déployé dans votre infrastructure LDAP existante (c'est l'une des fonctionnalités gratuites de l'IPA).
des utilisateurs /home, /tmpet éventuellement /var/tmppolyinstanciés via /etc/security/namespace.conf:
/tmp /tmp/.inst/tmp.inst-$USER- tmpdir:create root
/var/tmp /tmp/.inst/var-tmp.inst-$USER- tmpdir:create root
$HOME $HOME/$USER.inst/ tmpdir:create root
La polyinstantiation des répertoires n'est pas une nouveauté, elle est disponible depuis assez longtemps. Pour référence, voir cet article de 2006 . En fait, beaucoup de modules utilisent déjà pam_namespacepar défaut, mais la configuration par défaut à /etc/security/namespace.confne permet pas la polyinstantiation. En outre, /etc/security/namespace.inittous les fichiers squelettiques doivent être en lecture seule pour les utilisateurs et détenus par root.
De cette façon, vous pouvez choisir si les utilisateurs peuvent exécuter n'importe quelle commande en leur nom (via un lien dans le ~/binrépertoire privé , fourni via /etc/skel, comme expliqué ci-dessus), au nom d'un autre utilisateur (via sudo) ou aucun.
