CBS / Enfin un outil qui nous facilite la vie.

Posté par  . Modéré par Benoît Sibaud.
Étiquettes :
0
1
juin
2002
Linux
CBS est un systeme client-serveur qui permet aux utilisateurs de lier les ports TCP/UDP en dessous de 1024.
Un simple fichier de configuration permet d'autoriser tel ou tel utilisateur a ouvrir tel ou tel port.
Dans la pratique, un utilisateur particulier pourra donc etre autorisé à lancer un service réseau tel que sshd, ftp, httpd sans être root.

Pour moi, deux avantages à utiliser cet outil :
- sécurité : le service réseau est lancé avec les droits de cet utilisateur. Un pirate pourra bien s'amuser a exécuté un shell via un bogue de sécurité de ce service, il se retrouvera confiner sur le système, car il ne sera pas root.

- délégation des droits de l'administrateur : on peut sans danger donner à un utilisateur spécialisé (par exemple le webmaster), le droit de recompiler, d'exécuter et de relancer son apache sans qu'il nous casse les pieds.

Pour l'instant, CBS tourne sur GNU/linux et NetBSD.

Note du modérateur : le pirate ne sera confiné que si le service est chrooté. Dans le cas contraire, il va chercher une faille locale.

Aller plus loin

  • # chroot ET iptables -m owner

    Posté par  . Évalué à 10.

    Je suis d'accord avec le modérateur pour dire qu'il faut combiner CBS et chroot.

    De même, il faut aussi utiliser "iptables -m owner" pour empecher le serveur internet chrooté de communiquer localement et de pouvoir exploiter par socket d'autres services IP de la machine locale ou du réseau local.

    Enfin rappelons que les capabilities du kernel 2.4
    ont été encore enrichies pour pouvoir donner facilement à un utilisateur un des privilèges de root, sans donner tous les privilèges en même temps.

  • # c'est quoi un port IP ?

    Posté par  . Évalué à 10.

    C'est pas plutôt un port de ca couche transport (TCP/UDP) dont ça parle ?

    Ou c'est qu'on lie un port avec une IP pour autoriser certains utilisateur à ouvrir certaines connexions très précises ?

  • # GruïK p0w4H !

    Posté par  . Évalué à 10.

    Houlà ... je ferais pas trop confiance à ce truc moi ...

    Une bonne grosse lib qui remplace l'appel bind() du système ... beurk.

    Autant écrire des applis qui gèrent la séparation de privilèges, style ssh.

    Et puis une appli, même root, après chroot et filtrage de la plupart des syscalls (avec systrace par ex.) ne peut plus faire grand chose ...

    • [^] # Re: GruïK p0w4H !

      Posté par  (site web personnel) . Évalué à 0.

      Ben t'as les sources, donc tu peux vérifié si c'est bien codé.

      Et puis si cette problématique peut être traitée une bonne fois pour toute, c'est quand-même mieux. Chaque gus qui reprogramme un truc spécifique pour son serveur risque de faire des erreurs qui conduiront à des trous de sécurité. Utiliser une librairie ou n'importe quel moyen de réutilisation du code permet d'obtenir une meilleure qualité de code, car il est utilisé par plus de monde, ce qui veux dire plus de tests, plus de hackers pour débugger ...

  • # historique

    Posté par  (site web personnel) . Évalué à 10.

    Je me pose la question depuis quelques temps...
    Pourquoi est ce que seul root peut ouvrir un port < 1024? d'où vient ce choix historique ?

    • [^] # Re: historique

      Posté par  (site web personnel) . Évalué à 10.

      Les ports <1024 sont réservés pour les services connus comme smtp, pop, ftp, http et j'en passe...

      Cela permet d'être sûr que tout le monde utilise les mêmes ports... et qu'il n'y ait pas d'embrouille (et de petits plaisantins/utilisateurs non root qui "bloquent" un port)
      Bref, ça permet de standardiser !

      Par contre, de quand ça date exactement, je ne peux pas te dire... mais c'est bien vieux ! (au niveau informatique et réseaux bien sûr).

  • # Redirection de port

    Posté par  . Évalué à 10.

    Je ne vois pas l'interet de ce truc.
    Pour faire tourner un service ayant besoin d'un port < 1024 sans etre root, il suffit de binder ce service sur un port utilisateur et d'effectuer une redirection de port.

    Par exemple pour Apache, je le fais ecouter 127.0.0.1:8000 uniquement, et une regle du firewall se charge de rediriger 127.0.0.1:8000 sur l'IP externe.

    Ca marche sur n'importe quel OS disposant d'un noyau avec un firewall (quasiment tous les OS libres), ca ne necessite pas d'installer quoi que ce soit, c'est stable, et ca ne ralentit pas du tout les traitements.

    • [^] # Re: Redirection de port

      Posté par  . Évalué à 10.

      CBS permet visiblement d'autoriser les ports en fonction des utilisateurs.

      La encore, pourquoi reinventer la roue? Sous OpenBSD-current, les regles de firewall peuvent dependre de l'uid/gid. Linux sait aussi faire ca depuis des lustres.

      Si IPF ne sait pas le faire, pourquoi ne pas ajouter cette fonctionnalite plutot que d'inventer une espece de bibliotheque en userland necessitant de recompiler tous les serveurs?

      Eh oh, on est en 2002, il faut se reveiller, l'epoque ou seul tcp-wrappers existait pour faire du filtrage, c'etait il y a 10 ans!

      • [^] # Re: Redirection de port

        Posté par  . Évalué à 2.

        oui. Et pour que l'utilisateur paul puisse relancer apache, rien de tel que sudo pour lancer rc.httpd en root ! Comme ça il fera pas n'importe quoi sur ce foutu port 80 !

        • [^] # Re: Redirection de port

          Posté par  (site web personnel) . Évalué à 0.

          euh oui mais non.

          Soit paul n'a pas accès à la conf apache en écriture et il n'a aucune raison d'avoir à relancer apache.

          Soit paul a accès à la conf apache et c'est tres dangereux un tel sudo. Imagine qu'il change la ligne user de la conf apache ? paf, il peut se faire passer pour qui il veut. Le but est bien justement de ne pas lancer le démon en root (si c'est paul qui lance apachtl il peut y avoir ce qu'on veut dans la config il ne pourra pas se faire passer pour un autre utilisateur (genre celui de la base de donnée).

  • # chtite question technique

    Posté par  . Évalué à 1.

    Est-ce que le Hurd a une solution élégante pour le problème que traite CBS ?
    Si oui c'est gràce aux tokens, grace au micro-noyau ou grace à la présence des 2 simultanément ?

    • [^] # Re: chtite question technique

      Posté par  . Évalué à 10.

      hum...
      Oui, puisque c'est la pile tcp-ip (pfinet) qui autorise ou non de binder un port donné pour un programme, suivant les jetons de sécurité qu'elle a.

      Je ne sais pas exactement comment cela fonctionne à l'heure actuelle, mais il est parfaitement possible au moins dans la théorie de donner à des programmes le jeton "peut binder le port 42". Je ne sais pas trop comment implémenter ça en pratique de manière propre, mais oui, ça me semble très possible.

      Beaucoup d'autres possibilités existent sous GNU, puisqu'une application peut donner des jetons à une autre par exemple (cf addauth, je suis root, je fais 'addauth 456 uid 0' et le process 456 gagne les droits root en cours d'exécution), ...

      J'espère que quelqu'un pourra me compléter, mais mieux c'est de demander sur #hurd@OPN ou sur une ML...

  • # Patch kernel -- Linux Network Pseudo ACL

    Posté par  . Évalué à 10.

    Il existe depuis quelques temps deja, un patch permettant d'autoriser les ports < 1024 pour les utilisateurs appartenant a un gid particulier (par exemple gid: net).

    Attention cependant car a partir du moment ou un utilisateur a le gid, il peut binder n'importe quel port < 1024. Il faut donc avoir confiance sur cet utilisateur.

    voila l'url, avec une petite doc pour la mise en oeuvre:
    http://original.killa.net/infosec/acls/(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.