Déjà je suis très surpris d'apprendre que jail n'est pas géré par le système
jail effectue sa propre sécurité. Ca n'a rien a voir avec la politique de sécurité établis sur le système.
Forcément tu veux te la péter mais tu lis de traviole les réponses. J'ai dis qu'utiliser jail ce n'était PAS utiliser la politique de droits sur le système (vu que tu rajoute une couche supplémentaire pour empêcher l'utilisateur de faire quelquechose).
Dans mon esprit Jail était une fonctionnalité kernel d'isolation par virtualisation+containers
Tout a fait. Un peu comme SE Linux en fait.
SE Linux a rien a voir avec un jail ou un chroot.
Mais même sur des authentifications très différentes de SE Linux, comme par exemple kerberosV ou pfauth, j'ai du mal à voir en quoi elles ne sont pas gérées par le système.
Il n'y a pas d'authentification "se linux" (mais il y a un module pam qui met le contexte de sécurité lors de l'authentification au système).
Tu es sur de comprendre de quoi tu parles ou tu essaie juste de mettre des noms de technos pour faire genre ?
Pour ton info kerberos a rien a voir avec selinux. (et pfauth, je sais pas, jamais utilisé).
Parcequ'il y a deux façons de les interpreter :
- soit tu changes alégrement les points de vues quand ca t'arrange, passant de l'entreprise au réseau familial, de la protection par pur mot de passe à l'élévation des privilèges et du distinguo uid au distinguo privilèges un peu au moment ou ca t'arrange.
Je passe au réseau familial quand on me dis "mais non ca parle que tu réseau familial". Si tu as des récrimination, va les faires a notre grand copain (ou lis correctement les commentaires).
- Soit tu confonds des notions de sécurité par groupe avec des notions de sécurité par AC
Ta première remarque n'est pas exclusif de la seconde, donc je vois pas trop l'intérêt du "soit".
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 , ... ?
enfin sur le manuel de freebsd je trouve pas ton abbrévation AC. je suis peut être pas doué ...
J'ai simplement constaté de visu que tous les postes qui essayaient de mettre en exergue les différences entre le système d'évaluation des droits par AC et les sytèmes type sudo, se faisaient violamment moinsser.
Violamment... On est venu avec les battes de baseball pour moinsser...
j'ai simplement dit que la confusion qui semblait régner entre les anciens modes de sécurité et les nouveaux chez les lecteurs de LinuxFR me faisait peur.
Peur... qui est un mot très soft hein ...
Tu l'as pas dis, tu l'as juste sous entendu très "violamment" pour reprendre un mot qui t'es cher.
- 1) Le système qui permet de savoir quel utilisateur a le droit d'effectuer quelle commande n'est pas nécessairement accessible à l'ensemble des utilsateurs. On peut même penser qu'un administrateur va en limiter l'accès aux seuls gens qui en ont besoin. Comme pour tout autre système.
Le monsieur disait que c'était pas a destination de l'entreprise. Faudrait se décider un moment...
Bon supposons que c'est pour les entreprises.
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. Je peux le comprendre, mais ça veut pas vraiment dire que c'est une best practice.
(On a pire a notre boulot, mais on va pas dire "c'est trop top génial". On sait que c'est de la merde).
Ps: ca doit être fun lors des prises de congés pour savoir qui dois rester joignable et qui peut partir XD
- 2) En entreprise, parcourir tout un arbre de droits, sur le LDAP domaine puis le recouper avec les droits et les restrictions locales d'une machine pour savoir qui peut ou ne peut pas lancer telle commande est loin d'être trivial. C'est même un problème NP complet je pense.
Parcourir un arbre et faire un check, un problème NP complet ? Tu as fumé quoi ? Tu m'en passes ?
On demande pas de trouver un chemin hamiltonien hein...
Il permet de façon évidente de trouver quel autre utilisateur peut lancer la commande dont on a besoin.
"Ah lui je le connais bien. Bon il est pas admin, ils lui ont filé parce qu'il en avait besoin. Il va me la faire cette commande, il est sympa".
Et boum un système modifié (mal de préférence).
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".
Mais aussi, et c'est peut être même plus interressant que la fonctionnalité évidente, il permet de sortir une liste des utilisateurs qui ont des droits qu'ils ne devraient pas avoir.
audit de sécurité toussa... (on peut déjà le faire sans cette fonctionnalité. encore heureux!).
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.
Ah moins que tu penses à un attaquant. qui se faufile entre deux audits de sécurité, et que quand nous on lancera la commande avec notre user normal (en oubliant d'avoir auparavant fait le su kivabien) on voit, sur la liste des 10aines d'admin et d'utilisateurs un type louche, et qu'on ait envie de remonter sur l'ensemble des tickets et interroger tous les collègues pour savoir qui c'est et si c'est normal qu'il ait ce droit là, si oui pour combien de temps toussa.
oui ca peut etre une idée. C'est marrant, je suis pas sur que c'est la première qui me viendrais à l'esprit. Je sais pas pourquoi.
Vu la complexité que peut prendre les règles de sécurité dans un environnement d'entreprise, un tel outil est très précieux. Je confirme en plus qu'il n'y a aucun utilitaire unix à ma connaissance capable de donner la liste complète (domaine + local) des comptes capables de faire un rm sur tel fichier.
Sous windows peut être, j'en sais rien.
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 ?
4) Au domicile, un tel système permet surtout à l'adminsitrateur local (généralement connu sous le nom de papa) de vérifier que les différents acteurs de son réseau ne peuvent pas, par exemple, enlever la protection parentale, continuer à surfer après 22h30, installer n'importe quoi.
Même chose que plus haut.
On sait déjà le faire sans avoir besoin de ce truc.
Il permet aussi aux enfants de savoir si ce qu'ils sont en train de faire (installer un jeu par exemple) peut être débloqué seulement par papa, ou bien par papa ET maman. Une fois de plus je n'ai jamais vu une telle fonctionnalité sur un Unix.
En même temps, j'aimerais bien savoir dans quelle famille, maman a le droit de débloqué tel soft, papa d'autres soft, et les deux encore une autre populations de soft...
Et si tu les as pas vu sous unix (pourtant au départ orienté gros serveurs d'entreprises multi utilisateurs), peu que dans un contexte familial ben désolé ca sert vraiment a rien.
Tu vas demander à maman de l'installer. Ah ca marche pas, bon ben je vais demander à papa (et déjà ca voudrait dire qu'il y a deux comptes différents pour papa et maman, avec des droits différents, ce qui doit etre 0.00001% des cas).
(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é.)
[^] # Re: On se demande qui est l'idiot/enflure
Posté par briaeros007 . En réponse au journal On connait un des brevets microsoftiens que linux viole. Évalué à 2.
jail effectue sa propre sécurité. Ca n'a rien a voir avec la politique de sécurité établis sur le système.
Forcément tu veux te la péter mais tu lis de traviole les réponses. J'ai dis qu'utiliser jail ce n'était PAS utiliser la politique de droits sur le système (vu que tu rajoute une couche supplémentaire pour empêcher l'utilisateur de faire quelquechose).
Dans mon esprit Jail était une fonctionnalité kernel d'isolation par virtualisation+containers
Tout a fait.
Un peu comme SE Linux en fait.
SE Linux a rien a voir avec un jail ou un chroot.
Mais même sur des authentifications très différentes de SE Linux, comme par exemple kerberosV ou pfauth, j'ai du mal à voir en quoi elles ne sont pas gérées par le système.
Il n'y a pas d'authentification "se linux" (mais il y a un module pam qui met le contexte de sécurité lors de l'authentification au système).
Tu es sur de comprendre de quoi tu parles ou tu essaie juste de mettre des noms de technos pour faire genre ?
Pour ton info kerberos a rien a voir avec selinux. (et pfauth, je sais pas, jamais utilisé).
Parcequ'il y a deux façons de les interpreter :
- soit tu changes alégrement les points de vues quand ca t'arrange, passant de l'entreprise au réseau familial, de la protection par pur mot de passe à l'élévation des privilèges et du distinguo uid au distinguo privilèges un peu au moment ou ca t'arrange.
Je passe au réseau familial quand on me dis "mais non ca parle que tu réseau familial". Si tu as des récrimination, va les faires a notre grand copain (ou lis correctement les commentaires).
- Soit tu confonds des notions de sécurité par groupe avec des notions de sécurité par AC
Ta première remarque n'est pas exclusif de la seconde, donc je vois pas trop l'intérêt du "soit".
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 , ... ?
enfin sur le manuel de freebsd je trouve pas ton abbrévation AC. je suis peut être pas doué ...
J'ai simplement constaté de visu que tous les postes qui essayaient de mettre en exergue les différences entre le système d'évaluation des droits par AC et les sytèmes type sudo, se faisaient violamment moinsser.
Violamment... On est venu avec les battes de baseball pour moinsser...
j'ai simplement dit que la confusion qui semblait régner entre les anciens modes de sécurité et les nouveaux chez les lecteurs de LinuxFR me faisait peur.
Peur... qui est un mot très soft hein ...
Tu l'as pas dis, tu l'as juste sous entendu très "violamment" pour reprendre un mot qui t'es cher.
- 1) Le système qui permet de savoir quel utilisateur a le droit d'effectuer quelle commande n'est pas nécessairement accessible à l'ensemble des utilsateurs. On peut même penser qu'un administrateur va en limiter l'accès aux seuls gens qui en ont besoin. Comme pour tout autre système.
Le monsieur disait que c'était pas a destination de l'entreprise. Faudrait se décider un moment...
Bon supposons que c'est pour les entreprises.
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. Je peux le comprendre, mais ça veut pas vraiment dire que c'est une best practice.
(On a pire a notre boulot, mais on va pas dire "c'est trop top génial". On sait que c'est de la merde).
Ps: ca doit être fun lors des prises de congés pour savoir qui dois rester joignable et qui peut partir XD
- 2) En entreprise, parcourir tout un arbre de droits, sur le LDAP domaine puis le recouper avec les droits et les restrictions locales d'une machine pour savoir qui peut ou ne peut pas lancer telle commande est loin d'être trivial. C'est même un problème NP complet je pense.
Parcourir un arbre et faire un check, un problème NP complet ? Tu as fumé quoi ? Tu m'en passes ?
On demande pas de trouver un chemin hamiltonien hein...
Il permet de façon évidente de trouver quel autre utilisateur peut lancer la commande dont on a besoin.
"Ah lui je le connais bien. Bon il est pas admin, ils lui ont filé parce qu'il en avait besoin. Il va me la faire cette commande, il est sympa".
Et boum un système modifié (mal de préférence).
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".
Mais aussi, et c'est peut être même plus interressant que la fonctionnalité évidente, il permet de sortir une liste des utilisateurs qui ont des droits qu'ils ne devraient pas avoir.
audit de sécurité toussa... (on peut déjà le faire sans cette fonctionnalité. encore heureux!).
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.
Ah moins que tu penses à un attaquant. qui se faufile entre deux audits de sécurité, et que quand nous on lancera la commande avec notre user normal (en oubliant d'avoir auparavant fait le su kivabien) on voit, sur la liste des 10aines d'admin et d'utilisateurs un type louche, et qu'on ait envie de remonter sur l'ensemble des tickets et interroger tous les collègues pour savoir qui c'est et si c'est normal qu'il ait ce droit là, si oui pour combien de temps toussa.
oui ca peut etre une idée. C'est marrant, je suis pas sur que c'est la première qui me viendrais à l'esprit. Je sais pas pourquoi.
Vu la complexité que peut prendre les règles de sécurité dans un environnement d'entreprise, un tel outil est très précieux. Je confirme en plus qu'il n'y a aucun utilitaire unix à ma connaissance capable de donner la liste complète (domaine + local) des comptes capables de faire un rm sur tel fichier.
Sous windows peut être, j'en sais rien.
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 ?
4) Au domicile, un tel système permet surtout à l'adminsitrateur local (généralement connu sous le nom de papa) de vérifier que les différents acteurs de son réseau ne peuvent pas, par exemple, enlever la protection parentale, continuer à surfer après 22h30, installer n'importe quoi.
Même chose que plus haut.
On sait déjà le faire sans avoir besoin de ce truc.
Il permet aussi aux enfants de savoir si ce qu'ils sont en train de faire (installer un jeu par exemple) peut être débloqué seulement par papa, ou bien par papa ET maman. Une fois de plus je n'ai jamais vu une telle fonctionnalité sur un Unix.
En même temps, j'aimerais bien savoir dans quelle famille, maman a le droit de débloqué tel soft, papa d'autres soft, et les deux encore une autre populations de soft...
Et si tu les as pas vu sous unix (pourtant au départ orienté gros serveurs d'entreprises multi utilisateurs), peu que dans un contexte familial ben désolé ca sert vraiment a rien.
Tu vas demander à maman de l'installer. Ah ca marche pas, bon ben je vais demander à papa (et déjà ca voudrait dire qu'il y a deux comptes différents pour papa et maman, avec des droits différents, ce qui doit etre 0.00001% des cas).
(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é.)