Saluxfr,
J'ai un tout petit serveur dédié que j'admin comme je peux sur lequel plusieurs user(amis) cohabitent.
J'ai installé à chacun un daemon torrent (transmission), un serveur web (nginx), un serveur ftp (vsftpd), un proxy (squid);
Biens que ces utilisateurs soient des amis et ne soient pas censés se faire du mal j'aimerai être sûr qu'aucun d'entre eux
ne peux accéder à l'espace ou aux daemons de l'autre. Aussi j'aimerai que si un attaquant extérieur arrivait à prendre la main sur le serveur via une faille sur un daemons (au hasard transmission), il ait toutefois un accès extrêmement réduit au système (au mieux à ce dont transmission avait absolument besoin pour fonctionner au pire aux droits de l'user concerné)
Le problème c'est que mon serveur a un processeur Atom et 2Go de RAM donc lancer des machines virtuelles dessus me semble impossible.
J'ai essayé de set-up tout ça avec la commande chroot mais les dépendances de bibliothèques, et les besoins de chacun des daemons m'ont semblés très compliqués,
j'ai aussi trouvé des outils commes LXC, fakechroot, Linux-VServer etc.. mais je n'ai pas su faire un choix.
Bref, tout ceci m'a l'air assez compliqué et je n'ai pas l'impression qu'une solution très rapide et facile existe pour mon problème, est-ce bien le cas ?
je suis pret à passer du temps à comprendre un des outils sus-mentionné (ou un autre) et à faire des scripts pour automatiser un ajout d'utilisateur mais
je voudrais au moins être sûr d'avoir choisi l'outil le mieux adapté.
Je pense savoir qu'il y a plusieurs sysadmin qui trainent dans le coin, quelle solution choisiriez vous et pourquoi ?
# lapin
Posté par Adrien . Évalué à 2.
Je comprend pas très bien le besoin en fait.
Dans l'état actuel (par ex. sous Debian), transmission tourne en tant qu'utilisateur « transmission ». Donc si un pirate en prend le contrôle, il sera restreint à cet utilisateur (qui doit avoir un shell en /bin/false si je me souviens bien). Si chaque utilisateur lance sont propre transmission, alors c'est un peu différent.
Si tu veux isoler encore plus les choses, alors il faut passer à plus compliquer, comme tu le mentionnes, comme les machines virtuelles, avec d'autres contraintes (par ex. pour les machines virtuelles, ça fera 1 système par service à maintenir, au lieu d'un seul actuellement…)
Mais as-tu vraiment besoin de ça ? à toi d'estimer si la sécurité de base te suffit ou pas.
[^] # Re: lapin
Posté par NeOwA . Évalué à 1. Dernière modification le 29 juillet 2013 à 09:52.
Niveau sécurité de base je n'ai besoin de casi rien.
Mais j'aimerai faire les choses d'un manière sécurisée et propre, pour la connaissance que ça représente.
Si je comprends bien ce que tu me dis : il suffit que je lance plusieurs instances de chacun des daemon (en admettant que ce soit possible, je crois savoir que transmission ne le gère pas) avec des users différents (alice_ftp; alice_proxy; bob_ftp; bob_proxy etc..) pour chaque couple user/daemon et cela sera suffisant ?
Le problème auquel je me heurte avec ça c'est que certains daemon le supportent mal (cf. transmission) et d'autres (comme nginx) sont très bien fait pour le multi-site mais sont eux aussi lancés une seule fois. Ce qui oblige les utilisateurs à partager le même daemon.
[^] # Re: lapin
Posté par Adrien . Évalué à 3.
Perso je ferais ça comme ça :
– un seul démon FTP, qui tourne en tant qu'utilisateur « ftp ».
– un seul serveur web, qui tourne en tant que « www-data »
– un transmission, qui tourne en tant que « transmission ».
Ensuite la séparation des utilisateurs se fait par chaque démon : ftp -> droit utilisateur du système, web -> htpasswd, transmission -> à voir. Si transmission ne permet pas d'authentification par utilisateur, alors il faudra le lancer pour chaque utilisateur (par ex. avec cron).
Lancer des démon plusieurs fois pour chaque utilisateur n'est pas vraiment une meilleure solution d'un point de vue sécurité : si le démon FTP a une faille, alors alice-ftp, bob-ftp, etc. seront vulnérable aussi…
[^] # Re: lapin
Posté par Anonyme . Évalué à 2.
C'est là qu'on se rend compte que le monde du Web c'est toujours autant de la merde…
vsFTPd, SSHd et plein d'autres daemons sont capables de tourner en root et de forker en fonction de l'utilisateur qui se connecte. Les serveurs Web ? Non.
[^] # Re: lapin
Posté par NeoX . Évalué à 2.
ca depend en fait de la techno du site web.
il existe des modules apache (fast_cgi, wsgi) qui peuvent tourner en tant qu'utilisateur
c'est juste une histoire de configuration et de droit sur les fichiers
# Proxmox?
Posté par ChickenKiller . Évalué à 1.
Personnellement je fonctionne avec des containers proxmox.
L'avantage est la faible "surconsommation" par rapport à tout faire tourner sur le même système.
Le problème est bien sûr comme dit plus haut qu'il faut maintenir autant de systèmes que d'utilisateurs ou services suivant le découpage que tu souhaites.
[^] # Re: Proxmox?
Posté par NeOwA . Évalué à 1.
Le problème avec ce genre de solution c'est que ça utilise de la virtualisation hardware (si j'ai bien compris) ce que mon processeur ne semble pas supporter (Atom D425 - http://ark.intel.com/Products/VirtualizationTechnology)
[^] # Re: Proxmox?
Posté par NeoX . Évalué à 2.
sauf que là ce n'est pas pour faire de la virtualisation (KVM) mais plutot pour faire des containers (OpenVZ avec Proxmox, ou LXC comme dit plus bas)
tu n'as donc pas besoin de la virtualisation hardware.
par contre il te faut
1 adresse MAC, une adresse IP, un compte root
mais ainsi tu pourras dire que tel container n'a droit qu'à X Go de disque dur, Y Mo de RAM
et bien sur isoler tes utilisateurs avec chacun son OS, ses libs, et ses services.
ex un utilisateur peut avoir tomcat, l'autre juste lighthttpd, un troisieme apache
# LXC
Posté par Amaury . Évalué à 4.
Vu les caractéristiques matérielles de ta machine je pencherai sur une base LXC dans la mesure ou la charge "perdue" pour faire tourner le système de virtualisation est négligeable.
Il y a néanmoins quelques inconvénients :
- à chaque utilisateur son container LXC, avec son arbo dupliquée (un fs CoW pourrait aider ?), à oublier sur ta machine si tu es limité en espace disque ou si tu as beaucoup d'amis
- l'isolation entre containers est perfectible, il est possible de s'évader d'un LXC avec un peu de motivation (ça s'améliore)
- la mise en place d'un container, sans être d'une complexité extrême, n'est pas triviale.
J'ajoute qu'en 2013 il semble tout à fait inutile (sauf cas d'usage spécifique) d'installer un serveur FTP dont on sait qu'ils sont souvent mal sécurisés, dans la mesure où SSH fournit grosso modo les même fonctionnalités, avec une chiffrement par défaut.
[^] # Re: LXC
Posté par NeOwA . Évalué à 1.
Merci pour ton retour sur LXC.
C'est la solution dont on me parle le plus et qui me semble bien correspondre, je pense que je vais me lancer là dessus.
Pour ton idée de fs CoW : Tu voudrais dire que LXC pourrait ainsi ne pas avoir besoin de dupliquer tous les fichiers kernels/bibliothèques/(et autre fichier qui n'a pas vocation a être modifié, ou pas souvent) mais ne dupliquerait que les fichiers propres à chaque utilisateurs ? Si oui, l'idée me semble très bonne mais je vais me renseigner avant sur les désavantage (quid d'une màj du kernel, d'une lib, … ?)
Concernant le FTP, je suis assez d'accord avec toi, la raison principale étant qu'ils y accèdent la plupart du temps via leur navigateurs (qui à ma connaissance ne supportent pas SFTP ni FTPS) c'est une sorte de partage dans le cloud du pauvre car j'ai eu la flemme d'installer un sgbd+owncloud/etc.
[^] # Re: LXC
Posté par Monocular . Évalué à 1.
Je ne sais pas ce qu'il en est des autres navigateurs, mais Firefox est tout à fait capable de naviguer dans un répertoire sftp.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.