Est il un moyen pour les processus non-root lier à « privilégié » ports (< 1024) sur Linux ?

Question

C'est très ennuyeux d'avoir cette limitation sur mon développement de la boîte, quand il ne sera jamais tous les utilisateurs autres que moi.

Je suis conscient de la norme des solutions de contournement, mais aucun d'entre eux n'exactement ce que je veux:

1. authbind (La version présente dans Debian testing, 1.0, prend en charge IPv4 uniquement)
2. À l'aide de la iptables cible de REDIRECTION pour rediriger un faible port à port élevé (le "nat" table n'est pas encore mis en œuvre pour ip6tables, l'IPv6 version d'iptables)
3. sudo (Exécuté en tant que root est ce que j'essaie d'éviter)
4. SELinux (ou similaire). (C'est juste ma boîte de dev, je ne veux pas introduire beaucoup de complexité.)

Donc, est-il une simple variable sysctl pour cela, ou suis-je juste pas de chance?

EDIT: Dans certains cas, vous pouvez utiliser les capacités pour ce faire.

Answer 1

Ok, merci pour les gens qui ont souligné les capacités du système et de l' CAP_NET_BIND_SERVICE de la capacité. Si vous avez un noyau récent, il est en effet possible de l'utiliser pour lancer un service non root, mais aussi de lier faible ports. La réponse courte est que vous n':

setcap 'cap_net_bind_service=+ep' /path/to/program

Et puis, à tout moment program est exécuté par la suite, il aura l' CAP_NET_BIND_SERVICE de la capacité. setcap est dans le paquet debian libcap2-bin.

Maintenant, pour les mises en garde:

1. Vous aurez besoin d'au moins un noyau 2.6.24
2. Cela ne fonctionnera pas si votre fichier est un script. (c'est à dire, utilise un #! la ligne de lancer un interpréteur). Dans ce cas, autant que je comprends, vous devez appliquer la capacité de l'interprète exécutable lui-même, qui est bien sûr la sécurité de cauchemar, car tout programme d'aide que l'interprète aura la capacité. Je n'étais pas en mesure de trouver votre propre façon simple de contourner ce problème.
3. Linux va désactiver LD_LIBRARY_PATH sur n'importe quel program disposant de privilèges élevés comme setcap ou suid. Donc, si votre program utilise sa propre .../lib/, vous pourriez avoir à regarder dans une autre option, comme la redirection de port.

Ressources:

• capabilities(7) de la page de manuel. Lire ce long et difficile, si vous allez utiliser des capacités dans un environnement de production. Il y a vraiment de délicats détails de la façon dont les capacités sont héritées au travers d'un exec() appels qui sont détaillés ici.
• setcap page de man
• "Lier les ports inférieurs à 1024, sans racine sur GNU/Linux": le document qui Le premier m'a orienté vers setcap.

Remarque: RHEL d'abord ajouté cette v6.

Answer 2

Vous pouvez faire une redirection de port. C’est ce que je fais pour un serveur de stratégie Silverlight s’exécutant sur une machine Linux

Answer 3

Le niveau moyen est de les faire "setuid", de sorte qu'ils commencent en tant que root, puis ils jettent que les privilèges de root dès qu'ils ont tenu à le port, mais, avant de commencer à accepter les connexions. Vous pouvez voir de bons exemples dans le code source d'Apache et de l'INN. Je me suis dit que Lighttpd est un autre bon exemple.

Un autre exemple est Postfix, qui utilise plusieurs démons qui communiquent à travers les tuyaux, et seulement un ou deux d'entre eux (qui n'ont que très peu, sauf à accepter ou à émettre octets) exécuter en tant que root et le reste de l'exécuter à un moindre privilège.

Answer 4

Les fonctionnalités de fichiers ne sont pas l'idéal, car ils peuvent casser au bout d'un package de mise à jour.

La solution idéale, à mon humble avis, devrait être une capacité à créer un shell avec héritables CAP_NET_BIND_SERVICE ensemble.

Voici un peu alambiqué manière de faire ceci:

sg $DAEMONUSER "capsh --keep=1 --uid=`id -u $DAEMONUSER` \
     --caps='cap_net_bind_service+pei' -- \
     YOUR_COMMAND_GOES_HERE"

capsh utilitaire peut être trouvé dans libcap2-bin paquet dans Debian/Ubuntu distributions. Voici ce qui se passe:

• sg des changements de groupe efficace IDENTIFIANT de l'utilisateur daemon. Ceci est nécessaire car l' capsh feuilles GID inchangée et nous avons certainement ne voulez pas.
• Ensembles de bits "maintenir les capacités de l'UID du changement".
• Les changements UIDE $DAEMONUSER
• Gouttes tout en majuscules (a ce moment, tous les bouchons sont toujours présents en raison de l' --keep=1), à l'exception pouvant être héritées cap_net_bind_service
• Exécute votre commande ("--"séparateur)

Le résultat est un processus spécifié d'utilisateur et de groupe, et cap_net_bind_service privilèges.

Comme un exemple, une ligne d' ejabberd script de démarrage:

sg $EJABBERDUSER "capsh --keep=1 --uid=`id -u $EJABBERDUSER` --caps='cap_net_bind_service+pei' -- $EJABBERD --noshell -detached"

Answer 5

Deux autres de simples possibilités:

Il y a un vieux (démodé) solution du "un démon qui se lie sur un bas port et des mains le contrôle de votre démon". Il est appelé inetd (ou xinetd). Les inconvénients sont:

• le démon doit parler sur stdin/stdout (si vous ne contrôlez pas le démon -- si vous n'avez pas la source -- puis c'est peut-être un écueil, bien que certains services peuvent avoir un inetd-indicateur de compatibilité)
• un nouveau processus de démon est fourchue pour chaque connexion
• c'est un maillon supplémentaire dans la chaîne

Pour:

• disponible sur n'importe quel vieux UNIX
• une fois que votre administrateur système a configuré la config, vous êtes bon pour aller sur votre développement (lorsque vous re-construire votre démon, pourriez-vous perdre setcap capacités? Et ensuite, vous aurez à revenir à votre admin "s'il vous plaît, monsieur...")
• le démon n'a pas à s'inquiéter de la mise en réseau des trucs, juste a parler sur stdin/stdout
• pouvez configurer pour exécuter le démon comme un utilisateur non-root, comme demandé

Une autre alternative: un piraté-proxy (netcat ou même quelque chose de plus robuste) à partir du port privilégié à certains arbitraire élevées port où vous pouvez exécuter votre cible démon. (Netcat est évidemment pas une solution de production, mais "juste ma boîte de dev", non?). De cette façon, vous pouvez continuer à utiliser un réseau capable de la version de votre serveur, aurait seulement besoin de root ou sudo pour lancer proxy (au démarrage), ne serait pas en s'appuyant sur les complexes et/ou potentiellement fragile capacités.