Objectif: charge .so ou exécutable qui a été vérifié pour être signé (ou vérifié contre un algorithme arbitraire).
Je veux pouvoir vérifier un fichier .so / exécutable puis charger / exécuter ce .so / exécutable avec dlopen /...
La clé de la clé est qu'il ne semble y avoir aucune façon de contrôler programmatique. On pourrait vérifier le fichier manuellement, puis le charger après .. Cependant, il existe une fenêtre d'opportunité dans laquelle quelqu'un pouvait échanger ce fichier pour un autre.
Une solution possible que je peux penser est de charger le binaire, vérifiez la signature, puis dlopen / Execvt the Depuis que les serrures de système de fichiers sont consultatifs sous Linux, ils ne sont pas utiles à cet effet ... (Eh bien, il y a / processus / $ pid / fd ... Cependant, je ne sais pas si c'est une solution viable.
Mont -o Mand ... Mais c'est quelque chose pour l'utilité d'userlevel, pas de la racine) .
4 Réponses :
Ce projet résout censé cela sur le niveau du noyau.
digsig offre actuellement:
- Vérification de la signature du temps d'exécution des binaires elfe et des bibliothèques partagées.
- Prise en charge de la révocation de signature du fichier.
- Un mécanisme de mise en cache de signature pour améliorer les performances.
De nombreux liants dynamiques (y compris GLIBC) Réglage de la prise en charge LD_AUDIT CODE> Variable d'environnement à une liste de bibliothèques partagées séparées par le colon. Ces bibliothèques sont autorisées à accrocher à divers endroits du processus de chargement de la bibliothèque dynamique.
$ cc -shared -fPIC -o hook.so hook.c
$ cat > a.c
#include <dlfcn.h>
int main() { dlopen("./hook.so", RTLD_LAZY); dlopen("libm.so", RTLD_LAZY); }
^D
$ cc -ldl a.c
$ ./a.out
my_dlopen(libm.so, 1, 0x80484bd)
Sweet, ce genre d'apparence comme ce que je veux ... Sauf que c'est l'une de ces variables d'environnement uniquement vérifiées au démarrage: - / Le projet nécessitant cette fonctionnalité est une partie qui est souvent chargée en tant que plugin à un autre produit ... Cependant, LD_AUDIT ressemble à quelque chose d'utile à gérer lorsqu'il est utilisé dans nos applications contrôlées ...
Impressionnant! Je donnerais celui-ci l'une des charges d'informations les plus utiles et la marque la réponse, à l'exception du cas où quelqu'un a porté un trou sur la théorie.
Le problème est essentiellement insoluble dans le formulaire que vous avez donné, car les objets partagés sont chargés par MMAP () ing pour traiter l'espace mémoire. Donc, même si vous pourriez-vous Assurez-vous que le fichier dlopen () fonctionnait sur était celui que vous avez examiné et déclaré OK, quiconque peut écrire dans le fichier peut modifier l'objet chargé à n'importe quel temps après l'avoir chargé. (C'est la raison pour laquelle vous ne mettez pas à niveau les fichiers binaires en écrivant à eux - au lieu de cela, vous supprimez-l'qu'installez, car vous écrivez probablement des instances d'exécution).
Votre meilleur pari est de vous assurer que seul l'utilisateur que vous utilisez, vous pouvez écrire dans le fichier, puis l'examiner, puis dlopen (). Votre utilisateur (ou racine) peut toujours se faufiler à un code différent, mais les processus avec ces autorisations pourraient simplement faire ptrace () vous de faire leurs enchères de toute façon.
Eh bien, MMAP (,copy ,) donnerait un mappage qui n'est pas affecté par d'autres modifications apportées au fichier sur disque, mais elle n'est pas largement mise en œuvre. Sur Linux et la plupart des autres systèmes, MMAP (, Map_Protivate ,) est utilisé; Il est indéterminé par POSIX si des modifications apportées au fichier modifient la cartographie, mais elles font généralement si la page a déjà été copiée sur écriture.
Ah, bonne capture sur celle-ci ... et pillage rend tout cela inutile ne le fait-il pas: - / Digsig ressemble à la seule option ... ou à un système de fichiers qui offre un accès en lecture seule à des données en soi vérifiées. ..
Marquant ceci comme la «réponse» puisqu'il ne semble pas y avoir d'alternative qui empêche un utilisateur root / courant de fumer avec des choses.
Au cœur, la limite de sécurité à UNIX est entre les UID. C'est un pari juste que la plupart de / usr / bin / * n'a pas été auditée contre Autoriser-l'utilisateur à exécuter-code-code-comme-même "attaques".
Considérons int Memfd = MemFD_Create (...) , que vous pouvez alors Sceau , combiné avec Dlopen ("/ Proc / FS /
Je propose la solution suivante qui devrait fonctionner sans bibliothèques *) *) ne l'a pas réellement testé contre les attaques. Ne pas utiliser dans la production sans autre enquête.
On dirait que le problème global est insoluble sans intervention au niveau du noyau: - / segments peut être écrasé une fois vérifié une fois vérifié ... Ptrace peut changer tout à fait changer la façon dont les choses fonctionnent ... en attendant des réponses qui peuvent faire quelque chose de "magique" ... On dirait qu'il n'y a aucun moyen de le faire sans privilèges au niveau des racines et un moyen de désactiver le débogage externe.
Je pense que tout dépend fortement de ce que vous voulez réaliser exactement en termes de scénario d'affaire. Par exemple, si vous souhaitez envoyer une bibliothèque partagée signée à vos utilisateurs, vous pouvez relativement supposer qu'il n'y a pas de problème de fenêtre d'opportunité - il faudrait déjà être installé des logiciels malveillants sur la machine et, dans ce cas, il n'y a pas grand chose que vous pouvez faire. EDIT: Question à partir de 2009? Mein gott! Parlez de la filomancie!