Jump to content

Restreindre les exécutables dispos


Recommended Posts

Je cherche un moyen de faire en sorte que les utilisateurs d'un ordi ne puissent exécuter que les programmes que j' (l'admin) aurai installés.

J'ai pensé à simplement mettre /home (et éventuellement /tmp) sur une autre partition montée avec noexec.

Mais comme je ne suis pas un gourou de la sécurité je sais pas si c'est suffisant. Genre, est-ce qu'un "sh ./lancer-programme" avec "lancer-programme" qui contient un appel vers un prog dans /home/user fonctionnerait (vu que sh est pas dans /home) ?

Link to post
Share on other sites

Oui, le noexec est une bonne idée.

Il faut aussi le mettre pour le /tmp, /var et pour toutes les partitions où un utilisateur normal peut écrire sans qu'il y ait d'exécutables.

Par contre certains programmes sont assez problématiques pour cela. Gentoo qui lance les compilations dans le /var, fluxbox qui lance un script dans le /home du user ...

Link to post
Share on other sites

La distrib sera Ubuntu Dapper.

Pour /var tu es sûr qu'un utilisateur standard peut écrire dedans ?

Et concernant une possibilité de contourner cette protection... ? (genre je viens de penser à des progs sur une clé USB... faut que je vois comment Ubuntu monte les périphs amovibles, surtout en FAT)

Link to post
Share on other sites

Euh je crois que le chmod est complètement à côté de la plaque :modoreussi:

Ce que je veux c'est que le système soit accessible (gnome firefox etc) mais que les utilisateurs ne puissent pas utiliser d'autres exécutables qu'ils auraient DL par exemple...

Link to post
Share on other sites

Salut

Il te faut utiliser les acl .

Ça permet plein de chose .

Tu as 10 utilisateurs, tu autorise 3 a utiliser le fichier, 4 a en faire ce qu'il veulent, les autres ne peuvent que le voir .

Sous KDE il y a meme ça d'integré directement :) .

a+

PS : une capture sur ma machine :

8599c170f8ffdf3e11c115b31de20fb2.png

Link to post
Share on other sites

Attention, mettre le /tmp en noexec, ça fera merder dpkg qui a besoin de lancer des ptits scripts dans le /tmp lors des aptitude upgrade et consors.

Pour /var, /var/tmp est généralement accessible.

De toutes façons même si le /tmp était en noexec :

theocrite@pascal$ grep logical_tmp /proc/mounts 
/dev/mapper/logical_tmp /tmp ext3 rw,nosuid,nodev,noexec,data=ordered 0 0

theocrite@pascal$ chmod +x coucou.sh 
theocrite@pascal$ ./coucou.sh 
-bash: ./coucou.sh: Permission denied
theocrite@pascal$ sh coucou.sh 
coucou

EDIT : Tiens j'avais jamais remarqué que tu habitait à Issy, à 4 bornes de chez moi...

Link to post
Share on other sites

Euh je crois que le chmod est complètement à côté de la plaque :modoreussi:

Ce que je veux c'est que le système soit accessible (gnome firefox etc) mais que les utilisateurs ne puissent pas utiliser d'autres exécutables qu'ils auraient DL par exemple...

Autant pour moi, j'avais pas compris le problème. Je croyais que tu voulais restreindre l'accès aux prog installés :(
Link to post
Share on other sites

Bon si j'ai bien compris jamais je n'aurai un truc parfait... Bon je suis pas le seul à connaître Linux mais le seul à "maîtriser" (maîtrise-t-on jamais Linux ? :modoreussi:) et je pense que déjà mettre /home en noexec éliminera quasiment tout risque.

Quelqu'un sait-il où changer les options de montage des USB amovibles dans Dapper (et si possible les forcer pour éviter un remount -o exec) ? J'ai essayé dans /etc/udev/rules.d/40-permissions.rules mais ça n'est visiblement pas pris en compte.

L'ordi en question est celui du BDE de mon école, si vous saviez à quel point ça me fait plaisir de le faire migrer :) (Bon le trésorier rebootera une fois par semaine sous Win pour faire les comptes mais c'est déjà ÉNORME je pensais pas réussir à convaincre mon cher prez' si facilement). C'est surtout pour éviter ce qui se passe actuellement avec le XP actuel (complètement vieux et mourrant et en ruine) c'est-à-dire que l'ordi sert régulièrement à autre chose que les activités associatives auxquelles il est destiné.

P.S. : j'habite plus chez les parents maintenant :transpi:

Link to post
Share on other sites

Pour tout ce qui est scripts, il est toujours possible de lancer le programme (sh, perl...) avec en argument le fichier, on exécute le programme et non le script...

Link to post
Share on other sites

Oui c'était toute la substance de ma remarque (« Genre, est-ce qu'un "sh ./lancer-programme" avec "lancer-programme" qui contient un appel vers un prog dans /home/user fonctionnerait (vu que sh est pas dans /home) ? ») mais pour revenir là-dessus :

* je fais un script dans /home/sufflope qui ne contient que des commandes shell et des appels à des exe "légitimes" : oui il sera parfaitement executé par "sh ./monscript" mais... tant mieux c'est un comportement que je veux bien tolérer

* je fais un script qui appelle un exe illégitime (/home/sufflope/embeter-admin) : bah là comme l'exe est sur une partoche noexec, ça marche pas

si j'ai faux sur le point 2 là en effet c'est dommage pour moi. Sinon ça me va.

Link to post
Share on other sites
si j'ai faux sur le point 2 là en effet c'est dommage pour moi. Sinon ça me va.

Tous les exécutables (sauf les scripts lancés à la main avec commande fichier) seront désactivés.

Link to post
Share on other sites

Bon j'ai installé une Ubuntu avec ce type de réglages et en créant un utilisateur sans droits d'admin.

Il n'a pas accès via le menu aux réglages via gksudo (ils n'apparaissent même pas, et évidemment sudo marche pas) et j'ai DL une archive de Fx et le script de lancement ne marche pas (il me répond « /bin/sh : mauvais interpreteur » alors que sh fonctionne évidemment bien).

Ça m'a l'air tout bon ça :) Vivement jeudi que je fasse ma mission d'évangélisation :keskidit: (reste à migrer les mails de l'assoc' de Foxmail vers Thunderbird :reflechis: )

Link to post
Share on other sites

Pour tout ce qui est scripts, il est toujours possible de lancer le programme (sh, perl...) avec en argument le fichier, on exécute le programme et non le script...

Et pour tout ce qui est non script:

/lib/ld-2.3.2.so /ton/executable/qui/est/monte/sur/une/partition/noexec

Donc le noexec ne tient pas bien longtemps mais bon c'est toujours efficace en première mesure :reflechis:

Link to post
Share on other sites
Et pour tout ce qui est non script:

/lib/ld-2.3.2.so /ton/executable/qui/est/monte/sur/une/partition/noexec

Donc le noexec ne tient pas bien longtemps mais bon c'est toujours efficace en première mesure :transpi:

Non ça ça ne marche pas...

 # mount /tmp -o remount,noexec
# mount | grep /tmp
none on /tmp type tmpfs (rw,noexec)
# cp /bin/ls /tmp/ls
# ls -l /tmp/ls
-rwxr-xr-x 1 root root 58576 mai 31 09:20 /tmp/ls
# /lib/ld-2.4.so /tmp/ls
/tmp/ls: error while loading shared libraries: /tmp/ls: failed to map segment from shared object: Operation not permitted

Link to post
Share on other sites

Bah j'aurai juré le contraire. Merci en tout cas.

EDIT: après un piti test, ca marche sur ma Red Hat Entreprise 3.0. Je testerai sur ma sid ce soir pour voir.

Si ca marche pas, ca va stracer pour voir qui bloque et qui ne bloque pas :transpi:

Link to post
Share on other sites

2.4.21 ??? le dernier 2.4 est un 2.4.32

elle est si vielle que ça la RH3.0

Oui oui, du 2.4.21, (enfin c'est une distrib du cru maison mais basée sur de la RH3.0).

Enfin bon ca tourne pas trop mal pour un serveur, je ne me souviens plus ce qu'avaient aportées les versions suivantes...

PS: on vire un peu du post original là :pleure:

Link to post
Share on other sites

peut-être que changer le shell de ton utilisateur de bash vers rbash (ou bash -r) pourrait t'aider un peu niveau problématiques de sécurité ?

man rbash (sur une ubuntu) pour en savoir plus, c'est assez brutal ... :byebye:

Link to post
Share on other sites
/lib/ld-2.3.2.so /ton/executable/qui/est/monte/sur/une/partition/noexec
Non ça ça ne marche pas...
EDIT: après un piti test, ca marche sur ma Red Hat Entreprise 3.0. Je testerai sur ma sid ce soir pour voir.
Chez moi j'ai comme tuXXX :
noexec Do not allow direct execution of any binaries on the mounted file system. (Until recently it was possible to run binaries anyway using a command like /lib/ld*.so /mnt/binary. This trick fails since Linux 2.4.25 / 2.6.0.)
Link to post
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...