Journal Tame et OpenBSD

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
67
20
juil.
2015

Juste un petit journal pour vous signaler un post intéressant de Theo de Raadt (leader d'OpenBSD) sur la liste "Tech".
Dans ce post il présente tame, un outil sur lequel il travaille depuis un certain temps et qui vise à réduire les droits d'un programme afin de diminuer la surface d'attaque.

Theo commence par évoquer très brièvement les alternatives et pourquoi, selon lui, elles ne conviennent pas.

  • Capsicum nécessite de réécrire profondément le programme qui sera protégé.
  • D'autres approches (comme systrace) manquent de granularité et surtout bloquent les droits pendant toute la durée d'exécution du programme alors qu'il faudrait être permissif lors de l'initialisation pour ensuite verrouiller lors de l'exécution (main loop).
  • Les approches du style seccomp-bpf obligent à écrire un nouveau programme pour observer le programme initial. Selon Theo "That is insane".

Après ce dégommage succinct des alternatives il présente sa propre solution. Il s'agit d'un nouvel appel système qui serait inséré dans le programme, entre l'étape d'initialisation et la boucle principale d'exécution. Cet appel spécifie quels groupes de droits sont accordés au programme (et si le programme tente une opération non permise il est immédiatement killé).
Parmi ces groupes de droits on trouve des trucs comme TAME_MALLOC (droits d'allocation mémoire), ou TAME_RW (droits read-write sur le ystème de fichiers) etc, etc.

Cela ressemble donc bougrement aux Capabilities POSIX qui découpent les privilèges des programmes root en une trentaine de droits différents. Mais, à première vue, il y a deux différences.
Tout d'abord, au lieu d'être défini par des attributs étendus, l'appel système tame est invoqué directement par le code du programme, après l'initialisation, et cela permet de réduire les droits au strict minimum nécessaire à l’exécution.
Ensuite les groupes de droits définis par Theo ne suivent pas les frontières des Capabilities POSIX. Peut-être sont-ils mieux adaptés et plus facile à utiliser par les programmeurs ?

Dans son post Theo cite 29 programmes qui ont été modifiés pour inclure l'appel à tame : cat pax ps dmesg ping ping6 dc diff finger from id kdump logger script sed signify uniq w wc whois arp authpf bgpd httpd ntpd relayd syslogd tcpdump traceroute.
Le travail sur ces 29 programmes n'est pas terminé et le diff vise avant tout à montrer de quoi est capable ce nouveau système de restriction des droits.

À première vue difficile de savoir si tame constitue une avancée notable qui intéressera les développeurs en dehors d'OpenBSD. Les Capabilities POSIX sont complexes, notoirement sous-utilisées et elles sont vertement critiquées (voir cet article de Spender) car les droits sont trop larges et les groupes trop fourre-tout.

Je ne sais pas si tame a une chance de sortir du microcosme OpenBSD. Il est probable que seccomp-bpf (plus puissant, plus flexible) restera la solution reine de restriction des programmes sous Linux.

  • # SELinux

    Posté par  . Évalué à 2.

    Hello,

    Saurais-tu dire en quoi cela est différent de SELinux?
    Et accessoirement pourquoi il ne le liste même pas dans les alternatives.

    (je dois vraiment rater qqchose).

    Merci

    • [^] # Re: SELinux

      Posté par  . Évalué à 10. Dernière modification le 20 juillet 2015 à 13:42.

      AMHA la grande différence entre SELinux et tame c'est que SELinux s'applique sur toute la durée de vie du programme, là où s'applique qu'à partir du moment où tu le souhaite. Un programme qui n'a besoin d’accéder au fs que pour lire sa configuration peut alors perdre se droit pour le restant de son exécution.

      C'est aussi le cas de capabilities POSIX au passage.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: SELinux

      Posté par  (site web personnel) . Évalué à 9. Dernière modification le 20 juillet 2015 à 14:01.

      Saurais-tu dire en quoi cela est différent de SELinux?

      SELinux est de l'ordre des politiques MAC (Mandatory Access Control) autrement dit tu définies ce qu'un programme peut ou ne peut pas faire sous forme d'une politique d’exécution.

      Ici on est dans l'ordre des Capacités. Tu définis lors de la programmation que ton programme ne doit pas faire telle ou telle chose.

      Par exemple tu peux décider sous RedHAT avec SELinux que Apache ne doit pas faire de DNS setsebool httpd_verify_dns off. Cela est possible parce que l'empaqueteur d'apache a défini une politique de sécurité prenant en charge cette possibilité. En tant qu'administrateur système, tu peux utiliser cette politique ou une autre de ton cru ou aucune. Cela est indépendant du fait qu'Apache puisse ou ne puisse pas effectuer de la résolution DNS.

      Hors Apache peut et doit pouvoir résoudre des noms. Cela se pilote par la directive HostNameLookup (je simplifie volontairement). Pour un programmeur il est donc intéressant de pouvoir dire, si HostNameLookup vaut on alors Apache doit avoir la capacité de résoudre des noms sinon, cette capacité doit lui être enlevée. cela permet de limiter fortement l'impact de bugs qui seraient utilisés comme vecteur d'attaque et ce indépendamment des politiques mises en place par l'administrateur système qui déploie ce soft.

    • [^] # Re: SELinux

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

      Je me permets de rajouter une précision basique qui te permettra de mieux comprendre le tableau global et qui ne m'apparaît pas clair dans les réponses de mes deux confrères ci-dessus :

      capsicum et TAME sont des bibliothèques permettant au programme lui-même de déclarer ses droits. Ils nécessitent donc une modification (plus ou moins lourde) du programme, et si il est malfaisant (le développeur prétend ne rien faire de mal et les utiliser pour en être sûr, mais en fait il n'en fait rien) ou si il est remplacé par une version vérolée, tu l'as dans l'os.

      SELinux est un système pour décrire les droits et les vérifier en dehors du programme (dans le noyau). Il ne nécessite aucune modification des programmes cibles. Donc même si ton Apache est vérolé, si la politique SELinux du système lui interdit d'ouvrir une socket réseau, il peut toujours essayer… (sauf bug dans le noyau évidemment).

      • [^] # Re: SELinux

        Posté par  . Évalué à 2.

        Idéalement il faudrait que SELinux ait des règles du type : bloquer tel accès une fois que tel appel à l'API a été effectué si le code de retour est x.

        • [^] # Re: SELinux

          Posté par  . Évalué à 6.

          Le couplage entre le code et ta règle devient très fort, du coup ta règle sera très difficile à maintenir.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Avancée notable

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

    Une petit exemple vaut mieux qu'un long discours

    Implémentation sans raffinage de Tame dans uniq

    Index: usr.bin/uniq/uniq.c
===================================================================
RCS file: /cvs/src/usr.bin/uniq/uniq.c,v
retrieving revision 1.19
diff -u -p -u -r1.19 uniq.c
--- usr.bin/uniq/uniq.c 26 Nov 2013 19:25:39 -0000      1.19
+++ usr.bin/uniq/uniq.c 3 Jun 2015 22:09:03 -0000
@@ -33,6 +33,7 @@
  * SUCH DAMAGE.
  */

+#include <sys/tame.h>
 #include <ctype.h>
 #include <err.h>
 #include <errno.h>
@@ -61,6 +62,8 @@ main(int argc, char *argv[])
        int ch;
        char *prevline, *thisline;

+       tame(TAME_STDIO | TAME_RPATH | TAME_WPATH);
+
        obsolete(argv);
        while ((ch = getopt(argc, argv, "cdf:s:u")) != -1) {
                const char *errstr;
@@ -118,6 +121,8 @@ main(int argc, char *argv[])
        default:
                usage();
        }
+
+       tame(TAME_STDIO);

        prevline = malloc(MAXLINELEN);
        thisline = malloc(MAXLINELEN);

    Implémentation (sans raffinage) de Capsicum dans uniq

    --- head/usr.bin/uniq/uniq.c    2011/11/06 08:18:11 227193
+++ head/usr.bin/uniq/uniq.c    2013/07/18 22:11:27 253457
@@ -44,15 +44,20 @@
   "$FreeBSD$";
 #endif /* not lint */

+#include <sys/capability.h>
+
 #include <ctype.h>
 #include <err.h>
+#include <errno.h>
 #include <limits.h>
 #include <locale.h>
+#include <nl_types.h>
 #include <stdint.h>
 #define _WITH_GETLINE
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
+#include <termios.h>
 #include <unistd.h>
 #include <wchar.h>
 #include <wctype.h>
@@ -68,6 +73,17 @@
 static void     obsolete(char *[]);
 static void     usage(void);

+static void
+strerror_init(void)
+{
+
+   /*
+    * Cache NLS data before entering capability mode.
+    * XXXPJD: There should be strerror_init() and strsignal_init() in libc.
+    */
+   (void)catopen("libc", NL_CAT_LOCALE);
+}
+
 int
 main (int argc, char *argv[])
 {
@@ -77,6 +93,7 @@
    size_t prevbuflen, thisbuflen, b1;
    char *prevline, *thisline, *p;
    const char *ifn;
+   cap_rights_t rights;

    (void) setlocale(LC_ALL, "");

@@ -128,8 +145,34 @@
    ofp = stdout;
    if (argc > 0 && strcmp(argv[0], "-") != 0)
        ifp = file(ifn = argv[0], "r");
+   if (cap_rights_limit(fileno(ifp), CAP_FSTAT | CAP_READ) < 0 &&
+       errno != ENOSYS) {
+       err(1, "unable to limit rights for %s", ifn);
+   }
+   rights = CAP_FSTAT | CAP_WRITE;
    if (argc > 1)
        ofp = file(argv[1], "w");
+   else
+       rights |= CAP_IOCTL;
+   if (cap_rights_limit(fileno(ofp), rights) < 0 && errno != ENOSYS) {
+       err(1, "unable to limit rights for %s",
+           argc > 1 ? argv[1] : "stdout");
+   }
+   if ((rights & CAP_IOCTL) != 0) {
+       unsigned long cmd;
+
+       cmd = TIOCGETA; /* required by isatty(3) in printf(3) */
+
+       if (cap_ioctls_limit(fileno(ofp), &cmd, 1) < 0 &&
+           errno != ENOSYS) {
+           err(1, "unable to limit ioctls for %s",
+               argc > 1 ? argv[1] : "stdout");
+       }
+   }
+
+   strerror_init();
+   if (cap_enter() < 0 && errno != ENOSYS)
+       err(1, "unable to enter capability mode");

    prevbuflen = thisbuflen = 0;
    prevline = thisline = NULL;

    C'est sûr que les possibilités ne sont pas les mêmes, mais le travail pour une couverture complète du système est loin d'être le même non plus.

    • [^] # Re: Avancée notable

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

      C'est un poil malhonnête comme comparaison: dans tame le développeur dit ce dont il a besoin et laisse le système gérer les cas d'erreur, alors que dans le cas de Capsicum c'est le développeur qui doit gérer lui même les cas d'erreur. Un truc un peu plus lisible aurait été du genre caps_ioctls_limit quitte le programme avec une grosse erreur si c'est pas possible. Bon, dit comme ça, on se dit que ça devrait être le boulot de Capsicum d'offrir cette API là, mais bon.

      • [^] # Re: Avancée notable

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

        C'est un poil malhonnête comme comparaison

        Oui. C'était juste pour illustrer le côté réaliste de tame. Theo ne code pas un truc exhaustif qui couvre tous les cas. Mais un truc simple et pratique qui sera déployé de façon exhaustive dans le système de base dans 2 ou 3 versions.

        • [^] # Re: Avancée notable

          Posté par  . Évalué à 3.

          Theo ne code pas un truc exhaustif qui couvre tous les cas.

          Je ne suis pas expert et je ne suis pas de comprendre ce que tu entends par exhaustif, mais il me semble qu'il y a un curseur à placer entre la finesse des droits et la simplicité de mise en œuvre. La plupart des systèmes simples se révèlent simplistes (les capabilities POSIX, les droits Android) et les systèmes complets sont réputés complexes (SELinux).

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Avancée notable

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

            je ne suis pas de comprendre ce que tu entends par exhaustif,

            Pour uniq, dmesg et tout les programmes du système de base qui globalement font une et une seule chose, tame et sa quinzaine de droits me semble tout à fait adapté voir génial par sa simplicité d'implémentation.

            dmesg ne fait pas de réseau, ne forke pas, n'alloue pas de mémoire. C'est facile à dire, à concevoir et à implémenter. Pour un logiciel plus complexe tel un navigateur web, les droits risquent de manquer de granularité pour qu'un tel mécanisme soit réellement utilisable.

            • [^] # Re: Avancée notable

              Posté par  . Évalué à 5.

              Oui probablement, après ce ne sont pas souvent des vecteurs d'attaques important justement parce qu'ils n'écoutent pas le réseau et que le problème se situe plutôt dans des programmes qui écoutent le réseau et qui appellent ces commandes.

              Pour un serveur web, tame perds déjà de l'intérêt par manque de granularité.

              dmesg ne fait pas de réseau, ne forke pas, n'alloue pas de mémoire. C'est facile à dire, à concevoir et à implémenter. Pour un logiciel plus complexe tel un navigateur web, les droits risquent de manquer de granularité pour qu'un tel mécanisme soit réellement utilisable.

              Un truc marrant sur Debian (et probablement dérivé) la commande ping a eu, jusqu'à il n'y a pas si longtemps, le sticky bit root. Tout ça pour pouvoir ouvrir une socket en mode raw. Il y a une capabilities POSIX pour ça (CAP_NET_RAW) qui marche très bien.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Avancée notable

                Posté par  . Évalué à 2.

                Un truc marrant sur Debian (et probablement dérivé) la commande ping a eu, jusqu'à il n'y a pas
                si longtemps, le sticky bit root. Tout ça pour pouvoir ouvrir une socket en mode raw.

                Petite correction: pas un sticky bit (t) mais setuid bit (s)
                Je ne pense pas que Linux ait jamais tenu compte du sticky bit sur fichier.

              • [^] # Re: Avancée notable

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

                Pour un serveur web, tame perds déjà de l'intérêt par manque de granularité.

                Oui il me tarde de voir comment il compte implémenter ça dans ce type de programmes. Je suis comme toi sceptique. A voir.

                Un truc marrant sur Debian (et probablement dérivé) la commande ping a eu, jusqu'à il n'y a pas si longtemps, le sticky bit root. Tout ça pour pouvoir ouvrir une socket en mode raw. Il y a une capabilities POSIX pour ça (CAP_NET_RAW) qui marche très bien.

                J'entends déjà un vieux BSDiste de ma connaissance clamer que "linux c'est de l'à peu près".

                La démarche est louable par contre elle n'est clairement pas aboutie. Remplacer le bit suid par un privilège plus fin est une bonne chose. Mais cela n'a pas conduit à la suppression du bit suid.

                Par exemple sur le PC avec lequel j'écris ce message (debian jessie)

                find /usr/bin/ /usr/sbin/ /bin/ /sbin/ -perm -4000 |wc -l
20

                Il reste 20 programmes suid dans une install relativement basique.

                Si tu regardes l'implémentation de ping de OpenBSD, le programme commence par ouvrir une socket puis drope ses privilèges. 

                int
main(int argc, char *argv[])
{
    struct hostent *hp;
    struct sockaddr_in *to;
    struct in_addr saddr;
    int ch, optval = 1, packlen, preload, maxsize, df = 0, tos = 0;
    u_char *datap, *packet, ttl = MAXTTL, loop = 1;
    char *target, hnamebuf[HOST_NAME_MAX+1];
    char rspace[3 + 4 * NROUTES + 1];   /* record route space */
    socklen_t maxsizelen;
    const char *errstr;
    uid_t uid;
    u_int rtableid;

    if ((s = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)) < 0)
        err(1, "socket");

    /* revoke privs */
    uid = getuid();
    if (setresuid(uid, uid, uid) == -1)
        err(1, "setresuid");

                Du coup dans les deux cas l'attaquant se retrouve avec une socket raw et pas grand chose de plus. On peut alors se demander quel est l’intérêt d'utiliser une Capacité plutôt qu'un privilège à la louche, si le résultat n'est pas la suppression des privilèges à la louche.

                C'est un peu je crois ce que dénonce Théo. Les choses à moitié implémentés parce que trop complexes ou intrusives. Sa vision de la sécurité est de faire des choses simples et robustes, implémentés de façon exhaustive. Si un jour OpenBSD décide de faire la peau au bit suid tu peux être sûr que ce sera fait de façon exhaustive et que nosuid deviendra l'option de montage par défaut.

                • [^] # Re: Avancée notable

                  Posté par  . Évalué à 4.

                  Si tu regardes l'implémentation de ping de OpenBSD

                  Ça n'a rien avoir.

                  Tous les appels systèmes du monde ne remplaceront jamais les solutions à la capabilities POSIX, LSM ou autre pour plusieurs raisons : ils ne gèrent pas la même sécurité (un programme ne peux gérer les failles d'intégration - par exemple pour vérifier que /usr/bin/ping est bien ping(8)) et ils ne sont pas audités de la même façon (toujours pour une question d'intégration). L'audit d'un système n'est pas à l'audit de l'ensemble des programmes qui y sont installés. Tu peux écrire ping de la façon que tu souhaite ça n'empêchera pas qu'il faut au niveau des métadonnées du système lui limiter au maximum ses droits.

                  La seule chose qui pourrait remplacer ça c'est si le mode de développement de ping était en devops, car à ce moment là les développeurs gèrent aussi l'intégration et tant que l'installation se fait via le parcourt classique ce serait bon.

                  Si un jour OpenBSD décide de faire la peau au bit suid tu peux être sûr que ce sera fait de façon exhaustive et que nosuid deviendra l'option de montage par défaut.

                  Faut pas non plus le vénérer, hein ? Les capabilities POSIX n'ont pas pour but de remplacer les bit set-uid donc ils ne les ont pas remplacés et ils n'ont jamais quittés le statu de draft, ça n'empêche pas de les utiliser pour réduire la surface d'attaque.

                  Dans OpenBSD tu as toujours un ring 0 et un compte root qui sont des modes sans la moindre sécurité (rapport à la gestion des droits à la louche). Ils ont pas encore atteins une gestion aussi fine que ce qu'il est possible d'atteindre avec dbus (qu'on peut pas que l'on a) et ils se retrouvent à faire de la séparation de privilège à la main, en statique sans aucune possibilité de superviser la chose1.

                  Je viens de regarder sur mon système j'ai 19 programme avec le sticky-bit et la majorité d'entre eux auraient besoin d'un droit impossible à fournir juste avec une capabilities en empêchant une élévation des privilèges. Les programmes qui modifient /etc/passwd et tame() se rétame sur cette problématique.

                  1 : la supervision est un sujet totalement délaissé par OpenBSD. Pourtant Théo se pleinds de l'incapacité chronique des admin à comprendre la sécurité de leur système. La supervision de leur système devrait être la clef de voûte pour :
                  - comprendre et audité la sécurité de son système
                  - pouvoir réagir aux attaques
                  - faire une analyse post-mortem d'une attaque

                  AMHA ça devrait être LA priorité avant de chercher à ajouter des appels encore différents de ce qui se fait ailleurs et qui n'apporte pas grand chose (c'est plus des manières de voir différemment que de réelles nouveautés).

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Avancée notable

          Posté par  . Évalué à 2.

          Realiste, c'est vite dit, sigkiller l'appli, c'est un tantinet bourrin, non?

          Linuxfr, le portail francais du logiciel libre et du neo nazisme.

          • [^] # Re: Avancée notable

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

            Ça dépend. Je suis de ceux qui pensent qu'une situation exceptionnelle est effectivement exceptionnelle, et que tu n'as donc pas nécessairement le temps/les moyens de nettoyer proprement derrière toi quand un problème survient. Si tu te débrouilles pour qu'un SIGKILL soit la manière normale de fermer ton logiciel (pas de transaction à écrire, pas de fichier à créer/déplacer/supprimer, …), alors tu es prêt pour toutes les situations.

  • # Complexité

    Posté par  . Évalué à 3.

    La comparaison avec SELinux n'est pas très rassurante. 99% des documentations de logiciels et howto recommandent de désactiver SELinux avant de commencer toute opération… Moi même je ne connais personne qui l'utilise en dehors des politiques par défaut sur CentOS/Fedora, et encore.
    En fait c'est tellement compliqué qu'il vaut mieux ne pas l'utiliser et connaitre son système, que de se croire blindé mais n’avoir aucune maîtrise sur l'outil.

    J'espère que tame sera plus simple.

    • [^] # Re: Complexité

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

      La comparaison avec SELinux n'est pas très rassurante. 99% des documentations de logiciels et howto recommandent de désactiver SELinux avant de commencer toute opération…

      Si tu lis les documentation de 2004, ce n'est pas étonnant. La situation a évolué depuis.
      Globalement les seuls qui désactivent SELinux sur Fedora, ce sont les admins systèmes qui ne savent pas l'utiliser et qui sont bloqués quand ils configurent certaines choses (parfois car ils le font mal, parfois de manière légitime).

      Un utilisateur lambda aura très très rarement un soucis dans SELinux, les configs par défaut sont bien rodés maintenant.

      Moi même je ne connais personne qui l'utilise en dehors des politiques par défaut sur CentOS/Fedora, et encore.

      Et ?
      Si on part de là, Linux est peu utilisé sur son ordinateur, cela enlève l'intérêt de son existence ?

      En fait c'est tellement compliqué qu'il vaut mieux ne pas l'utiliser et connaitre son système, que de se croire blindé mais n’avoir aucune maîtrise sur l'outil.

      Tu crois que tout utilisateur connait son système et comment fonctionne chaque outil de sécurité comme pare-feu, anti-virus, etc. ?
      Non, et il ne doit pas les virer pour autant… Ce n'est aps une attitude très responsable.

      Il ne faut pas pour autant croire que SELinux te sauvera de tout, mais c'est une aide comme d'autres.

      • [^] # Re: Complexité

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

        les seuls qui désactivent SELinux sur Fedora, ce sont les admins systèmes qui ne savent
        pas l'utiliser

        Si les admins systèmes sont incapables de manipuler leur système correctement, où va-t-on …

        Trêve de plaisanteries, SELinux a le mérite d'ajouter une couche de sécurité très importante au noyau Linux, mais en échange c'est assez compliqué à mettre en place pour un néophyte. C'est principalement ça que je reproche à SELinux.

        En matière de sécurité, j'ai tendance à considérer que plus un outil est complexe à configurer/manipuler, plus le risque d'erreurs est grand. SELinux fait partie de ces outils complexes à utiliser. Packet Filter a une syntaxe très simple à prendre en main, ce qui me permet de comprendre très rapidement son fonctionnement et donc me permet de bien le configurer.

        J'ai déjà eu un problème avec SELinux, et ce qu'on m'a conseillé c'est de le passer en mode permissif … sans jamais lire les logs pour identifier le/les problèmes. Donc SELinux perd tout son intérêt (dans mon cas).

        • [^] # Re: Complexité

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

          Un néophyte selon moi n'a pas à trifouiller dans SELinux, de la même façon qu'il ne touche pas à son parefeu. Sa complexité ne peut concerner que les admins systèmes.

          Et je pense que pour un admin système ce n'est pas fondamentalement compliqué, cela nécessite de l'apprentissage et cela peut paraître barbant. Mais au moins c'est une sécurité qui ne nécessite aucune modification de programme et c'est l'admin qui gère sa politique notamment suivant la confiance qu'il accorde au binaire (et non le développeur qui s'évalue sa propre confiance ce qui est ridicule).

          C'est donc puissant, mais cela demande du travail. Note que par défaut la configuration de SELinux n'est pas si mal, cela évite une grande partie du travail rébarbatif pour se concentrer sur la politique de ses seules applications.

          • [^] # Re: Complexité

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

            Et puis il n'y a pas que SELinux.
            Apparmor semble plus facile à prendre en main, notamment via des règles plus lisibles.

          • [^] # Re: Complexité

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

            Mais au moins c'est une sécurité qui ne nécessite aucune modification de programme et c'est l'admin qui gère sa politique notamment suivant la confiance qu'il accorde au binaire (et non le développeur qui s'évalue sa propre confiance ce qui est ridicule).

            Ce qui n'est surtout pas du même ordre. Je ne pense pas qu'il y ait antinomie entre une politique MAC et le fait d'écrire au sein d'un programme des gardes fou l'empêchant de dévier de son comportement normal.

            La comparaison de Tame ou Capsicum avec SELinux me semble hors propos. Le fait que Apache ne garde pas ses droits root, n’empêche pas de gérer les droits sur le système de fichier. La sécurité dans le code et la bonne administration du système ne s'opposent pas.

      • [^] # Re: Complexité

        Posté par  . Évalué à 2.

        Il y a quelques temps dans Fedora, suite à une MàJ, GDM ne se lançait plus, blocage au niveau du boot. En désactivant SELinux ça a fonctionné à nouveau.

    • [^] # Re: Complexité

      Posté par  (site web personnel) . Évalué à 7. Dernière modification le 21 juillet 2015 à 11:57.

      À titre personnel j'utilise SELinux sur mon serveur autohébergé sous Fedora. Vu que j'ai des services dont j'ai déplacé les données et/ou la conf sur mon raid, voire des services installés à la main en dehors de yumdnf sur le dit raid, mon apprentissage s'est globalement résumé à comprendre que :

      • chaque « objet » (donc fichier exécutable / fichier de données / port / …) a une étiquette
      • chaque étiquette a le droit de toucher certaines autres étiquettes seulement
      • quand par exemple un binaire veut lire un fichier, il faut que ça colle point de vue étiquettes cf. le point au-dessus

      Et googler/man la commande pour étiqueter un chemin pas prévu par la distrib (maintenant je la connais presque par cœur et de toute façon y a l'historique).

      Alors quand par exemple j'installe gitlab à la main j'ajoute quelques règles, du style

      • le fichier gitlab-shell est étiqueté shell
      • le dossier d'upload public est étiqueté contenu web en écriture pour qu'Apache ait le droit d'y écrire

      et en avant Guinguamp.

      J'ai en tout 22 règles SELinux custom (et j'ai tapé la bonne commande du premier coup pour les lister, sans même chercher dans l'historique bash ! facile).
      Sachant que j'ai DNS / web / gitlab / postgres / jappix / SMTP / et j'en passe qui sont installés au moins en partie ailleurs qu'à l'emplacement prévu, je trouve ça raisonnable.

      Pour troller un poil je pense que le wanabe adminsys qui ne peut/veut pas apprendre ces 2-3 concepts et commandes ferait mieux de trouver autre chose à faire, et en général quand je trouve une doc/tuto qui commence par « désactiver SELinux » j'en tire des conclusions hâtives sur sa qualité et je ferme l'onglet.

      • [^] # Re: Complexité

        Posté par  . Évalué à 3.

        Pour troller un poil je pense que le wanabe adminsys qui ne peut/veut pas apprendre ces 2-3 concepts et commandes ferait mieux de trouver autre chose à faire, et en général quand je trouve une doc/tuto qui commence par « désactiver SELinux » j'en tire des conclusions hâtives sur sa qualité et je ferme l'onglet.

        On ne peut pas balayer d'un coup ce problème en sortant l'excuse du sysadmin qui ne veut pas apprendre. D'ailleurs, parmi tous ceux qui ont moisonné mon premier commentaire, je suis curieux de savoir combien utilisent SELinux et savent faire des règles custom…

      • [^] # Re: Complexité

        Posté par  (Mastodon) . Évalué à 4. Dernière modification le 21 juillet 2015 à 14:11.

        Oui mais la tu parles à titre personnel. La question n'est pas d'apprendre, de savoir ou pas. La où ça coince c'est quand ta boite achète une appli et qu'on te dit que selinux n'est pas supporté. S'ils ne veulent pas rentrer en matière tu désactives selinux pour avoir du support et tu ravales ta fierté.

        Je blâme l'héritage de la culture windows 95 et son tout le monde doit être admin pour cela.

        • [^] # Re: Complexité

          Posté par  . Évalué à -1.

          Windows 95 n'avait pas de notion de droits/restrictions de ce que pouvait faire ou pas faire un utilisateur, donc pas d' "admin".

          Par ailleurs :
          - Windows 95 a 20 ans (c'est facilement deux siècles en informatique)
          - la lignée NT date de 1993, et avait, elle, une notion de droits/restrictions des utilisateurs (au niveau applicatif et filesystem)
          - Depuis Vista (sorti en 2006, soit 9 ans !), l'administrateur n'utilise ses droits administrateurs que pour les tâches d'administration (ou à la demande pour tel ou tel application), le reste est executé avec des droits d'utilisateur standard.

          Bref, la "culture où tout le monde doit être admin" est morte il y a 10 ans (enfin, même si y'a des survivants, ce n'est plus aussi dominant que du temps de Windows XP).

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Complexité

            Posté par  . Évalué à 3.

            J’ai surtout l’impression que c’est je me connecte de base sur le compte qui peut être admin. Quand l’OS demande je clique sur autoriser sans réfléchir. Donc la notion d’admin reste floue. C’est la même chose sous ubuntu, au détail près qu’il faut taper le mot de passe.

          • [^] # Re: Complexité

            Posté par  . Évalué à 3.

            la "culture où tout le monde doit être admin" est morte il y a 10 ans

            La quasi-totalité des postes fixes et portables Windows chez les utilisateurs sont avec les droits d'administrateur pour l'utilisateur. Tout le monde clique sur « Ok » sans lire.
            Dans les petites entreprises c'est pareil, bien souvent même lorsqu'une boîte d'informatique s'en occupe.

            • [^] # Re: Complexité

              Posté par  . Évalué à 0. Dernière modification le 23 juillet 2015 à 07:40.

              La quasi-totalité des postes fixes et portables Windows chez les utilisateurs sont avec les droits d'administrateur pour l'utilisateur.

              Ouais, comme pas mal d'installations de GNU/Linux avec un seul véritable utilisateur qui a le droit d'utiliser sudo. 1 partout.

              Tout le monde clique sur « Ok » sans lire.

              Tout le monde rentre son mot de passe dans sudo sans refléchir (pour Windows, si l'utilisateur n'est pas admin, un mot de passe d'un administrateur sera demandé plutôt qu'une simple confirmation). 1 partout.

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

              • [^] # Re: Complexité

                Posté par  . Évalué à 1.

                le cas n'est pas comparable. Pas grand monde lance un (g|k)sudo firefox (ou autre) pour naviguer alors qu'il y a des gibitonnes de IE (ou autre) lancés avec des droits administrateur.

                The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein

                • [^] # Re: Complexité

                  Posté par  . Évalué à 3.

                  Source ?

                  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                  • [^] # Re: Complexité

                    Posté par  . Évalué à 1.

                    L'annuaire. J'ai contacté chacune des personnes s'y trouvant et afin de leur demander le niveau de privilèges de leur compte utilisateur Windows.

                    The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein

                    • [^] # Re: Complexité

                      Posté par  . Évalué à 3.

                      Encore une fois, ce n'est pas lié au niveau de privilège du compte.

                      Depuis Vista, même en étant administrateur, il faut une élévation de privilège pour exécuter quelque chose en tant qu'administrateur. On est plus du temps de XP.

                      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                      • [^] # Re: Complexité

                        Posté par  . Évalué à 2.

                        Tu fais semblant de ne pas comprendre, ou tu n'as jamais vu de vrais utilisateurs ?

                        Avec 90% des ordinateurs sous Windows il suffit de cliquer sur OK, ce que presque tout le monde fait car ce n'est qu'une n-ième fenêtre de confirmation à un truc qu'on ne pige pas. Même les informaticiens cliquent parfois trop vite sur OK, par habitude.

                        Alors qu'en n'étant pas administrateur, il faut EN PLUS fournir le mot de passe. Ce qui est le cas avec les distributions Linux.
                        Et ça change énormément de choses.

                        • [^] # Re: Complexité

                          Posté par  . Évalué à 5. Dernière modification le 23 juillet 2015 à 19:32.

                          Ça ne change RIEN DU TOUT.

                          Rentrer son mot de passe, ou cliquer sur OK, si l'utilisateur à décidé de s'en foutre, il s'en fichera.

                          Toi, tu n'a pas vu la tétrachiée de posts sur les forums Ubuntu du genre "j'ai fait une commande avec sudo et maintenant j'ai des dragons dans mon ordi" !

                          Et puis niveau sécurité, si la personne peut cliquer sur OK à un prompt UAC, ça veut dire qu'elle a un accès physique (ou qu'elle s'est déjà identifée avec ton compte admin dans le cas de l'accès à distance) : tu es fichu de toutes façons !

                          Et puis je répondais à un commentaire qui disait qu'il y avait des tonnes d'IE ou autre lancés en admin tous les jours, car le premier utilisateur créé sur un poste Windows est administrateur, impliquant qu'être admin signifie utiliser les droits admins constamment, ce qui est faux depuis Vista (bref, faut suivre la conversation aussi).

                          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                          • [^] # Re: Complexité

                            Posté par  . Évalué à 2. Dernière modification le 23 juillet 2015 à 19:48.

                            Et si tu veux une UAC qui te demande un mot de passe plutôt que OK ou Annuler (pourquoi demander un mdp à un admin qui s'est déjà authentifié ? Lui faire perdre son temps ?), il te suffit de ne pas être administrateur.

                            Ce n'est pas propre à gksu/kdesu/sudo.

                            D'ailleurs, bien que l'UAC et la notion qu'un administrateur n'utilise pas constamment ses droits admins au sein de sa session date de Vista, pouvoir exécuter quelque chose en tant qu'un autre utilisateur - y compris un admin - du moment qu'on connaît son login et mdp ça date au moins de NT 4, soit 1996 : cela se faisait sur un exécutable avec l'option "Exécuter en tant que…" ou l'utilitaire en ligne de commande RUNAS.

                            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

            • [^] # Re: Complexité

              Posté par  . Évalué à 3.

              Oui et non. Depuis Vista c'est un fonctionnement similaire à sudo et c'est pas con.

    • [^] # Re: Complexité

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

      99% des documentations de logiciels et howto recommandent de désactiver SELinux avant de commencer toute opération…

      Je vois, et trois lignes plus bas on te demande de faire un chmod 777 (comme dans 99% des docs d'installation d'application web).

  • # seccomp-bpf

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

    Les approches du style seccomp-bpf obligent à écrire un nouveau programme pour observer le programme initial. Selon Theo "That is insane".

    Je ne vois pas cette critique dans le lien que tu donnes et je ne suis pas sûr de comprendre le raisonnement.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: seccomp-bpf

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 22 juillet 2015 à 07:13.

      La phrase de Theo : Some BPF-style approaches have showed up. So you need to write a program to observe your program, to keep things secure? That is insane.

      Et pour ce qui est du raisonnement il faudra lui demander…mais c'est vrai que BPF est une machine virtuelle avec un JIT donc c'est très différent de l'approche de tame.

    • [^] # Re: seccomp-bpf

      Posté par  (site web personnel) . Évalué à 1. Dernière modification le 23 juillet 2015 à 10:29.

      Je ne vois pas cette critique dans le lien que tu donnes et je ne suis pas sûr de comprendre le raisonnement.

      Post de Theo paragraphe 4.

      Le principe des outils comme seccomp, c'est d'autoriser/interdire chaque syscall un par un (il existe un mode "simple", qui n'autorise que read(2), write(2), _exit(2) et un autre dont je ne me souviens plus, sigreturn(2)).

      Le problème c'est que si tu dois faire passer ton programme dans une moulinette qui t'indique les syscall utilisés, c'est sous-optimal et pas forcément pratique. De plus c'est complexe.

      Prenons un exemple : imagine que tu analyses un serveur web que tu as codé toi-même. Pour savoir quel syscalls sont utilisés, tu as deux choix, lire statiquement le code source de ton programme et déterminer lesquels sont des syscalls, et retourner la liste (complexe + cher, mais marche à tous les coups). L'autre solution c'est de lancer ton programme et de regarder les syscalls qui apparaissent au fur et à mesure et à la fin retourne lui aussi la liste des syscalls (simple + léger, mais si un syscall n'a pas apparu durant ton exécution, alors certains auront des problèmes).

      Le principe de tame, c'est d'autoriser/interdire des groupes d'opérations au cours de l'exécution (hors initialisation du programme, là où des opérations privilégiées sont nécessaires).

      • [^] # Re: seccomp-bpf

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

        Ça ne me semble pas changer fondamentalement le problème : il faut quand même déterminer ce qu'on veut autoriser le programme à faire ou non. Si seccomp groupait les syscalls tu pourrais utiliser des « policies » identiques.

        Pour la distinction entre l'initialisation et la boucle principale c'est un peu plus compliqué mais on pourrait imaginer une « policy » seccomp ou autre qui n'est activée qu'après un fork() par exemple.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: seccomp-bpf

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

          Si seccomp groupait les syscalls tu pourrais utiliser des « policies » identiques.

          C'est exactement ce qui a été proposé dans les commentaires de l'article sur LWN.net. Il y a eu proposition pour développer une bibliothèque équivalente au syscall tame(2) avec les mêmes fonctions/fonctionnalités/interface se basant sur seccomp pour gérer les syscalls. Je trouve que c'est une super idée.

          il faut quand même déterminer ce qu'on veut autoriser le programme à faire ou non.

          Alors en fait pas vraiment, si tu sais que ton programme a besoin d'accéder au système de fichiers, tu demandes à tame(2) d'autoriser l'utilisation des syscall travaillant sur le système de fichiers (avec distinction READONLY, WRITEONLY, RW). Si tu as besoin du réseau, tu demandes à tame(2) d'autoriser les syscalls pour l'accès réseau, etc.

          Pour la distinction entre l'initialisation et la boucle principale c'est un peu plus compliqué mais on pourrait imaginer une « policy » seccomp ou autre qui n'est activée qu'après un fork() par exemple.

          Côté Linux, ça pourrait être fait, mais côté OpenBSD je ne pense pas qu'il y ait grand chose de fait à la base (seccomp n'existe pas dans OpenBSD). Le principe, c'est de dire :

          • je lance un programme
          • ce programme effectue toutes ses opérations privilégiées à ce moment, et ne les fera plus
          • il appelle tame(2) pour réduire ses capacités au strict nécessaire pour son fonctionnement nominal
          • si un appel à un syscall non autorisé est effectué, c'est que l'on n'est pas dans un comportement nominal (tentative d'exécution frauduleuse d'une opération non prévue ? Buffer overflow ?)

          Je pense que pour Theo, ça n'augmente pas réellement la charge de travail/maintenance de leurs outils, car via tame(2) ils n'ont pas d'audit de code à conduire pour déterminer la liste EXACTE des syscalls autorisés.

          • [^] # Re: seccomp-bpf

            Posté par  . Évalué à 4.

            Je pense que pour Theo, ça n'augmente pas réellement la charge de travail/maintenance de leurs outils, car via tame(2) ils n'ont pas d'audit de code à conduire pour déterminer la liste EXACTE des syscalls autorisés.

            En effet c'est plus complexe parce qu'il faut savoir si chacun des appels systèmes que tu utilise fait parti ou non du groupe que tu autorise.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: seccomp-bpf

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

              il faut savoir si chacun des appels systèmes que tu utilise fait parti ou non du groupe que tu autorise.

              Les "groupes" d'appels systèmes de tame(2) semblent assez bien faits et rassemblent les syscalls de la bonne façon (par exemple le flag TAME_CPATH rassemble les syscalls qui permettent de créer des fichiers/dossiers/liens symboliques). Donc à moins d'utiliser un syscall à la signification obscure, tu n'auras pas souvent ce problème (et dans ce cas,
              man 2 tame
              Et une recherche te donne le groupe du syscall.

  • # Article LWN

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

    LWN vient de publier un article sur tame : https://lwn.net/Articles/651700/
    Il est pour l'instant derrière le paywall mais il sera accessible à tous à partir du jeudi 30 juillet.

  • # finger ?

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

    Dans son post Theo cite 29 programmes qui ont été modifiés pour inclure l'appel à tame : cat pax ps dmesg ping ping6 dc diff finger from id kdump logger script sed signify uniq w wc whois arp authpf bgpd httpd ntpd relayd syslogd tcpdump traceroute.

    sérieux ? qui utilise encore finger ? (cela permet d'accéder au .project et autres fichiers qu'un utilisateur aurait placé dans son $HOME, je vous laisse regarder le man)
    C'est surtout l'un des plus gros trous de sécurité par nature, utilisés par mes collègues spécialistes de l'intrusion en SI sur les slowlaris 8 qui existeraient encore, les 9 et les 10 aussi d'ailleurs je crois…

    Finger, cela existait avant la page perso sur le web, cela va aussi avec les yellow pages, 'fin des trucs avant le web quoi :-)

    • [^] # Re: finger ?

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      J’utilise encore régulièrement finger, très pratique pour accéder à la clef publique des collègues ou aux .plan, voire pour trouver l’orthographe du nom à partir du mail ou réciproquement. Pourquoi toujours lancer un navigateur ?

    • [^] # Re: finger ?

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

      Tous(?) les outils que tu cites sont plus vieux que le web. Ça ne me semble pas un argument valable pour s'en débarrasser.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: finger ?

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

      Je ne suis pas bien sûr d'avoir compris.

      Comment un process lancé depuis un utilisateur peut-il accéder à un fichier situé dans le home d'un autre utilisateur ? (je pense notamment au cas où root n'a pas accès aux homes)

      • [^] # Re: finger ?

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 23 juillet 2015 à 23:43.

        root n'a pas accès aux homes

        Ah mais oui le fameux bit de chmod qui dit "olol root peut pas lire ce fichier".

        Bon blague à part (oui je vais remettre une couche de SELinux love sur ce journal) avec SELinux même root peut se faire jeter s'il lit ce qu'il ne doit pas lire (la question d'être sûr d'avoir démarré sur un noyau qui ne permet pas à root d'ajouter la règle SELinux adéquate à la volée est laissée au lecteur).

        Mais on parle de finger donc on est dans les années 80 hein ? Donc pas de SELinux. Donc root qui accède pas à ce qu'il veut ? Vraiment ?

        • [^] # Re: finger ?

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

          Je pensais plutôt à des systèmes de fichiers distants (OpenAFS ou NFS) avec une authentification raisonnable (comme Kerberos).

Suivre le flux des commentaires

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