Administration de l'historique des commandes user

Bonjour :)

j'ai fait quelques recherches mais j'ai pas trouver ce que je cherche exactement,j'ai besoin d'un petit coup de main concernant deux petits sujets:

1- limiter les acces pour des utilisateurs , par exemple il ne peut exécuter que des commandes que je l'ai spécifier ( cat, ls , pwd ...) et l'enlever le droit d"exécution d'autre commande comme chmod par exemple.

2eme sujet: c'est la traçabilité de toutes les commandes exécutées sur la machines genre " history" mais avec plus de détails et archiver pour chaque utilisateur "comme un mouchard pour savoir qui fait quoi" 8-)

merci par avance :king:

:evil: On voit par là que les volontés dictatoriales se portent bien. Ce que tu cherches à faire n'existe pas. Tu t'es trompé d'OS. Retourne sous Windows.

Pour le premier point, c'est possible avec la commande sudo. Par contre le principe est tout est interdit sauf ce qui est expressément autorisé. Donc il te faudra mettre toutes les commandes qui peuvent être faites. Les droits sur les commandes sans sudo seront celle qu'un utilisateur peut faire sur ces fichiers à lui et ceux de son groupe et avec sudo ceux de administrateur.
Par exemple :
sans le sudo, l'utilisateur pourra faire un ls dans un dossier qui lui appartient ainsi qu'un chmod. Par contre si le dossier ne lui appartient pas, il ne pourra pas.
avec le sudo, l'utilisateur pourra le faire si root peut.

Pour le 2eme point, c'est plus délicat. Il existe des outils et il possible de le fair sans, mais cela demande une bonne connaissance des systèmes Linux.

Citation:

---

Envoyé par Flodelarab

:evil: On voit par là que les volontés dictatoriales se portent bien. Ce que tu cherches à faire n'existe pas. Tu t'es trompé d'OS. Retourne sous Windows.

---

La où je travaille, les deux sont en place par obligation légale. L'accès à certain serveurs doit être nominatif, pas de compte de service, et toutes les commandes doivent être traçable et surtout celle des administrateurs afin de s'assurer.
De plus certains utilisateurs ont des droits étendus pour leur éviter une demande aux administrateurs systèmes pour certaines opérations de maintenance. Tout le monde est content : moins de délai et comme nous savons ceux qu'il font, moins de suspicion en cas de crash lors d'une opération de maintenance.
Et une ancienne boite a du prouver, après un sabotage (un rm -rf / sur une dizaine de serveurs critiques) par un des administrateurs, que celui ci l'avait bien fait pour pouvoir le licencier pour faute lourde.

Citation:

---

doivent être

---

Tout est là. Dans l'expression "doivent être". La croyance de contrôle existe uniquement dans la tête délirante de quelques dictateur en puissance. Mais concrètement, y a rien. Aucune sécurité.

Citation:

---

Et une ancienne boite a du prouver, après un sabotage (un rm -rf / sur une dizaine de serveurs critiques) par un des administrateurs, que celui ci l'avait bien fait pour pouvoir le licencier pour faute lourde.

---

Et ben alors ? Je croyais qu'on pouvais contrôler ce que faisaient les utilisateurs ??? Malgré toutes vos manipulations fascistes, vous n'avez pas réussi à empêcher un sabotage ? En croyant contre-argumenter, tu donnes raison à ce que je dis.

Citation:

---

toutes les commandes doivent être traçables

---

Tu te fais rêver pour pas cher. Les commandes ne sont même pas obligées d'aller dans l'historique (cf OP). alors tracer ... c'est n'importe quoi.
Et quid des exécutables perso de l'utilisateur ? Si j'amène mon "cat" ?
Et quid des compilations de code perso ?
Et quid des scripts perso interprétés par des exécutables autorisés ?

La sécurité que tu décris est un dispositif de pieds nickelés qui n'existe que parce qu'il y a un chèque d'un nullard encore plus incompétent que celui qui met en place la prétendue solution de contrôle. Le jour où il y aura des procès pour incompétence dans les télécoms, ça va valser.
Malheureusement, ça n'arrivera jamais. Vous faîtes semblant de travailler.

man pam_tty_audit et les mans des outils liés
pour les droits, tu vas te faire chier, car il faut tout interdire, pusi lever les interdictions. Est-ce vraiment pertinent ? Pour des droits plus fins tu peux regarder du cotés des ACL.

Bonjour,

De manière naïve, je ferai un système proche de celui qui est utilisé pour /sbin (ou /usr/sbin). Par exemple, sous Debian par défaut, l'utilisateur de base n'a pas accès à /sbin. Il n'est pas présent dans le PATH et il n'y a pas accès.
En bref, ma méthode serait :

• chaque utilisateur ou groupe aurait un /bin propre à lui (et que lui peut aller l'utiliser et il faut bloquer l'accès à /bin) (possible que certains programmes dépendent d'un programme dans /bin, que vous auriez oublier et donc, ça va mal se passer).
• le PATH est réglé pour ne pointer que sur le /bin propre à l'utilisateur

Après, vous avez des solutions de jail, peut être de conteneur.

Citation:

---

Les droits sur les commandes sans sudo seront celle qu'un utilisateur peut faire sur ces fichiers à lui et ceux de son groupe et avec sudo ceux de administrateur.

---

J'ose croire que l'on peut placer une règle pour interdire absolument tout et ainsi, whitelister les commandes utiles.
Par contre, cela ne bloque pas les commandes de bases, car ça bloque que les commandes réalisées avec sudo, je pense.

Salut,

Je suis globalement d'accord avec l'avis de Flodelarab. Ce genre de politique du doigt tendu est contre-productive à plein de niveau mais passons.

Il est évidemment possible de faire ce genre de choses ... avec SELinux par exemple

Citation:

---

Envoyé par becket

Je suis globalement d'accord avec l'avis de Flodelarab. Ce genre de politique du doigt tendu est contre-productive à plein de niveau mais passons.

---

La ou je travaille, il ne s'agit pas de doigt tendu, mais de garde fou sur la production. Les serveurs de développement et de recette ne sont pas concernés
En effet, quand plusieurs centaines de personnes peuvent se connecter sur des serveurs en productions et effectuer des manœuvres potentiellement dangereuse, il faut s'assurer que la personne sait ce quelle fait et que dans l'organisation, elle a le droit de le faire. Un administrateur SAP a fait tomber un cluster PowerHA en faisant une mauvaise manipulation parce qu’il avait les droits root, demandant plusieurs heures aux administrateurs système pour être réparé.
Depuis, seul les administrateurs système ont les droits root. Une certaine délégation de droits a été faite auprès des administrateurs applicatifs afin qu'ils puissent redémarrer certains services systèmes sans passer par une demande auprès des administrateurs systèmes. Il était dommage d'attendre plusieurs heures pour débloquer une application, juste parce qu'ils n'avaient le droit de le faire.
Si de préférence, les applicatifs utilisent un compte spécifique, certains modules malheureusement nécessitent les droits root.
Même nous, administrateur système, nous évitons de travailler en root afin d'éviter une bourde. Personne n'est infaillible, même moi. Sur un système, nous nous sommes même créer un compte limité pour 99% des opérations, pour éviter une action dont les conséquences seraient très lourde et qui n'est possible qu'avec le compte root. La bourde a d'ailleurs était faite pendant la recette. C'est comme ça que l'on s'en est aperçu.

Pour certains systèmes, notamment bancaire, c'est une obligation légale de tracer et de stocker les accès et actions des administrateurs et des utilisateurs avec pouvoir. Cela est contrôlé de manière aléatoire par la cour des comptes.

Après, il est évident, que toutes ces sécurités ne feront pas long feu face à un attaquant ayant l'intention de nuire. Mais ce n'est pas l'objectif affiché. Pour cela d'autres systèmes sont déployé et si l'attaquant est parvenu à passer, il trouvera sûrement un faille sudo ou kernel à exploiter pour prendre le contrôle du système.

Citation:

---

Envoyé par becket

Il est évidemment possible de faire ce genre de choses ... avec SELinux par exemple

---

SE Linux permet de faire beaucoup de chose, mais demande une bonne connaissance de l'application. Lors de son activation, de très nombreux tests ont du être fait pour créer la configuration compatible avec l'application. Certaines mises à jour nécessitent d'ailleurs un modifications de celle-ci. Cela nécessite une infrastructure de pré-production solide pour faire les tests.

Salut gabriel21,

Mon post ne t'était pas destiné et je comprend très bien ces situations particulières. Dans le cadre de la demande initiale, il me semble que le demandeur ne comprend pas les niveau d'accès Unix ( par exemple la référence à chmod est assez révélatrice ) mais semble chercher une méthode pour imposer une forme de contrôle despotique sur les utilisateurs.

Concernant SELinux, c'est bien cela qui est merveilleux par rapport à l'outil, c'est qu'il est nécessaire de bien maîtriser les concepts associés à SELinux pour le mettre en route et qu'il est très compliqué de le metre à chaud sur une infra en prod.

salut,

Citation:

---

Envoyé par becket

(...) imposer une forme de contrôle despotique sur les utilisateurs.

---

la sécurisation d'un SI ne s’embarrasse pas de considérations morales, sinon on aurait des firewalls ouverts aux quatre vents, pour un plus grand respect des libertés fondamentales des paquets...

un administrateur par nature agit en root, c'est donc très difficile de l'empêcher d'agir de manière malveillante, le mieux qu'on puisse faire c'est conserver la traçabilité de ses actions, non pas pour le fliquer mais pour pouvoir incriminer l'admin malveillant en cas de pépin, la situation inverse serait la fête du slip ; un admin malveillant pourrait causer des dommages à l'entreprise sans être inquiété : on tiendrait là un vrai problème de sécurité.

il ne s'agit donc pas d'envisager la problématique en se positionnant du côté de la majorité des admins réglos, mais du côté de la minorité éventuelle d'admins malveillants : c'est lui qu'on veut contrecarrer à tout prix, parce que c'est lui qui si il parvient à ses fins peut mettre l'entreprise dans une cagasse noire.

donc effectivement c'est très difficile de mettre en place une traçabilité incontournable (voire infaisable), mais c'est clairement la meilleure option (la seule en fait) qui s'offre à la gouvernance sécu. pour se prémunir des rogue operators

un bastion d'accès aux machines de prod peut par ailleurs être relativement suffisant, se contentant alors de logguer les débuts/fins d'accès aux machines nominativement sans plus mettre le nez dans le détail des commandes.
on peut ainsi obliger l'admin à atterrir sur un shell loggué dans le bash_history, et bind ce dernier sur une socket en écriture direction le loghost, partant de là, même si l'admin parvient à échapper son shell, on doit quand même trouver quelques commandes indiquant qu'il a cherché à s'en extraire.