[Resolu] Sécurité utilisateur application à distance ?

Support Debian
#1

Salut,

J’ai (encore) un petit soucis, j’essaye de lancer une application sous un utilisateur restreint en local, et je me sers de SSH pour le X forwarding.

J’ai mis un shell restreint en place pour cet utilisateur: /bin/rbash pour qu’il n’est pas accès à n’importe quoi sur mon système.

Cependant je viens de faire un test et j’ai vu qu’il etait très simple pour lui de le changer en faisant simplement la commande: chsh.

Et même si l’application ou l’utilisateur n’a pas le mot de passe de son compte, c’est possible en passant par le navigateur de fichier en faisant un copier/coller d’un autre shell dans son /home et un chmod +x sur celui ci, executer et hop on a un shell non restreint :frowning:

Quelqu’un aurait il une solution SVP?

Bye !

#2

si tu lui mets /usr/sbin/nologin comme shell, ça ne passe pas ?
ou encore scponly (paquet éponyme à installer).

#3

hello mattotop,

Entrez la nouvelle valeur ou « Entrée » pour conserver la valeur proposée Interpréteur de commandes initial [/bin/rbash]: /usr/sbin/nologin /usr/sbin/nologin n'est pas un interpréteur de commandes valable.

Donc /usr/sbin/nologin ne fonctionne pas.

Quand à scponly, oaip ca a l’air interressant, a tester.

Mais ese que si j’ai un shell comme ca, je pourrais toujours lancer mes apps graphique?

Merci ++

#4

J’ai dit une connerie: aucun de ces deux shells ne permet l’execution en remote, justement.
Mais il y a un truc que je ne pige pas en relisant: en quoi rbash est il insuffisant ? Le fait qu’ils puissent executer chsh ne leur donne pas le droit d’accés à la configuration de leur shell: ils peuvent toujours lancer chsh, mais comme ça n’a aucun effet…

#5

Hello,

Ben je fais:

[code]su user1

chsh

/bin/bash

exit[/code]

Et je me reconnecte, et j’ai un shell bash… :frowning:

#6

Bon, ben tu viens de m’apprendre un truc fâcheux pour la sécurité: chsh est en suid, effectivement.
Alors j’ai fais chez moi un chmod -s /usr/bin/chsh et aprés ça, le gars ne peut plus changer de shell et reste bloqué en rbash.

#7

L’alternative que je n’ai pas testée qui doit être plus propre est de limiter les shells authorisés en modifiant le fichier /etc/shells, pour n’y laisser que les shells que tu autorises à tes users. Root n’est pas affecté et peut toujours choisir ce qu’il veut comme shell.

#8

Yop,

Arf la voila l’explication ^^

Je ne connais pas trop ‘suid’ mais il me semble avoir entendu que c’etait pour donner à un programme les droits root.

Ese que ca mérite un rapport de bug ou autres? (cela me semble vraiment merdique pour la sécu)

Sinon tu connais de bons trucs pour vraiment restreindre au maximum un utilisateur ?

Merci en tout cas :wink:

#9

[quote=“Claire.F”]Yop,

Arf la voila l’explication ^^

Je ne connais pas trop ‘suid’ mais il me semble avoir entendu que c’etait pour donner à un programme les droits root.[/quote] C’est indirectement ça. En fait, un executable qui a le bit suid s’execute avec pour identité celle du possesseur de l’executable (en l’occurence root).
Il y a la même chose pour le faire s’executer avec un id de groupe donné. [quote=“Claire.F”] Ese que ca mérite un rapport de bug ou autres? (cela me semble vraiment merdique pour la sécu)[/quote] Ben la multiplication des bits suid est trés suivie par les équipes de sécurité. Le fait que chsh soit en suid est AMA certainement volontaire. Il y a surement eu une longue discussion sur le sujet, mais tu peux effectivement poser des questions (je n’ai rien trouvé concernant ça en cherchant deux minutes).
Mais tu sais, même avec un shell complet, un utilisateur normal sans sudo ne peut pas casser grand chose. C’est l’avantage de linux, même quand les protections de surface sont contournées, le systême reste protègé au coeur. [quote=“Claire.F”] Sinon tu connais de bons trucs pour vraiment restreindre au maximum un utilisateur ?[/quote] Bien il y en a beaucoup, mais linux est déjà à la base trés sûr. Ta precaution avec un shell restreint et pas mal.
Si tu veux aller plus loin:
linux.developpez.com/cours/secur … e=sommaire
(que je n’ai jamais eu le temps de lire, m’a l’air un peu ancien)

et surtout:
debian.org/doc/user-manuals#securing
qui est trés bien pour comprendre les concepts et les enjeux, assez complet quoi qu’obsolète parfois, et bien sûr particulièrement adapté à debian.

[quote=“Claire.F”]Merci en tout cas :wink:[/quote]De rien.

#10

Yep,

Oki doki, je demanderais à l’occasion sur la mailing list FR, mais oui je pense comme toi que ca a du déja être discuté en profondeur.

Merci pour la doc :slightly_smiling: je vais lire tout ça :stuck_out_tongue:

Bonne nuit :wink:

#11

Comme je suis présentement en Guadeloupe, il était 17h30 quand tu m’as dit “bonne nuit”, donc un peu en avance. :mrgreen:
Bonne lecture.

Tu devrais mettre [résolu] dans le titre.

#12

Hello,

Ah oui un peut tôt effectivement ^^

Je rajoute [Resolu].

Ciao.

#13

Arf, sous l’utilisateur avec le shell restreint en faisant un ps aux on peut voir tout les processus de tout les utilisateurs :frowning:

#14

A priori, je crois que si tu chroote ssh, ce n’est pas le cas, mais ça sous entend que tu aies un chroot par utilisateur.
debian.org/doc/manuals/secur … nv.fr.html