jail effectue sa propre sécurité. Ca n'a rien a voir avec la politique de sécurité établis sur le système.
C'est quoi la politique de sécurité effectuée par le système ? La séparation kernel mode/user mode ? Parceque UID/GID c'est les routines file system (au sens large) qui gèrent, SE Linux c'est les routines SE Linux, etc. J'aimerais vraiment comprendre le distinguo que tu fais entre des routines kernel de sécurité avec limitations d'une part et d'autres routines kernel de sécurité avec limitation d'autre part.
SE Linux a rien a voir avec un jail ou un chroot.
C'est un système de virtualisation + cotainers. Il est utilisé différamment certes mais fondamentalement c'est exactement le même principe sous-jacent.
Il n'y a pas d'authentification "se linux"
Alors comment donne-t-il les droits ? Si il n'y pa pas de système qui permette de savoir qui a les droits (ie authentification) que fait SE Linux pour les attribuer ? Il tire au sort ?
N.B il existe plusieurs méthodes d'authentification (je suis (bio-métrie), je connais (mot de passe ou clef), je sais faire (door knocking, sign pad), j'ai fait(élévation de privilèges, réattribution de droit, login tortueux))
De plus, c'est pas moi qui confond en utilisant la partie fixe pour parler de la partie variable hein...
Enfin, tu utilise AC pour account control, (Mandatory?) access control , ... ?
Tu dis que c'est gravissime de connaitre les logins qui ont accès à tel ou tel outil, je réponds que ce n'est plus le cas aujourd'hui. Parceque même si le login est une condition nécessaire, ce n'est plus une condition suffisante (justement à cause de la partie variable comme tu l'appelles). Ceci étant, pour ta gouverne sache que dans environnement de domaine la partie fixe est l'UID pas le login. Sur mes serveur root peut être 0, 514 ou 10000 suivant les cas. Avec le même login et le même mot de passe (bon pour 0 il faut la clef). C'est kerberos/LDAP qui attribue le UID suivant l'authentification...
Quand à AC, c'est l'abrevation de access control. Ca englobe tout ce qui est MAC, ACL, jail, SE Linux etc. Bref tout ce qui est attribution/retraits de droits en plus du couple UID/GID
Donc tes procédures ne sont pas à jour et tu as besoin que le système te tienne par la main pour te dire qui a le droit ou pas.
a) En entreprise c'est pas forcément moi qui ait monté le système/domaine
b) En entreprise je suis pas forcément seul et avec la maitrise absolue sur le système/domaine
c) En entreprise il y a des gens qui vont, qui viennent, qui prennent des vacances qui changent de postes, qui prennent des assitants etc.
d) En entreprise il y a des softs fermés dont le vendeur n'assure pas la maintenance si les utilisateurs n'ont pas tel et tel droits.
Après monter un système tel que M. Truc qui a beoin de faire les taches 1, 2 et 4 mais pas la tache 3 et qui quand il part en vacances a besoin que madame chose fasse les taches 1 et 2 et que monsieur bidule prenne en charge la tache 4 nécessite une gestion complète. Si tu es capable de gérer tout çà de tête, félicitation pour toi (à moins que tu ne bosses dans une petite entreprise, ou une boite ou la sécurité n'est pas primordiale). Personellement je bosse pour de très grands groupes étalés sur plusieurs pays, dont des banques. Le nombre de scripts mis en place qui ne servent qu'à déplacer les fichier du dossier a vers le dossier b en changeant les droits au passage est assez impressionant. Mais si on ne le fait pas on se retrouve avec des effets de bords désagréables de type "machin a besoin de faire la tache 1 et la tache 4 mais il se retrouve également avec les droits pour lire les résultats de la tache 3".
Parcourir un arbre et faire un check, un problème NP complet ? Tu as fumé quoi ? Tu m'en passes ?
Je reprend :
Tu as un domaine, dans ce domaine tu as une forêt d'annuaire LDAP avec des relations de confiance les uns avec les autres ou pas. Ensuite tu as des politiques de sécurité certaines dans le domaine, certaines dans l'annuaire LDAP concernée, certaines dans l'annuaire LDAP de l'utilisateur et enfin certaines sur la machine de l'utilisateur et sur le serveur de l'application. Trouver l'ensemble des utilisateurs capables de lancer telle commande avec tels arguments sur l'ensemble du domaine doit être un problème NP complet je pense.
Bien entendu dans la vraie vie on s'arrange pour que ce soit des groupes locaux qui contiennent des groupes LDAP qui sont à leurs tour inscrit dans des politiques domaines. Ce qui rend la détermination de droits plus simple, mais la possibilité de créer des effets de bords reste élevée.
Dans une boite où j'interviens c'était à peu près ce qui ce passé. Conclusion, maintenant c'est "les sysadmins se déplacent quand vous avez besoin de lancer un truc".
Bonjour, les sysadmin sont à Paris et à Toronto. L'utilisateur est à Singapour. Ah, et il lance ce type d'opération 300 fois par jour. C'est la validation/renouvellement des clefs de confiance tierces, légalement il faut une validation humaine. Il lui faut les droits sur le LDAP. A vous.
audit de sécurité toussa... (on peut déjà le faire sans cette fonctionnalité. encore heureux!).
On peut tout faire en langage machine sur une machine Turing Complete. La question est peut on le faire bien, de façon fiable dans un temps raisonnable (ie avant que Mme Chose ait besoin d'autres droits). Pas facile. Ca se fait avec des réseaux de Petri coloré par exemple quand on veut être sur de couvrir tous les cas et tous les effets de bords. Le seul ennui est que quasiment personne n'est capable de formaliser un problème de droits à l'échelle d'une boite internationale avec un réseau de Petri. Donc on pense avoir fait les choses proprement, mais on a pas de preuves (au sens mathématique du terme).
Sur la plupart des machines que j'administre, je peux trouver ça sans trop de problème par contre).
Si tu as du mal a trouver ça, c'est peut être que ta politique de sécurité crains un peu, tu ne crois pas ?
Si tu utilise juste les droits UID/GID ca ne pose pas de problèmes en effet. Mais des fois ca ne suffit pas comme droits.
Quand à ma politique de sécurité ca fait trois année de suite que l'audit "surprise" se termine en 30 minutes avec l'auditeur qui est coupé du réseau et qui est obligé d'appeler pour qu'on le débloque de façon à pouvoir finir ses tests (donc au niveau surprise, plouf)
Et puis si on les a rajouté c'est qu'il y a une raison... et si on les a pas supprimé c'est aussi qu'il y a une raison.
Le problème n'est pas là. Un utilisateur X qui n'a plus besoin de l'application A, doit-il garder les droits sur le répertoire 1 utilisé par l'application A mais aussi par d'autres applications dans certains cas.
Répondre à cette question nécessite de savoir parfaitement ce que fait cet utilisateur et d'avoir une architecture complète et à jour de tous les SI pour savoir si l'utilisation 12 de l'application B ne nécessite pas aussi les droits sur répertoire 1.
De plus il est très fréquents que deux utilisateurs qui ont un répertorie en commun l'utilise pour autre chose que ce qui est prévu pour des raisons pratiques. Donc quand on ferme le répertoire 1 à un des deux utilisateurs ca gueule qu'une tache qui n'a rien à voir ne marche plus. Des fois quand c'est un grand ponte qui gueule (Forex ou Trésorerie par exemple) tu recois l'ordre de rendre le répertoire à l'utilisateur qui ne devrait plus en avoir besoin.
Même chose que plus haut.
On sait déjà le faire sans avoir besoin de ce truc.
Je ne connais pas grand monde qui soit capable de dire, à forciori sur sa machine personelle, cet utilisateur ne pourra pas executer cette commande. Il faut déjà un bon niveau en informatique.
(Ps sur mes serveur un tant soit peu sécurisé, j'ai un PermitRootLogin no sur mon sshd_config.
J'aimerais savoir comme tu t'authentifie par su avec une clé.)
Tu n'a pas accès à su si tu es venu par login/mot de passe depuis le domaine. Tu n'es pas dans le bon groupe.
De toute façon pour avoir vraiment les droits root sur le domaine entier il faut :
- être sur le bon VLAN
- Se logguer au firewall avec un utilisateur wheel via clef. PFauth et PFSync se mettent en route.
- Récupérer le port à la con qui change tout le temps
- Se logguer au domaine avec la clef root sur le port à la con qui change en permanence
- Pendant mes heures de veille, répondre au téléphone pour m'expliquer lentement pourquoi il y a eu besoin de se loguer en root sur le domaine. Toute réponse non satisfaisante entrainne la fermeture de la session et l'invalidation de la clef.
[^] # Re: On se demande qui est l'idiot/enflure
Posté par Jerome Herman . En réponse au journal On connait un des brevets microsoftiens que linux viole. Évalué à 2.
C'est quoi la politique de sécurité effectuée par le système ? La séparation kernel mode/user mode ? Parceque UID/GID c'est les routines file system (au sens large) qui gèrent, SE Linux c'est les routines SE Linux, etc. J'aimerais vraiment comprendre le distinguo que tu fais entre des routines kernel de sécurité avec limitations d'une part et d'autres routines kernel de sécurité avec limitation d'autre part.
SE Linux a rien a voir avec un jail ou un chroot.
C'est un système de virtualisation + cotainers. Il est utilisé différamment certes mais fondamentalement c'est exactement le même principe sous-jacent.
Il n'y a pas d'authentification "se linux"
Alors comment donne-t-il les droits ? Si il n'y pa pas de système qui permette de savoir qui a les droits (ie authentification) que fait SE Linux pour les attribuer ? Il tire au sort ?
N.B il existe plusieurs méthodes d'authentification (je suis (bio-métrie), je connais (mot de passe ou clef), je sais faire (door knocking, sign pad), j'ai fait(élévation de privilèges, réattribution de droit, login tortueux))
De plus, c'est pas moi qui confond en utilisant la partie fixe pour parler de la partie variable hein...
Enfin, tu utilise AC pour account control, (Mandatory?) access control , ... ?
Tu dis que c'est gravissime de connaitre les logins qui ont accès à tel ou tel outil, je réponds que ce n'est plus le cas aujourd'hui. Parceque même si le login est une condition nécessaire, ce n'est plus une condition suffisante (justement à cause de la partie variable comme tu l'appelles). Ceci étant, pour ta gouverne sache que dans environnement de domaine la partie fixe est l'UID pas le login. Sur mes serveur root peut être 0, 514 ou 10000 suivant les cas. Avec le même login et le même mot de passe (bon pour 0 il faut la clef). C'est kerberos/LDAP qui attribue le UID suivant l'authentification...
Quand à AC, c'est l'abrevation de access control. Ca englobe tout ce qui est MAC, ACL, jail, SE Linux etc. Bref tout ce qui est attribution/retraits de droits en plus du couple UID/GID
Donc tes procédures ne sont pas à jour et tu as besoin que le système te tienne par la main pour te dire qui a le droit ou pas.
a) En entreprise c'est pas forcément moi qui ait monté le système/domaine
b) En entreprise je suis pas forcément seul et avec la maitrise absolue sur le système/domaine
c) En entreprise il y a des gens qui vont, qui viennent, qui prennent des vacances qui changent de postes, qui prennent des assitants etc.
d) En entreprise il y a des softs fermés dont le vendeur n'assure pas la maintenance si les utilisateurs n'ont pas tel et tel droits.
Après monter un système tel que M. Truc qui a beoin de faire les taches 1, 2 et 4 mais pas la tache 3 et qui quand il part en vacances a besoin que madame chose fasse les taches 1 et 2 et que monsieur bidule prenne en charge la tache 4 nécessite une gestion complète. Si tu es capable de gérer tout çà de tête, félicitation pour toi (à moins que tu ne bosses dans une petite entreprise, ou une boite ou la sécurité n'est pas primordiale). Personellement je bosse pour de très grands groupes étalés sur plusieurs pays, dont des banques. Le nombre de scripts mis en place qui ne servent qu'à déplacer les fichier du dossier a vers le dossier b en changeant les droits au passage est assez impressionant. Mais si on ne le fait pas on se retrouve avec des effets de bords désagréables de type "machin a besoin de faire la tache 1 et la tache 4 mais il se retrouve également avec les droits pour lire les résultats de la tache 3".
Parcourir un arbre et faire un check, un problème NP complet ? Tu as fumé quoi ? Tu m'en passes ?
Je reprend :
Tu as un domaine, dans ce domaine tu as une forêt d'annuaire LDAP avec des relations de confiance les uns avec les autres ou pas. Ensuite tu as des politiques de sécurité certaines dans le domaine, certaines dans l'annuaire LDAP concernée, certaines dans l'annuaire LDAP de l'utilisateur et enfin certaines sur la machine de l'utilisateur et sur le serveur de l'application. Trouver l'ensemble des utilisateurs capables de lancer telle commande avec tels arguments sur l'ensemble du domaine doit être un problème NP complet je pense.
Bien entendu dans la vraie vie on s'arrange pour que ce soit des groupes locaux qui contiennent des groupes LDAP qui sont à leurs tour inscrit dans des politiques domaines. Ce qui rend la détermination de droits plus simple, mais la possibilité de créer des effets de bords reste élevée.
Dans une boite où j'interviens c'était à peu près ce qui ce passé. Conclusion, maintenant c'est "les sysadmins se déplacent quand vous avez besoin de lancer un truc".
Bonjour, les sysadmin sont à Paris et à Toronto. L'utilisateur est à Singapour. Ah, et il lance ce type d'opération 300 fois par jour. C'est la validation/renouvellement des clefs de confiance tierces, légalement il faut une validation humaine. Il lui faut les droits sur le LDAP. A vous.
audit de sécurité toussa... (on peut déjà le faire sans cette fonctionnalité. encore heureux!).
On peut tout faire en langage machine sur une machine Turing Complete. La question est peut on le faire bien, de façon fiable dans un temps raisonnable (ie avant que Mme Chose ait besoin d'autres droits). Pas facile. Ca se fait avec des réseaux de Petri coloré par exemple quand on veut être sur de couvrir tous les cas et tous les effets de bords. Le seul ennui est que quasiment personne n'est capable de formaliser un problème de droits à l'échelle d'une boite internationale avec un réseau de Petri. Donc on pense avoir fait les choses proprement, mais on a pas de preuves (au sens mathématique du terme).
Sur la plupart des machines que j'administre, je peux trouver ça sans trop de problème par contre).
Si tu as du mal a trouver ça, c'est peut être que ta politique de sécurité crains un peu, tu ne crois pas ?
Si tu utilise juste les droits UID/GID ca ne pose pas de problèmes en effet. Mais des fois ca ne suffit pas comme droits.
Quand à ma politique de sécurité ca fait trois année de suite que l'audit "surprise" se termine en 30 minutes avec l'auditeur qui est coupé du réseau et qui est obligé d'appeler pour qu'on le débloque de façon à pouvoir finir ses tests (donc au niveau surprise, plouf)
Et puis si on les a rajouté c'est qu'il y a une raison... et si on les a pas supprimé c'est aussi qu'il y a une raison.
Le problème n'est pas là. Un utilisateur X qui n'a plus besoin de l'application A, doit-il garder les droits sur le répertoire 1 utilisé par l'application A mais aussi par d'autres applications dans certains cas.
Répondre à cette question nécessite de savoir parfaitement ce que fait cet utilisateur et d'avoir une architecture complète et à jour de tous les SI pour savoir si l'utilisation 12 de l'application B ne nécessite pas aussi les droits sur répertoire 1.
De plus il est très fréquents que deux utilisateurs qui ont un répertorie en commun l'utilise pour autre chose que ce qui est prévu pour des raisons pratiques. Donc quand on ferme le répertoire 1 à un des deux utilisateurs ca gueule qu'une tache qui n'a rien à voir ne marche plus. Des fois quand c'est un grand ponte qui gueule (Forex ou Trésorerie par exemple) tu recois l'ordre de rendre le répertoire à l'utilisateur qui ne devrait plus en avoir besoin.
Même chose que plus haut.
On sait déjà le faire sans avoir besoin de ce truc.
Je ne connais pas grand monde qui soit capable de dire, à forciori sur sa machine personelle, cet utilisateur ne pourra pas executer cette commande. Il faut déjà un bon niveau en informatique.
(Ps sur mes serveur un tant soit peu sécurisé, j'ai un PermitRootLogin no sur mon sshd_config.
J'aimerais savoir comme tu t'authentifie par su avec une clé.)
Tu n'a pas accès à su si tu es venu par login/mot de passe depuis le domaine. Tu n'es pas dans le bon groupe.
De toute façon pour avoir vraiment les droits root sur le domaine entier il faut :
- être sur le bon VLAN
- Se logguer au firewall avec un utilisateur wheel via clef. PFauth et PFSync se mettent en route.
- Récupérer le port à la con qui change tout le temps
- Se logguer au domaine avec la clef root sur le port à la con qui change en permanence
- Pendant mes heures de veille, répondre au téléphone pour m'expliquer lentement pourquoi il y a eu besoin de se loguer en root sur le domaine. Toute réponse non satisfaisante entrainne la fermeture de la session et l'invalidation de la clef.