Votre avis sur la sécurité d'une appli en suid user

[Jacques-]

Bonsoir,

Petite question sur le niveau de sécurité apporté par une solution :

1) Une application installée sur un serveur doit pouvoir être lancée de 2 façons :
- en mode daemon via un script dans init.d
- manuellement à des fins de test
2) Pour des raisons de sécurité, cette appli est installée (et lancée via init.d) sous un compte utilisateur quelconque (mettons user), ne possédant ni shell ni mot de passe valide (!! dans /etc/shadow)
3) Aucun problème pour la lancer sous ce compte en mode daemon
4) Le souci : pouvoir lancer ce programme depuis un compte utilisateur quelconque sans que les fichiers de logs, de config, etc... puissent être modifiés par cet utilisateur.
5) Solution proposée :
Droits des fichiers de config / log / etc... en user:user et 644
Ces fichiers sont situés dans un répertoire dont les droits sont 755 appartenant à user:user
L'utilisateur normal n'a donc normalement pas la possibilité de les modifier ou de les effacer.
Le problème est que si l'appli est en 755, l'utilisateur toto qui lancera l'appli en mode test ne pourra pas écrire dans les logs puisqu'ils ne lui appartiennent pas.
La solution à laquelle je pense est de mettre cette appli setuid "user" ce qui règle le problème d'écriture dans les logs, n'oblige pas à mettre un mot de passe et un shell sur ce compte.
Bref, je ne vois pas de risques inconsidérés à cette méthode.

Quel est l'avis des experts sécurité sur ce point ?
Y-a-t-il un trou dans la raquette auquel je ne pense pas ?

Merci d'avance

Jacques

[Gaston]

Bonsoir,
as tu jeté un coup d'oeil à "sudo"

G.

[Jacques-]

Merci de participer.
J'y ai pensé, mais sudo implique de disposer de ce programme sur toutes les machines où l'appli peut être installée, et cela je ne le maîtrise pas.
Et si un admin ne désire pas utiliser sudo, je me retrouve coincé à l'installation (pas envie de créer des configs pour chaque cas potentiels).

Jacques

[Walkyrie_II]

Puisque ton pb est : les droits sur le fichier de log,
il me semble plus logique de traiter la source du pb (le fichier de log) plutôt que les éléments venant agir sur ce pb et qui peuvent varier dans le temps et/ou être oubliés.

Voir commande chattr pour attribut étendu sous linux

http://www.lea-linux.org/cached/index/A ... endus.html

Dans ton cas
append only (a), « ajouter seulement » ─ réservé à root
Protège le fichier contre la suppression de contenu : on ne peut que lui en ajouter.

[tomtom]

Hello,

Le problème des setuid est toujours le même : Ca permet d'augmenter les privilèges.
Tout bug dans ton executable pourra etre exploité par un utilisateur sans droits pour essayer de faire des choses pas bien avec les droits de user.

Par exemple, passer des paramètres obscurs, essayer des débordements de tampon, remplir la log jusqu'à ecrasement/rotation, etc...

- Sudo ne règle pas tellement le problème, sauf que tu peux controler qui a le droit de le faire....

- Les attributs avancés peuvent résoudre les problème, mais on ne les trouve pas non plus partout...

Pourquoi ne pas ajouter une option à ton appli pour spécifier le fichier de log, différent pour les cas de test que la log "de production" ?

t.

[S0l0]

4) Le souci : pouvoir lancer ce programme depuis un compte utilisateur quelconque sans que les fichiers de logs, de config, etc... puissent être modifiés par cet utilisateur.
5) Solution proposée :
Droits des fichiers de config / log / etc... en user:user et 644

et l'attribut sticky t'y as penser

[Jacques-]

Pour ce qui est des attributs avancés, je n'y avais pas pensé mais je ne suis pas sur de les trouver partout. De plus, il y a un mécanisme de rotation automatique des logs dans l'appli, ce qui fait que append seul me paraît problématique, le fichier étant renommé puis recréé vide ensuite lorsque la taille critique est atteinte.

Pour sudo, étant donné que je ne connais pas le nom des utilisateurs "normaux" susceptibles de lancer le programme, cela revient à donner les droits à tout le monde, donc je ne vois pas de grosse différence avec un suid "user", avec en plus l'obligation de disposer du programme sur la machine, et la modification forcée d'un fichier de config lié à la sécurité de la machine lors de l'installation, ce qui peut comporter des risques.

Pour l'option de lancement spécifique indiquant le fichier de log, je ne maitrise pas le code de l'appli, mais c'est une solution à explorer.

Sinon, le risque de faire crasher l'appli existera toujours, elle est normalement lancée en tant que service sous un compte normal (ce qui n'était pas le cas avant, elle tournait sous root, ce qui me chagrinait fortement, d'où les modifs au démarrage du service). Comme elle communique sur le réseau, le risque de la planter via le réseau existe et c'est pour cela que je ne veux pas la laisser tourner en root. Si un utilisateur non root veut la lancer pour des tests, et qu'elle est en suid "user", je ne vois pas (mais c'est ma question) de risque supplémentaire au mode de fonctionnement en tant que service, à part effectivement la saturation des logs, ou un plantage répété. Mais si on est en démarrage manuel en mode test, c'est que c'est soit du debug, soit on n'est pas encore en production, donc ça me dérange pas trop.

Je vais regarder tout de même la piste d'un paramétrage spécifique pour le fichier de log, ce qui ne serait pas déconnant puisqu'on veut faire du test, donc ne pas mélanger les logs... pourquoi pas.

Merci de vos idées

Jacques

[jibe]

Salut,

Je vais regarder tout de même la piste d'un paramétrage spécifique pour le fichier de log, ce qui ne serait pas déconnant puisqu'on veut faire du test, donc ne pas mélanger les logs... pourquoi pas.

Je pense effectivement que c'est la meilleure idée. Pour la mettre en oeuvre si tu ne maitrises pas le code de l'application, un truc tout bête me vient à l'esprit : tu y as peut-être bien déjà pensé, ou alors je n'y ai pas assez réfléchi (pas du tout, à vrai dire) et il y a un gros problème auquel je ne pense pas... Je te le livre malgré tout :

Tu remplaces tout simplement ton fichier de log par un lien symbolique. Et ce lien, tu le modifies par un script qui lance ensuite l'application.

Et m*** ça ne marche pas ! J'y pense en rédigeant : il y a le problème de rotation des logs qui va faire tout foirer... A moins d'y trouver un remède ? Bon, ce n'est peut-être pas la bonne idée...

[Jacques-]

Les logs se trouvent dans un répertoire dédié sous /var/logs (pour que le user ait les droits en écriture).
Et le fichier de config indiquant où se trouvent le répertoire de log est dans /etc/répertoireDedié avec les mêmes droits.

Mais à priori, je dois pouvoir forcer un fichier de config avec un paramètre en ligne de commande, donc comme celui-ci est lisible pour tout le monde, il est facile d'en faire une copie dans le répertoire de l'utilisateur, de modifier les champs concernés à coup de sed ou awk et de passer ce fichier au lancement de l'application.
Avantage, plus de suid ou de sudo, c'est portable dans tous les cas, et les logs de test seront distincts des logs de l'appli lancée en mode service...
Ca me plaît bien comme ça, je pense que je vais continuer à creuser cette piste.
Pour le lien symbolique, c'est dommage mais effectivement cela ne marchera pas puisque je dois avoir les droits en écriture dans le répertoire de conf, ce qui n'est pas le cas (risque de destruction du fichier par accident ou non autrement).

Merci de vos avis et bon week-end ensoleillé

Jacques

[Franck78]

Salut,

D'après mes lectures à droites et à gauche sur la façon de faire sur un 'unix':
deux cas simple:

-le programme est destiné à 'tous' (par exemple un serveur) et est lancé avec les privilège root. A charge pour lui d'ouvrir fichiers et sockets nécéssaires puis de dropper ses privilèges.

-c'est un user qui lance le programme et dans ce cas c'est pour son usage perso. Le programme n'a que les privilèges de user. De mémoire même pas le droit de créer de serveur sur les ports (<1024 ?).

Essayer de distribuer des permissions partout pour obtenir un 'service serveur' lancé par un user n'est pas une bonne idée. Autant que le programme lui même lache ses privilèges dès que possible.

[Jacques-]

Pour Franck :
Le contexte : Un serveur qui tournait (jusqu'à ce que je mette les doigts dedans) en root, les ports utilisés sont au dessu de 1024, donc pas de soucis pour le faire touner en utilisateur normal.

Depuis que j'ai pris le truc en charge, le service sera lancé sous un compte normal, de façon à éviter des risques d'escalade de privilèges via le réseau. Le User utilisé ne peut pas se logguer, et il est propriétaire des fichers de config (un répertoire dédié dans /etc) et des logs (idem, répertoire dédié dans /var/logs).
Mais pour des raisons de test, il peut être nécessaire de redémarrer le programme manuellement, et cela pas forcément en tant que root.
Donc, pour faire cela, le service doit d'abord être arrêté (pour éviter d'interrompre justement le programme pas un user quelconque, que ce soit volontaire ou non) et le programme lancé sous un compte quelconque.
Le problème qui restait était de pouvoir écrire dans les logs, puisque justement on est dans ce dernier cas en train de faire des tests, donc les logs sont précieux. Comme les logs n'appartiennent pas à l'utilisateur possédant le programme, et qu'ils ne peuvent être modifiés que par cet utilisateur (ou root bien sur), j'avais pensé à placer ce prog en suid User, pour que les logs soient inscrits avec les droits du propriétaire du programme quelque soit l'utilisateur l'ayant démarré.

A priori, il y a une autre piste réalisable en changeant le fichier de config pour définir un autre chemin pour les logs, qui seront dans ce cas dans le répertoire utilisateur.
De la façon dont le prog est lancé maintenant, il lâche tout de suite ses privilèges pour tourner sous un compte normal, mais les tests devant être réalisés sans forcément être root, j'avais un soucis de droits, d'où ma demande d'avis.

Jacques

[Franck78]

j'avoue pas vraiment suivre tes explications.

Puisque tu as placé le bit suid et que le proprio de l'executable est 'User' ou est le problème? Le prog tourne avec les privilèges (l'identité) de 'User' et pas ceux de celui qui a lancé prog.
Tu obtiens bien ce que tu veux.

[Jacques-]

Oui, si je mets le suid sur le programme, j'obtiens ce que je veux, sauf que l'usage du suid est toujours sujet à interrogation, d'où ma question s'il existait une autre possibilité de le faire, ou si la solution envisagée comprenait un trou de sécurité que je ne voyais pas.
Je recherchais des idées ou des avis, dans le but d'améliorer la solution trouvée.
Si je peux modifier le nom du fichier de log, c'est ce que je ferais, sinon à priori le suid User ne comporte (comme je le pensais) pas plus de risque que de laisser tourner l'appli en User comme c'est le cas désormais.

Jacques

[Franck78]

Oui, si je mets le suid sur le programme,
Jacques

"suid root" d'accord. Parceque le programme est root. Mais quand il passe de tartempion1 à tartempion2....