[Résolu] Sticky bit, droit propriétaire

moi4567 · 31-03-2017 10:38:36

Bonjour à tous

Dans le cadre de création d'un script de backup des utilisateurs je cherche à faire exécuter un script en tant que propriétaire. Le script modifiant créant un fichier dans un dossier appartenant au même propriétaire (que le que le script).

Pour ça je pense passer par le sticky bit à l'image de la commande passwd qui modifie les fichier /etc/passwd et /etc/shadow en tant que root.

Concrètement voilà la situation:

user@debian: ~/test$ ls -l

total 20

drwx------ 2 root root 4096 mars  31 10:52 other

-rwsr-xr-x 1 root root   30 mars  31 10:50 script.sh

-rwsr-xr-x 1 root root 9520 mars  31 10:50 script.sh.x

other: Dossier dans lequel doit être créé les fichiers
script.sh: Script à éxecuter par un utilisateur tier.
script.sh.x: Script compilé.

J'ai compilé le script car j'ai pu voir sur des forum anglophones que le scrity bit est désactiver sur les fichiers non compilés pour des raisons de sécurité.

script.sh:

#!/bin/bash

touch other/$USER

Lorsqu'un utilisateur éxecute le script (script.sh.x) je me prend un "Permission denied". Cela m'étonne un peux car la commande passwd a les même droits.
J'ai également essayé de mettre un sticky bit sur le dossier "other" mais le problème reste le même.

N'ayant jamais vraiment utiliser les sticky bit je pense avoir loupé quelque chose, je m'en remet donc à vous

Merci d'avance

Dernière modification par moi4567 (31-03-2017 13:04:08)

captnfab · 31-03-2017 10:55:00

Hello,

Je pense que tu parles du bit setuid (+s) putôt que du sticky bit (+t) ?

Le bit setuid ne fonctionne pas pour les scripts. Si tu veux que cela fonctionne, tu devras faire un programme binaire, ou alors, rajouter une entrée dans les sudoers pour pouvoir lancer ton script en tant que l'user que tu souhaites, et dans ce cas utiliser sudo.

PS: on ne « compile » pas un script, qu'est-ce que ton script.sh.x ? comment l'as-tu généré ?

moi4567 · 31-03-2017 11:00:32

captnfab a écrit :

Hello,

Je pense que tu parles du bit setuid (+s) putôt que du sticky bit (+t) ?

Le bit setuid ne fonctionne pas pour les scripts. Si tu veux que cela fonctionne, tu devras faire un programme binaire, ou alors, rajouter une entrée dans les sudoers pour pouvoir lancer ton script en tant que l'user que tu souhaites, et dans ce cas utiliser sudo.

Hello,

Quand je dit sticky bit je parle effectivement du setuid (je ne connais pas encore vraiment bien les termes).

Un script compilé (avec shc) "deviens" un binaire non?

La solution de passer par sudo me plais moyennement, ça voudrait dire que l'utilisateur aurait des droit root même en dehors du script. Bien que ça soit temporaire, l'idée me plais moyennement.

captnfab · 31-03-2017 11:07:38

Non, pas de droits root en dehors du script. Via le fichier sudoers, tu peux spécifier pour quelles commandes les droits sont accordés.

Ok pour shc, je ne connaissais pas cette solution. Je ne sais pas comment ça fonctionne, peut-être du coup qu'il y a un truc faisant que le +s ne marche pas…

J'ai testé shc, c'est un obfuscateur de code .sh, et visiblement, il n'est pas complètement fidèle au code… Je te le déconseille pour ce genre de manip.

moi4567 · 31-03-2017 11:18:36

Hum... Ok je vois, je pourrait donc faire un groupe concerné par l’exécution du script et ajouter ce groupe dans les droits sudo... Ça pourrait être une solution.
Je suis tombé un lien expliquant que par défaut ce n'est pas possible d'utiliser shc et de setuid directement derrière mais à priori c'est possible. Il y aurait une manip à faire.
Je vais chercher encore un peux dans cette vois et si ça ne passe toujours pas j'essaierais avec sudo voir ce que ça donne.

Dans tous les cas je reviens ici pour faire un compte rendu

captnfab · 31-03-2017 11:25:41

Ok, bien

Je pense quand même que la solution sudo est plus propre en matière de droits (à condition que le .sh soit dans une arborescence dont tous les parents appartiennent à root.)
En fait, c'est à ça que sert sudo… Permettre à certains utilisateurs/groupes, de lancer certaines commandes (toutes ou non) avec des droits (root ou non) différents des leurs, via mot-de-passe ou non.

moi4567 · 31-03-2017 12:48:24

C'est vrai mais d'un autre côté moins il y a de dépendance de paquets et mieux c'est.
Puis pour le coup, ça me parais moins propre en passant par sudo. Mais n'étant jamais été admin linux je ne peux pas vraiment en juger

captnfab · 31-03-2017 12:54:07

shc te crée un code C chiffré absolument incompréhensible, et te compile ça en binaire ELF. Il te fait une tambouille étrange pas 100% compatible avec le .sh.
Du coup, tu as un binaire, certes, mais tu ne sais pas ce qu'il fait ! Comment cela peut-il être propre ? Ce n'est même pas raisonnable

Entre une boîte noire et une petite configuration de sudo, du point de vue de la sécurité, y'a pas photo. Les boîtes noires sont *toujours* à éviter (sauf pour faire de la photo…)

moi4567 · 31-03-2017 12:58:55

Hum... J'avais pas vu ça comme ça... Mais effectivement il peux se passer n'importe quoi avec shc sans qu'on ne le sache.
Ok, vu comme ça je n'hésite plus, je prend la méthode sudo, merci à toi

Debian-facile

#1 31-03-2017 10:38:36

[Résolu] Sticky bit, droit propriétaire

#2 31-03-2017 10:55:00

Re : [Résolu] Sticky bit, droit propriétaire

#3 31-03-2017 11:00:32

Re : [Résolu] Sticky bit, droit propriétaire

#4 31-03-2017 11:07:38

Re : [Résolu] Sticky bit, droit propriétaire

#5 31-03-2017 11:18:36

Re : [Résolu] Sticky bit, droit propriétaire

#6 31-03-2017 11:25:41

Re : [Résolu] Sticky bit, droit propriétaire

#7 31-03-2017 12:48:24

Re : [Résolu] Sticky bit, droit propriétaire

#8 31-03-2017 12:54:07

Re : [Résolu] Sticky bit, droit propriétaire

#9 31-03-2017 12:58:55

Re : [Résolu] Sticky bit, droit propriétaire

Pied de page des forums