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) ?

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 ...

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)

Si tu fais le truc avec noexec, même ton exemple d'sh ne marchera pas

Par contre, c'est trop compliqué comme solution. Tu n'as qu'a chmoder correctement tes executables...

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

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...

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 :

Modifié le 30 mai 200619 a par zoto

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...

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

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 :(

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 ? ) 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

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...

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.

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.

OK donc c'est bien ce que j'expliquais et c'est nickel.

Reste l'histoire des montages de périphs UMS (et toute autre idée que vous aurez )

Normalement c'est bien avec udev. Regarde aussi du côté de /etc/security/console.perms

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 (reste à migrer les mails de l'assoc' de Foxmail vers Thunderbird )

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

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

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

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

Modifié le 31 mai 200619 a par naparuba

Chez moi j'ai comme tuXXX :

/lib/ld-2.3.6.so /home/root/ls
/home/root/ls: error while loading shared libraries: /home/root/ls: failed to map segment from shared object: Operation not permitted

Hum... je pense que ca a du être bloqué après la RA3.0, je testerai sur sid avec un noyau 2.6 et un 2.4 pour voir. (la RA3.0 est un 2.4.21).

2.4.21 ??? le dernier 2.4 est un 2.4.32

elle est si vielle que ça la RH3.0

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à

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 ...

Ouais, avec rbash c'est clair qu'ils vont être limités, surtout si tu veux lancer des interfaces graphiques.

Sinon, c'est assez spécifique, mais on peut faire ça avec SELinux.

/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.)