[wine] établir un changement automatique d'user (résolu)

[Yax]

Bonjour !

Voici un problème un peu spécifique, qui est probablement à soumettre à un xkcd-man.

J'ai voulu imposer des restrictions d'accès aux applications windows lancées par wine, alors j'ai créé un utilisateur "wineUser" ainsi qu'un groupe "wineGroup", lesquels ont des droits réduits. Ensuite j'ai réalisé un binaire capable d'éxécuter wine avec des paramètres, dont le propriétaire est "wineUser" afin de lui appliquer le bit "setuid". (Sur le lanceur évidemment, pas sur wine en lui-même... Mais j'avoue que malgré ça, je ne suis pas trop sûr de mon coup d'un point de vue sécurité ou cohérence unix...)

Le dossier du préfixe, quant à lui, a pour propriétaire le véritable utilisateur mais appartient au groupe "wineGroup" avec le bit "setgid" afin de résoudre les questions d'autorisations d'accès aux yeux du système. (Ouf, vous me suivez toujours ?)

Le gros souci se trouve au niveau du répertoire "/tmp/.wine-1000" !
Comme wine l'utilise pour y écrire ses fichiers temporaires, je l'ai également affecté au groupe "wineGroup" avec les droits 770 g+s, mais ça nelui plaît pas. Il me crache un : "wineserver: /tmp/.wine-1000 must not be accessible by other users".

Du coup je sèche. Je suis sûr que je m'y prends très mal et qu'il existe des solutions bien plus élégantes... Mais lesquelles ?
Ça me paraîtrait incroyable que tous les utilisateurs de cet <émulateur?> tolèrent que des éxécutables windows aient les mêmes privilèges qu'eux, quelqu'un a forcément une solution...

edit : Sujet marqué en résolu

[oktoberfest]

Salut,

tu fais des choses bien savantes en effet
Commençons par le début : que souhaites-tu faire ?

Si je comprends bien, tu souhaites que les programmes lancés via wine n'aient aucun droit d'écriture sur aucun répertoire à part... à part quoi au fait ?

tu dis que winUser a des droits réduits. C'est quoi des droits réduits ? Par défaut un utilisateur ne peut modifier que les fichiers qui lui appartiennent, je ne vois pas ce que tu veux encore réduire.
Ensuite qu'est-ce qui te gêne dans le fait qu'un programme soit lancé par wine ? Il n'aura pas plus de droit qu'un vi ou un bash.... Il ne cassera pas ton système, et n'effacera rien de plus que ce que toi tu peux effacer avec un malencontreux 'rm'.

[Yax]

Ah oui, mon récit n'était pas toujours très clair.

Donc en fait le but est que les applis wine ne puissent pas accéder aux dossiers faisant partie des groupes "users", et evidemment qu'ils ne puissent pas non plus accéder aux fichiers personnels des utilisateurs effectifs, ni utiliser les mêmes services.

Diable , mais pourquoi vouloir ça alors qu'en effet, mes applis linux peuvent tout autant mettre la pagaille si elles le souhaient ?

Alors en fait, il existe deux motifs :
- D'une part parce qu'à chaque LAN krosoftienne il y a toujours un gars qui impose sa version du jeu (car lui comme il ne l'a jamais acheté, il utilise une version no-CD crackée par un certain monsieur X avec un grand chapeau noir, laquelle ne reconnait malheureusement pas les parties créées par d'autres joueurs avec une version "saine")
- D'autre part parce que quand on est linuxien, souvent ça signifie qu'on s'y connaît un peu en informatique, et donc les gens nous demandent tout un tas de services... Les fois où on accepte gentiment dépanner, il arrive qu'on doive installer sur notre poste les trucs douteux qu'ils utilisent chez eux. (C'est triste, mais depuis que les windows sont en 64 bits, mon qemu n'a plus rien à se mettre sous la dent)

C'est donc bien un problème légitime de confiance vis-à-vis des applications windows qui m'incite à vouloir les isoler un peu.

[benjarobin]

Si j'ai bien compris, il veux que le programme lancé via Wine n'est pas accès au home de l'utilisateur.
Il lancerait wine avec l’utilisateur/groupe wineUser:wineGroup. Jusque l'a aucun souci de compréhension pour moi.
Je décroche quand tu parles de /tmp/.wine-1000, ce dossier correspond au dossier temporaire de wine associé à l'utilisateur 1000.
Comme je ne pense pas que 1000 soit l'uid de wineUser, je ne comprends donc pas la suite.
Je ne comprend non plus pas pourquoi tu parle de setgid.

Avant tout essaye de te connecter avec l'utilisateur wineUser (via su --login) et lance le programme (.exe)
Normalement un autre dossier devrait apparaître de /tmp

Le home associé à l'utilisateur de wineUser devrait être /prefix-wine/
Quelle est la sortie de :

Code : Tout sélectionner

grep wineUser /etc/passwd
grep wineGroup /etc/group

Il est possible que ton lanceur soit "foireux"

[Yax]

Oh là, il est vraiment très fâché le petit bonhomme de ton avatar.

Quand j'éxécute winecfg à l'aide du "lanceur", il fonctionne bien comme s'il avait prit les droits de wineUser.
En revanche j'ai limpression que quand on utilise le setuid sur une application et qu'elle créé un répertoire, celui-ci appartient à l'effective user. Est-ce bien ça ?

Je n'ai pas attribué de mot de passe à wineUser, vu qu'il n'est jamais sensé se logger. Du coup, je ne crois pas pouvoir faire un "su --login" dessus.
Sinon, voici l'output des autres commandes suggérées :

Code : Tout sélectionner

[Yax@localhost ~]$ grep wineUser /etc/passwd
wineUser:x:101:101::/home/wine:/sbin/nologin
[Yax@localhost ~]$ grep wineGroup /etc/group
wineGroup:x:101:Yax

Si la notion d'effective user a tant d'importance, alors il est sans doute compréhensible que wine puisse utiliser le dossier ".wine-1000" tout en étant lancé avec les droits de l'utilisateur 101, non ?
Enfin, j'sais pas. Des fois j'ai l'impression de ne plus rien comprendre en informatique. o_O

Sinon, j'ai testé un peu le lanceur avant de l'utiliser et il m'avait l'air de fonctionner correctement.
Mais on ne sait jamais, même s'il est simplet il a été fait à la va-vite, alors je ne suis pas à l'abri d'une coquille :

Code : Tout sélectionner

#include <unistd.h>
#include <cstdio>

int main(int paramCount, char** paramValue) {

	if (paramCount < 2) return 0;

	unsigned int argumentCount = paramCount - 1;
	char** argumentValue = new char*[paramCount];

	for (unsigned int index = 0 ; index < argumentCount ; index++) argumentValue[index] = paramValue[index + 1];
	paramValue[argumentCount] = nullptr;

	execvp(argumentValue[0], argumentValue);

	perror(argumentValue[0]);
	return -1;

}

[benjarobin]

Si c'est ceci ton lanceur, cela ne risque pas de fonctionner même avec un chown wineUser:wineGroup et un chmod ug+s
En effet uniquement le lanceur est exécuté avec l’utilisateur spécifié par le setuid. Tout processus découlant de ton lanceur sera actuellement lancé avce ton utilisateur. Tu peux le vérifié simplement avec htop/top/ps

[Yax]

Ah d'accord.
Mais pourquoi ? À quel niveau n'ai-je pas le comportement attendu ?

Je manque de connaissances en posix de toute façon, tant au niveau des droits unix que de la lib unistd. (d'ailleurs c'est pas facile de se documenter sur cette dernière)
C'est pour ça que je viens demander de l'aide ici. Que devrais-je faire pour obtenir les résultats escomptés ?

Merci beaucoup pour vos réponses !

[benjarobin]

Voilà le programme en C

Code : Tout sélectionner

#include <unistd.h>
#include <stdio.h>
#include <malloc.h>

#define APP_UID  101
#define APP_GID  101

int main(int argc, char *argv[])
{
	int i;
	char** lstArgs = 0;
	
	if (argc < 2) {
		return 1;
	}

	if (setgid(APP_GID) != 0)
	{
		perror("Fail to setgid");
		return 2;
	}
	if (setuid(APP_UID) != 0)
	{
		perror("Fail to setuid");
		return 3;
	}
	
	lstArgs = (char**)calloc(argc, sizeof(char*));

	for (i = 0 ; i < argc - 1; i++)
	{
		lstArgs[i] = argv[i + 1];
	}

	execvp(lstArgs[0], lstArgs);

	perror(lstArgs[0]);
	return 4;
}

Le compiler :

Code : Tout sélectionner

$ gcc -std=c89 -Wall -Wextra -O2 test-wine.c -o test-wine

Lui donner les droits root:

Code : Tout sélectionner

# chown root:root test-wine
# chmod ug+s test-wine

Attention personnellement je ferait en sorte que le programme lancé soit obligatoirement wine, c'est à ta convenance.

[Yax]

Super merci.
Heureusement qu'il existe des mecs balèzes sur cette terre !

J'ai confiance en ton code, mais je l'essairai une autre fois parce que là il est l'heure de rendre visite à Alice dans son pays.

Ah oui au fait, je suis 999% d'accord avec l'idée d'imposer le lancement de wine uniquement. (En fait il y a aussi parfois besoin de lancer "wineserver -k" et "winecfg" en tant que wineUser, c'est pour ça que mon programme était assez libertain. Mais je préfère faire trois versions, c'est mieux.)

Merci encore pour tout, et à bientôt !

[Yax]

Ok ça fonctionne !

En revanche wine utilise les variables d'environnement qui, elles, correspondent toujours au vrai utilisateur ayant éxécuté le lanceur.
Donc il faut au moins redéfinir :

USER=wineUser
HOME=/home/wine
LOGNAME=wineUser
XAUTHORITY=/home/wine/.Xauthority

Et copier le fichier ".Xauthority" de l'utilisateur dans le dossier "/home/wine", sinon le serveur X ne trouve pas de display. (Ou peut-être qu'il vaut mieux faire un lien au cas où son contenu changerait ?)
Il est également important de s'assurer que wine pourra accéder en écriture à un répertoire "/home/wine/.local"

Donc tout est OK, je marque le sujet en résolu.
Merci pour tout !