Tout d'abord un grand merci de m'expliquer ce qu'est un VCS quand j'explique depuis maintenant 5 posts que la question posées n'a rien à voir avec les VCS.
Je sais ce qu'est un VCS, comment on s'en sert, je les utilises quotidiennement (et plutôt deux fois qu'une vu que le backup des systèmes est aussi un VCS sur mes machines), je fais du centralisé aussi bien que du distribué etc.
Donc tu as fait des handbook pour le FreeBSD ? Très bien. Estc-e que les modifications que tu as faites se sont retrouvées automatiquement en ligne ?
Non hein ?
Ben voilà.
Maintenant on se moque que ce soit l'admin FreeBSD himself en personne, ou une personne qui qu'elle soit qui a les droits d'administration d'un projet (Hint : il n'est pas forcément root sur tout le domaine) qui ait fait le taf. La sécurité dans les projets FreeBSD vient de la validation humaine. Rien ne se fait sans validation humaine si le mec qui soumet des modifs n'a pas les droits de commiter (i.e : il est probablement pas "stagiaire").
Après comme tu le dis très bien quand il y a 200 briques projets, des centaines de milliers de lignes de codes sur des sujets aussi variés que les I/O bas niveau et les CSS level3 compatibles IOS, c'est rarissime d'avoir assez d'admins (i.e chef de projets/commiteurs/responsables etc. par forcément des mecs root) pour faire une validation manuelle et fiable de tout ce qui passe. C'est ce que je soulignais en disant "L'admin va probablement trouver la blague saumâtre".
Et les VCS n'aident absolument pas à résoudre les problèmes de sécurité qui se posent.
Si on va part là, les ACL c'est la même chose. Le mec qui efface des ressources par erreur alors qu'il a le droit bha voilà... Ce n'est pas la bonne réponse.
Avec les ACL le mecs ne peut effacer que les fichiers sur lesquels il a les droits. Donc le mec peut lire le code HTML, mais n'avoir le droit que de modifier certains fichiers CSS. Alors que les fichiers sont lisibles aussi bien par le proxy nginx que par apache et qu'un autre stagiaire ne peut modifier que les fichiers images.
Sans ACL (et sans MLS/MAC ) forcément, il faudra mettre des droits inutiles à un des uid qui écrivent ou lisent sur le disque. Peut importe que ce soit l'uid du VCS, d'apache ou de nginx. Les fichiers ont un propriétaire et un groupe - avec à chaque fois un seul set de droits. Forcément tu augmentes la surface d'attaque en conservant les droits Unix plutôt qu'en mettant des ACL bien foutu. Et peut importe que ce soit le stagiaire, le VCS, Apache, ou nginx qui ait trop de droits (ie accès à des fichiers auquel il ne devrait pas avoir accès) ca pose un problème de sécurité qui est ultra-simple à résoudre.
Cette brique va livrer des artifacts bien définis qui seront déployés à un endroit et un contexte sécu précis.
Non. Elle va livrer des artefacts dans une section artificiellement restreinte d'un contexte beaucoup trop large - et on reporte sur le processus de déploiement la charge de limiter, via du code userspace, la zone d'impact de ce déploiement.
La surface d'attaque est l'ensemble de tous les répertoires que l'utilisateur (au sens uid) VCS peut lire ou écrire. Sans ACL cette surface est disproportionnée par rapport au besoin.
[^] # Re: Tout va bien, je t'assure
Posté par Kaane . En réponse au journal Les BSD isolés. Évalué à 4.
Tout d'abord un grand merci de m'expliquer ce qu'est un VCS quand j'explique depuis maintenant 5 posts que la question posées n'a rien à voir avec les VCS.
Je sais ce qu'est un VCS, comment on s'en sert, je les utilises quotidiennement (et plutôt deux fois qu'une vu que le backup des systèmes est aussi un VCS sur mes machines), je fais du centralisé aussi bien que du distribué etc.
Donc tu as fait des handbook pour le FreeBSD ? Très bien. Estc-e que les modifications que tu as faites se sont retrouvées automatiquement en ligne ?
Non hein ?
Ben voilà.
Maintenant on se moque que ce soit l'admin FreeBSD himself en personne, ou une personne qui qu'elle soit qui a les droits d'administration d'un projet (Hint : il n'est pas forcément root sur tout le domaine) qui ait fait le taf. La sécurité dans les projets FreeBSD vient de la validation humaine. Rien ne se fait sans validation humaine si le mec qui soumet des modifs n'a pas les droits de commiter (i.e : il est probablement pas "stagiaire").
Après comme tu le dis très bien quand il y a 200 briques projets, des centaines de milliers de lignes de codes sur des sujets aussi variés que les I/O bas niveau et les CSS level3 compatibles IOS, c'est rarissime d'avoir assez d'admins (i.e chef de projets/commiteurs/responsables etc. par forcément des mecs root) pour faire une validation manuelle et fiable de tout ce qui passe. C'est ce que je soulignais en disant "L'admin va probablement trouver la blague saumâtre".
Et les VCS n'aident absolument pas à résoudre les problèmes de sécurité qui se posent.
Si on va part là, les ACL c'est la même chose. Le mec qui efface des ressources par erreur alors qu'il a le droit bha voilà... Ce n'est pas la bonne réponse.
Avec les ACL le mecs ne peut effacer que les fichiers sur lesquels il a les droits. Donc le mec peut lire le code HTML, mais n'avoir le droit que de modifier certains fichiers CSS. Alors que les fichiers sont lisibles aussi bien par le proxy nginx que par apache et qu'un autre stagiaire ne peut modifier que les fichiers images.
Sans ACL (et sans MLS/MAC ) forcément, il faudra mettre des droits inutiles à un des uid qui écrivent ou lisent sur le disque. Peut importe que ce soit l'uid du VCS, d'apache ou de nginx. Les fichiers ont un propriétaire et un groupe - avec à chaque fois un seul set de droits. Forcément tu augmentes la surface d'attaque en conservant les droits Unix plutôt qu'en mettant des ACL bien foutu. Et peut importe que ce soit le stagiaire, le VCS, Apache, ou nginx qui ait trop de droits (ie accès à des fichiers auquel il ne devrait pas avoir accès) ca pose un problème de sécurité qui est ultra-simple à résoudre.
Cette brique va livrer des artifacts bien définis qui seront déployés à un endroit et un contexte sécu précis.
Non. Elle va livrer des artefacts dans une section artificiellement restreinte d'un contexte beaucoup trop large - et on reporte sur le processus de déploiement la charge de limiter, via du code userspace, la zone d'impact de ce déploiement.
La surface d'attaque est l'ensemble de tous les répertoires que l'utilisateur (au sens uid) VCS peut lire ou écrire. Sans ACL cette surface est disproportionnée par rapport au besoin.