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 barmic . En réponse au journal Tame et OpenBSD. Évalué à 4.
Ç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/pingest bienping(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.
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/passwdettame()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)