samerw a écrit 29 commentaires

Je viens d'ajouter cette idée à l'article. J'espère que ca explique mieux la synthèse

It should be noted that it is essential to differentiate Global Human Intelligence (GHI) from Individual Human Intelligence (IHI). The GHI represents the total sum of IHIs studied, proved, and analyzed in different fields. The GHI represents the ultimate knowledge that humanity has built till our present time. The IHI can be, however, partial and not a correct knowledge that many humans have in different fields based on their own experience. It is for sure that AI outweighs the IHI of every individual, but it is also very sure that AI will never outweigh the GHI. Thus, we need to see AI machines as knowledge improvement tool that helps every IHI to develop so that the GHI of humanity will always be better.

Merci pour votre commentaire. Je vais mettre à jour l'article pour ajouter des exemples qui illustrent le rôle que cet outil peut jouer pour améliorer l'enseignement.

Merci pour votre commentaire. N'hésitez pas à me faire d'autres retours qui me permettent d'améliorer l'article

Merci, je l'écrit il y a quatre ans.
Il faudrait écrire un autre article plus détaillé sur Linuxfr, qui discute AppArmor et SeLinux concernant leur gestion des capacités..

Nous avons surtout ajouté l'outil capable qui utilise eBPF pour retourner la liste des capacités demandés par un programme. Puis nous avons ajouté d'autres outils qui permet d'ajouter et supprimer les rôles. Chaque rôle étant une liste de capacités

Je suis le créateur de cet outil. Ca fait quelques années on travaille sur cet outil.
N'hésitez pas à me faire savoir votre avis.

SElinux et Apparmor sont complètement inefficaces pour faire face au risque d'escalation de privilège, car dans la majorité des cas ces modules limitent une partie d'application (e.g. target policy pour Selinux) et laisse les autres applications non confinées. N'importe quelle application non confinée est capable de désactiver Selinux et Apparmor lorsqu'on l'exécute avec la commande sudo. Si vous décidez d'appliquer la politique SELinux et Apprmor sur la totalité de des applications de votre système, votre système devient complémentent inutilisable. Notre objectif est de contrôler la distribution des privileges sur la totalité des applications présentes dans Linux. Cela est possible pour nous, car notre module n'implémente pas les règles MAC.

Bonjour,
Je viens de réaliser que j’ai oublié de répondre à votre mail. Je ne sais pas s’il est toujours possible de choisir un livre.

Merci
Samer

Je pense qu'il faut lire la documentation de Linux sur les capabilities. Sinon vous avez aussi des articles sur Internet qui parlent de ce sujet. Nous donnons plusieurs références dans notre page Github.

Je pense que on va arriver à se mettre d'accord. Si openbsd n'a pas implémenté le brouillon POSIX, mon travail n'a aucun intérêt dans OpenBSD. Par ailleurs, mon objectif ne consiste pas à filter les syscalls, il existe bien d'autres solutions qui font ce travail parfaitement comme par exemple Linux Extended BPF.

Mon objectif est de définir une approche de distribution des privilèges root dans les OSs qui ont implémenté le brouillon POSIX. Je vous donne un exemple en reprennat le syntaxe de votre propre exemple sur pf. Nous avons dans Linux le privilège cap_dac_override qui permet à celui qui le possède de contourner toutes les permissions. Maintenant, quand je donne ce privilège à quelqu'un j'aimerais lui donner ce privilège uniquement pour contourner les permissions sur certains dossiers mais pas tout le système. Ainsi, mon système doit permettre à l'administrateur de préciser les privilèges, les utilisateurs et les ressources sur les quelles ces privilèges seront appliqués. le syntaxe pf ce que je veux faire est le suivant:

table { awazan, toto } #
cap_dac_override_personal_documents = "cap_dac_override { /home/user/awazan}"
progbackup = "/usr/bin/backup_program"

pass cap_dac_override_personal_documents to prog progbackup

block # bloque tout ce qui n'est pas explicitement autorisé au dessus

Il semble que OpenBSD n'a pas implémenté POSIX draft 1003.1e dans son kernel. Si cela est vrai, alors OpenBSD adopte le modèle traditionnel d'administration où tous les pouvoirs sont aux mains de l'utilisateur root. Pledge permet d'améliorer la situation mais je me demande du coups comment être sûr que l'utilisateur n'a pas ouvert par exemple le port 81 au lieu de 80 dans OpenBSD?

Bonjour,

Je vous remercie pour l'ensemble de vos commentaires très intéressant. Je vais essayer de répondre:

Notre objectif est de donner la possibilité aux utilisateurs de controller les privilèges qu'ils passent aux programmes. Avec notre module en l'état actuel, l'utilisateur doit au préalable connaitre les privilèges demandés par un programme, ensuite définir les roles dans le fichier de configuration et à la fin utiliser sr avec le role défini pour lancer le programme. C'est un peu laborieux, j'accepte. Mais Nous souhaitons faire évoluer notre module pour rendre la tache facile aux utilisateurs. En particulier, nous souhaitons étendre le kernel de Linux pour enrichir la fonction cap_capable dans le kernel. Si vous regardez le code source de cette fonction, vous réalisez qu'il ne fait pas grande chose à part vérifier l'existence des privilèges dans le set effective des processus. Nous souhaitons développer cette fonction pour nous indiquer les privilèges demandés par les processus et les ressources utilisées avec ces privilèges. Quand on obtient cette information nous pourrons alors automatiser le choix des roles pour l'utilisateur. Par exemple, lorsqu'un programme demande l'accès à une ressource privilégiée, cap_capable va nous rendre des informations que nous croisons avec les infos dans le fichier capabilityRole.xml pour indiquer au utilisateur le role qu'il doit utiliser ou définir dans le fichier xml. Nous devons également étudier tous les programmes de bases qui viennent avec Linux et définir des roles basiques qui permettent aux utilisateurs standard d'utiliser ces roles.

Concernant l'amerlioration du sudo, je ne vous pas cache c'était notre volonté au départ. Simplement nous avons changé notre avis car le code sudo est assez compliqué, il nous fallait du temps pour l'étudier correctement et on n'était pas sûr des impacts de modification du code. Du plus, nous avions la volonté de faire un module composé de plusieurs outils. Pour l'instant notre module est composé d'un seul outil, mais nous souhaitons ajouter d'autres outils comme roleadd, rolemodify, sr_admin, etc..chacun de ces outils va avoir un role administratif associé défini par défaut dans le fichier xml.

Concernant l'installation et la configuration, nous allons travailler pour les rendre plus génériques. Un seul problème, il me faut des contributeurs pour améliorer ce travail car je n'ai pas personnellement assez du temps pour finir toutes ces améliorations.

Je reformule ma réponse. En effet, Linux possède le capability CAP_DAC_READ_SEARCH. Ce privilège permet uniquement de lire les fichiers. Donc vous pouvez éditer le fichier de configuration capabilityRole.xml de la manière suivante:

    <role name="role1">
            <capabilities>
                <capability>CAP_DAC_READ_SEARCH </capability>
            </capabilities>
            <users>
                <user name="toto">
                    <commands>
                        <command>rsync -av toto@server1:/etc  /tmp/etc</command>
                    </commands>
                </user>
            </users>
        </role>    

Apres l'utilisateur toto doit utiliser la commande suivante: sr -r role1 -c "rsync -av toto@server1:/etc /tmp/etc"

Je crains que votre solution ne suffit pas de protéger complètement votre OS. En effet, la configuration de la commande doas vérifie uniquement que l'utilisateur ne va pas passer au script une valeur différente à 80. Rien n'interdit par contre l'utilisateur awazan d'ouvrir un port qui est différent de 80. Par ailleurs, la configuration doas permet au utilisateur awazan de récupérer les privilèges root pour exécuter ce script. Je me demande donc si l'utilisateur awazan n'aura pas la possibilité de créer un autre processus et changeant les arguments de pledge pour pouvoir appeler d'autres syscall..(à tester).

Je pense que vous avez toujours du mal à comprendre que pledge et les separation des privilèges sont des solutions complémentaires. Je vous propose de regarder cette video qui est justement faite par OpenBSD sur la complémentarité de ces deux solutions.

https://www.youtube.com/watch?v=a_EYdzGyNWs

PS: Ma solution ne permet toujours pas de vérifier si l'utilisateur a vraiment ouvert le port 80 ou un autre port. Simplement, si vous avez lu la section to "do list" vous verrez que nous comptons modifier le kernel de Linux pour couvrir cet aspect.

Malheureusement je ne connais pas assez Android pour répondre à votre question.

Il existe le privilege cap_dac_override que vous pouvez donner à votre utilisateur « toto » en précisant la commande rysync avec les options associées. Maintenant cap_dac_override permet de tout faire (read,write, execute) mais uniquement dans le dossier /etc. Nous ne pouvons pas limiter à readonly car les privileges Linux ne sont pas assez fines, contrairement à d’autres systèmes comme Solaris qui possède des privileges fines et permettent de réaliser ce que vous demandez.

Une amélioration du kernel à ce niveau est nécessaire.

et si vous voulez controller les listes de privilèges que vous donnez à vos développeurs? Par exemple, un développeur construit une solution sur un serveur, l'administrateur du serveur souhaite lui donner une partie des privilèges pour tester sa solution sur le serveur, mais pas tous les privilèges. Notre solution peut bien servir dans ce cas.

Je vous remercie pour cette proposition.
Je vais l'étudier et voir si on peut faire du YAML à la place de XML.

Notre objectif est d'étudier l'utilisabilité de notre solution par rapport aux solutions existantes. Je pense qu'il nous manque un peu du support de la part du kernel pour améliorer l'utilisabilité de notre solution. En effet, aujourd'hui le kernel utilise cap_capable() dans le kernel pour vérifier si un processus possède un privilège ou pas. Le problème c'est que cette fonction retourne toujours le meme code erreur quel que soit le privilège vérifié. Si cette fonction est modifiée pour retourner avec le code d'erreur le privilège vérifié, nous pourrons exploiter cette information pour indiquer à l'utilisateur le role qu'il doit assumer.

bref, une modification du kernel est nécessaire pour améliorer notre solution. Nous allons travailler sur cet aspect prochainement.

Merci pour ce commentaire assez intéressant.

Moi je pars du principe suivant: aujourd'hui nous utilisons tous les commandes sudo et su par défaut, ce qui est très dangereux. Tous les programmes peuvent avoir des vulnérabilités et certains programmes ne sont pas forcément bien écrits et ne gèrent pas les privilèges correctement dans leur code. Par ailleurs, quand on donne un ou deux privilèges à un programme, on n'est pas sûr que le programme va l'utiliser sur la ressource qu'il est censé utiliser. Par exemple, quand je donne le privilège cap_net_bind_service à un programme qui est censé l'utiliser pour écouter sur le port 80. Qu'es qui me garantit que le programme ne va pas utiliser ce privilège pour écouter le port 81?

Notre module est donc une amélioration de la situation actuelle. Mais un bon programme doit utiliser des approches comme pledge et capsicum. Il doit aussi savoir gérer les privilèges qui consiste à désactiver les privilèges quand il n'en a plus besoin. Vous pouvez regarder notre code source pour avoir un exemple mais aussi le code source de ping qui est aussi un bon exemple sur l'utilisation des privilèges.

J'insiste sur le fait qu'il ne faut pas mélanger le capability based access control modele avec Linux capability. Je m'explique: admettant qu'un programme souhaite ouvrir un raw socket. Le programme doit absolument posséder cap_net_raw privilège sinon le call socket ne va pas fonctionner. Nous appelons le retour du call socket (file descriptor) comme capability dans le domaine "capability based access control". Ce descripteur normalement doit être initialisé et passé à un autre processus qui n'a pas le droit de faire des appels aux syscalls…

Par ailleurs, notre module est plutôt un outil pour les administrateurs et les utilisateurs, mais pas pour les développeurs. Comme vous le savez, tous les programmes ne sont pas forcément bien développés (imagine un programme qui demande à utilisateur de faire un sudo car il a besoin uniquement d'un seul privilège). Le fait que les administrateurs et les utilisateurs possèdent des outils qui leur permettent de contrôler les privileges passés au programmes c'est forcément avantage.

Bonjour,

Je crois que vous mélangez les 'capability based access control model' avec linux capability. Vous avez raison de confondre les deux car Linux utilise le mot capability. Mais en fait ce sont deux choses différentes. Pledge, seccomp et encore capsicum permettent de contrôler les appels systèmes des processus. Linux capabilities (nous devons utiliser le mot privilege) c'est l'ensemble des permissions dans le kernel qui sont traditionnellement réservés au root.

Si vous utilisez notre module, vous pouvez empêcher l'utilisateur d'utiliser les options de tcpdump qui lui permet de devenir root. En effet, il suffit de définir un role en lui donnant le privilège cap_net_raw et le limitant à l'argument -i par exemple.
N'hésitez pas à le tester.

Il ne faut pas mélanger les permissions classiques des utilisateurs standard avec les privilèges administratifs de root. Les deux existent. Les processus possèdent des attributs pour pouvoir mettre en oeuvre les deux types de permissions.

Virer xml non mais developper des outils pour l'éditer oui (c'est déjà prévu).

Le système de capacité de Linux souffre de nombreux problèmes. En tous cas, si vous utilisez le mode no-root (-n option) vous répondez à certain problèmes cités dans le lien que vous avez fourni (False Boundaries and Arbitrary Code Execution). Le mode no-root permet de désactiver le traitement particulier de uid 0 et vous permet d'avoir un système qui considère root comme utilisateur standard.