Ingo Molnar, célèbre développeur du noyau Linux et actuellement employé par Red Hat, a présenté Exec Shield, une méthode implémentée dans le noyau (actuellement disponible sous forme de patch pour le 2.4.21-rc1) pour réduire fortement sous x86 les risques de débordement de tampon (buffer overflows et associés) de façon transparente pour les applications, c'est-à-dire sans recompilation. Rappelons que les débordements de tampons permettent de faire exécuter sur la machine victime un code arbitraire, sous les droits de l'application victime.
Comme nous en parlions récemment dans la news OpenBsd 3.3 qui intègre ce type de protection, l'architecture x86 de Intel présente une limitation matérielle pour la protection des pages mémoire, les pages ne pouvant être marquées en lecture seule; elles sont donc marquées également en exécution, ce qui permet, lorsqu'une application est mal codée, de passer du code exécutable qui sera écrit dans ces pages à la suite des données légitimes et qu'on pourra faire ensuite exécuter par diverses techniques (instructions RET, CALL, sauts, etc)
Pour des raisons de performances, Exec Shield ne protège pas chaque page individuellement, mais utilise la possibilité de séparer en deux segments logiques l'espace d'adressage d'une application, ce qui permet d'empêcher l'exécution dans un des segments et de la permettre dans l'autre. Pour plus de détails, voir l'excellente présentation qu'Ingo fait de son projet.
Aller plus loin
# Re: Comme grsecutity ?
Posté par grumly_gg . Évalué à 10.
"Segmentation-based implementation of non-executable user page
for i386 with negligible performance hit"
# Re: Exec Shield: protection contre les débordements de tampons
Posté par Prae . Évalué à 10.
http://www.openwall.com/linux/(...)
[^] # Re: Exec Shield: protection contre les débordements de tampons
Posté par j . Évalué à 7.
[^] # Re: Exec Shield: protection contre les débordements de tampons
Posté par let antibarbie = xp <- xp - 1 . Évalué à 3.
[^] # Re: Exec Shield: protection contre les débordements de tampons
Posté par free2.org . Évalué à 2.
# Rappels aux développeurs...
Posté par AlV . Évalué à 10.
Il est, à mon sens, plus judicieux de programmer avec précaution toutes les parties "interface" des applications afin d'éviter que les données arrivant de l'extérieur "polluent" les applications, plutôt que de se dire que le système va passer surveiller l'exécution.
Les techniques de programmation permettant d'éviter ça sont connues.
(voir, par exemple là : http://www.dwheeler.com/secure-programs/(...) même si la news passée sur dlfp n'avait guère eu de succès http://linuxfr.org/2002/10/12/9949.html(...) )
Je reste persuadé qu'un programme qui contrôle activement les données qui lui sont passées "de l'extérieur" sera toujours plus sûr qu'une passoire tournant dans un environnement aussi hostile aux intrus soit-il....
Un grand pas vers le "zéro intrusion" reste la combinaison des deux, c'est à dire, de bien (pour tout ce que cela peut signifier ;o) programmer et de faire tourner ses programmes sensibles dans un environnement surveillé (et hostiles aux hackers et pirates) comme ce patch, l'utilisation de chroot et de comptes d'exécution différents de "root".
Dans tous les cas, c'est du très bon boulot, une fois de plus, de la part des développeurs de Linux (on a le droit de dire juste "Linux", vu que, là, c'est le noyau ;o) et plus généralement de tous ceux qui nous permettent de travailler dans de meilleures conditions.
[^] # Re: Rappels aux développeurs...
Posté par helf (site web personnel) . Évalué à 5.
Et question noyau, on pourrait appliquer le même raisonnement au scheduler: à quoi il sert celui-là? les applications, si elles sont bien écrites devraient "passer la main" sans qu'on soit obliger de leur retirer la cpu... Tiens çà me rappelle un "os"...
Moi je pense que le noyau est le garant de ce qu'il exécute. Par conséquent, ce type de développement n'est pour moi pas "une sécurité supplémentaire" mais une fonctionnalité indispensable au bon fonctionnement du noyau.
[^] # Re: Rappels aux développeurs...
Posté par doublehp (site web personnel) . Évalué à 7.
Non, c est pas ce qu il dit, justement :
Un grand pas vers le "zéro intrusion" reste la combinaison des deux, c'est à dire, de bien (pour tout ce que cela peut signifier ;o) programmer et de faire tourner ses programmes sensibles dans un environnement surveillé (et hostiles aux hackers et pirates) comme ce patch, l'utilisation de chroot et de comptes d'exécution différents de "root".
[^] # Re: Rappels aux développeurs...
Posté par Fabimaru (site web personnel) . Évalué à 2.
Même si on s'estime conducteur de voiture parfait, il faut quand même:
- faire confiance à sa voiture
- faire confiance aux autres conducteurs
La justement tu ne fais pas confiance aux données qui arrivent à ton serveur.
Donc même raisonnement.
[^] # Re: Rappels aux développeurs...
Posté par Sébastien Koechlin . Évalué à 6.
Linus a refusé plusieurs fois d'intégrer ce genre de protection, sous prétexte que cela ne ferme pas le problème, il a donné au moins deux fois une méthode permettant d'exploiter un buffer overflow sur une machine disposant d'une pile non exécutable (il me semble qu'il faut modifier l'adresse de retour pour qu'elle pointe sur un appel à exec situé dans la partie exécutable du code, on se contente d'ajouter un niveau d'indirection).
Sa politique est plus ou moins la suivante (si j'ai bien compris): les dépassements de pile sont toujours exploitables malgré cette protection, ils sont simplement nettement plus compliqués à mettre en place et donc aussi à traquer.
Donc les dépassements de buffers seronts moins bien corrigés si ce patch est intégré. Le seul bénéfice serait une diminution temporaire des attaques jusqu'à ce que les hackers se soient mis à niveau.
[^] # Re: Rappels aux développeurs...
Posté par un_brice (site web personnel) . Évalué à -5.
on a le droit de dire juste "Linux", vu que, là, c'est le noyau ;o
</blockquote>
Nan, il faut dire GNU/Linux:
http://www.gnu.org/gnu/linux-and-gnu.fr.html(...)
/me cherche une grosse pierre pour se cacher dessous
# Et l'exemple qmail ?
Posté par Matthieu . Évalué à 8.
Qmail se dit ultra-secure, le code a été travaillé pour qu'aucun buffer overflow n'existe. Pour l'instant rien ne démontre le contraire.
Alors qu'elle est la formule magique du code de qmail ? pourquoi est-ce que les développeurs ne s'en inspirent pas ?
Pourrait-il être possible d'éviter des buffers overflow rien qu'en s'inspirant des techniques de programmation utilisées dans qmail ?
[^] # Re: Et l'exemple qmail ?
Posté par bmc . Évalué à 4.
A priori, rien ne l'empêche. Le problème, c'est que les développeurs, par manque de temps/connaissance/envie, ne pensent même pas à sécuriser leurs applications, alors je les vois mal auditer Qmail. Par contre, les techniques utilisées dans Qmail sont largement diffusées, notamment dans le Secure Programming Howto (voir sur http://www.tldp.org/(...) ), et donc accessibles à tout un chacun sans beaucoup d'effort. On les retrouve (a priori c'est le même genre de technique mais je n'ai pas été vérifier) dans des programmes comme PureFTPd, vsftpd, postfix, etc. donc ce ne sont pas des techniques merveilleuses. Ces programmes ont été créés avec la sécurité comme motivation (presque) principale. C'est comme partout, il y a des gens extrèmements compétents, des gens très consciencieux, parfois des gens qui sont les deux, et souvent des gens qui ne sont ni l'un ni l'autre :)
Le fait est que les développeurs qui codent des logiciels libres le font souvent «pour le fun», et ils n'ont pas forcément la motivation d'aller chercher ce genre de docs ou pour «penser sécurisé». De plus, certaines failles peuvent être très subtiles et nécessitent que la sécurité soit vraiment un souci primordial du développeur, ce qui n'est que (trop) rarement le cas.
[^] # Re: Et l'exemple qmail ?
Posté par forc3 . Évalué à 10.
Si les stralloc.
Qmail utilise des stralloc pour toute la gestion de ses chaines de caracteres, pour faire bref, les stralloc sont les g_string de la glib. C'est une structure qui contient un pointeur sur char et un unsigned int len correspondant a la taille du char * et un autre unsigned int a contenant la taille reelle allouee.
a est toujours plus grand ou egal a len.
Les stralloc permettent tres facilement de manipuler les chaines sans plus jamais se soucier de savoir si la taille allouee est assez grande.
Le stralloc n'utilise pas de format et c'est _volontaire_.
Les format sont tres souvent mal utilise, la doc est trop complexe, il suffit de les bannir. (cf format strings bug)
De nos jour, faire des bugs de formats est inexcusable, disait quelqu'un ayant
travaille serieusement la question. (marchant dans l'espace).
Cependant ils sont encore mal utilises, de trop nombreux snprintf ne limitant pas la taille des arguments, ni d'appel verifiant la valeur de retour.
Le man correspondant est pourtant clair, et donne meme un exemple de code le mettant en pratique... (pas encore suffisant... personne ne lit de nos jours !)
Vsftpd utilise des stralloc cf fin du texte disponible sur son site dans:
vsftpd-1.1.3/SECURITY/IMPLEMENTATION
Site de qmail
http://cr.yp.to/(...)
-- ce qui suit n'est plus 'buffer overflow centric' mais est tout aussi important --
Reimplementation GPL de outils Bernstein, pour la plupart public domain.
http://www.fefe.de/libowfat/(...)
La racine faut aussi le coup d'oeil.
http://www.fefe.de/(...)
Autre site utilisant du Bernstein like aka DJB ware.
http://www.skarnet.org/(...)
http://www.superscript.com/(...)
http://www.smarden.org/pape/(...)
Excellent outils disponibles mais pas assez mis en valeur.
http://cr.yp.to/daemontools(...)
http://www.smarden.org/runit(...)
Ce n'est pas un hasard que depuis apache-1.3.26 une nouvelle option de ligne
de lancement est apparue:
-F run main process in foreground, for process supervisors.
De plus tous ces softs utilisent un principe different de ce qu'est un daemon.
Un daemon _ne_ doit _pas_ se detacher du son pere...
Cela permet non seulement de monitorer ce daemon car un magnifique SIGCHLD va frapper a la porte du papa, signalant que son fils est mort :/
Le papa peut rapidement le relancer.
Si maintenant le pere peut faire la meme chose avec un autre fils (le frere de notre daemon) mais n'ayant que pour but dans sa vie de mettre par ecrit ce que
son frere dit ... Vous obtenez une famille capable de tourner tout le temps.
Vous donnez la capacite a ce frere de 'rotater' tout seul les logs, sans devoir 'killer' l'autre frere. Si vous lui ajouter en plus la possibilite de gerer lui meme le timestamp, et si vous lui donnez en plus la possibilite d'executer une action avant de 'rotater' vous obtenez une famille formidable...
A la poubelle rotatelogs qui continue a faire des scripts shell pour killer les daemons. Un daemons est cense rester actif tout le temps.
Ce n'est pas son boulot de faire appel a toute ces actions a gettimeofday() pour coller un timestamp. Laissons ce travail a un processus dedie, lui aussi monitore.
De plus ce fameux timestamp, qui est toujours different entre tous les daemons... Et le fameux syslog() de la glibc qui a la grande idee de tronquer a l'annee. Tres pratique pour refaire des requetes SQL derriere contenant le temps, car notre timestamp lui necessite l'annee... Du coup notre parseur de log a lui aussi besoin d'appeler gettimeofday() sur toutes les lignes qu'il recoit. Sans compter qu'il faut le faire en temps reel car sinon il faut imaginer ce qu'il se passerait au date proche de la st sylvestre. Le parseur de log est en 2004 alors que les logs syslog datent de la semaine precedente.
Si vraiment vous pensez que syslog est viable (mdr...) utiliser www.smarden.org/socklog, avec multilog.
Maintenant que notre daemon est monitore, que son frere s'occupe de logguer son activite, et que pour passer des ordres il suffit de commandes archi-simple, sans devoir se soucier d'un quelconque PID.
(Normal le pere, lui, il est au courant du numero de son fils ...)
De plus les fils ne sont pas jumeaux, il peuvent tout a fait, et c'est recommande avoir des identites differentes... Un processus de log independant, monitore, qui rotate tout seul, qui peut vautrer sans bloquer le daemon, mais qui sera relancer aussitot. (Au passage il faut y aller pour faire tomber multilog)
Tres tres utile via des directive CustomLog de Apache, utilisant des pipes
On vire le timestamp car on va utiliser celui de multilog:
LogFormat "%h %u \"%r\" %>s %b" multilog
On fait 5 paquets max de log de environ 1M max, on log sous l'id log et non plus apache... ou root (;p mdr)
CustomLog "| /usr/local/bin/setuidgid log /usr/local/bin/multilog t s999999 n5 /var/log/apache/access" multilog
Voila un apache pres a tourner 24/24 sans jamais devoir se soucier d'avoir une tache cron qui appelle bien rotatelog qui va bien faire 1 script shell qui va bien parcourir la liste des pid en utilisant ps qui va bien faire un kill sur apache apres ... (humm que du bonheur).
Pour terminer, il faut separer les processus, il ne faut pas faire faire a votre daemon des choses qui sont faisables par d'autre programmes.
Utiliser des 'stralloc' like, bannissez les formats, utiliser toujours des filedescriptor, minimiser les appels a malloc(), utiliser alloca() quand vous le pouvez, ne forker pas au demarrage. Et aller lire le code source de qmail et de vsftpd.
Et enfin:
Reclamez l'implementation d'un syscall unlink() utilisant un fd et non plus un const char * (;p)
[^] # Re: Et l'exemple qmail ?
Posté par Thomas Cataldo (site web personnel) . Évalué à 5.
man alloca :
CONFORMING TO
[...]
This function is not in POSIX or SUSv3.
BUGS
The alloca function is machine and compiler dependent. Its use is discouraged.
On many systems alloca cannot be used inside the list of arguments of a function call, because the stack space reserved by alloca would appear on the stack in the middle of the space for the function arguments.
Je ne sais plus qui croire là ;-) Mais pour tout le reste je suis complètement d'accord, surtout pour apache/cron.
Sans vouloir lancer "une polémique" si les gens incompétents arrêtaient d'utiliser des languages de progs où chaque manipulation de chaines de caractères est un trou de sécurité potentiel, on aurait beaucoup moins de soucis.
[^] # Re: Et l'exemple qmail ?
Posté par Linux_GTI . Évalué à 3.
Faut se même dans la tête qu'il y a toujours un moment ou il faut "prendre des risques". Si tu fais un serveur web en C++, tu as surement une fonction "query_string_2_Qstring()" qui te retourne un objet string mais qui a forcément fait des manipulations avec malloc/strcpy etc.
De même, c'est pas parce que tu utilises du php qu'il n'y aura pas de problème.
[^] # Re: Et l'exemple qmail ?
Posté par Thomas Cataldo (site web personnel) . Évalué à 3.
Par contre C++ n'est pas problématique, sauf quand c'est mal utilisé est qu'on trouve des char* et des malloc partout. Si on utilise la STL ou autre, pas de souci, sauf si le problème est dans la STL bien sur.
[^] # Re: Et l'exemple qmail ?
Posté par Linux_GTI . Évalué à 7.
C'est le cas pour apache. Lors d'un logrotate, le processus père (pid : /var/run/httpd.pid) reçoit un SIGHUP. Ce processus père tue "en douceur" les fils (il laisse les requêtes se terminer (sauf les longues requêtes)) mais le processus père n'est pas tué !. Lorsque tous les fils sont morts, le père relance des fils. Les requêtes arrivées durant cette phase reste en attentes mais aucun client ne perçoit un service arrêté.
Faire un process frère pour les logs n'est pas la panacée. Il faut mettre en place des moyens de communication entre le processus qui fait les logs et ces frères (ipc surement puisque ce sont des frères).
De plus ta demande d'avoir des deamons qui tourne 24h/24 peut être très facilement faite en utilisant syslog(3). Par contre c'est plus coûteux en temps.
> Reclamez l'implementation d'un syscall unlink() utilisant un fd et non plus un const char * (;p)
Ça n'a aucun sens.
exemple :
$ mon_prog toto &
$ ln toto titi # lien hard
$ mv toto tata
mon_prog crée et ouvre toto. 2 minutes après il faut un hypotétique unlink(fd). Que doit faire l'OS ? suprimer titi et tata ? Et si toto est un lien symbolique ? Et si fd est un pipe ?
[^] # Re: Et l'exemple qmail ?
Posté par forc3 . Évalué à 10.
Enormement de programme ont souffert, souffrent et souffiront de ce probleme.
Un handler d'un signal _doit_ toujours faire un instruction atomique.
C'est a dire mettre un flag, et c'est tout.
Si maintenant tu preferes vraiment la methode rotate logs autant utiliser, les daemontools avec la commande
svc -h /service/apache
plutot que l'infame methode utilisee par rotatelogs...
En parlant de apache, dans les versions 1.3.x le programme htpasswd fait usage de tmpnam(). D'apres son man elle n'est pas vraiment recommandee ...
>> Faire un process frère pour les logs n'est pas la panacée. Il faut mettre en place des moyens de communication entre le processus qui fait les logs et ces frères (ipc surement puisque ce sont des frères).
Pourquoi donc ce n'est pas la panacee ?
Lire en utilisant un read bloquant est le moins couteux en temps proc.
Ensuite les pipe sous linux c'est PIPE_BUF: 4096 atomiquement.
Avant d'avoir une ligne de log qui fasse cette taille.
Si ton reader vautre, il est relance...
Ensuite un reader de log de dois jamais avoir un code tres complexe. Il est donc facile de coder quelquechose de tres stable.
Surtout avec 'getln' et 'stralloc' ...
Les ipc permettent le 'privilege separation' qui _doit_ etre utilise tout le temps que c'est possible.
>> De plus ta demande d'avoir des deamons qui tourne 24h/24 peut être très facilement faite en utilisant syslog(3). Par contre c'est plus coûteux en temps.
Quid de la rotation de logs ? (cf premier message)
Quid du format du timestamp ? (cf premier message)
Et du cote du developpeur:
Quid des personnes ne sachant pas utiliser les formats ? (cf premier message)
Syslog est a bannir.
Meme si entre les pipe il y a un mini parsage des donnees, c'est au programmeur d'utiliser des choses simple, dans qmail par exemple c'est juste le premier octet qui defini les actions a executer et les arguments sont les byte suivants. Meme si on perd une infime parti de temps a faire une analyse sur le flux au lieu de faire seulement un read, la securite est _grandement_ amelioree ... A comparer avec le parseur de printf() ...
> Reclamez l'implementation d'un syscall unlink() utilisant un fd et non plus un const char * (;p)
Je veux dire par cette phrase qu'il serait interessant de diposer d'un appel systeme appele, par exemple funlink() utilisant un fd au lieu d'une chaine. Pour eviter les problemes de 'race condition' que l'on trouve avec toutes les fonctions basees sur le nom.
Je ne veux pas dire qu'il faut enlever unlink().
[^] # Re: Et l'exemple qmail ?
Posté par PLuG . Évalué à 1.
Si DJB n'utilisait pas sa license "spéciale" et faisait un peu plus confiance a la communauté du libre (ie avait releasé ses outils en GPL), on aurait certainement plus de distributions grand public (redhat/mandrake/debian) n'utilisant quasiement plus les scripts de demarrage bsd/sysV... et des daemons développés (tous) de la meme facon.
Car tes paroles sont intégralement celles de DJB, qui a de bien bonnes idées.... mais peu d'estime dans ses semblables.
[^] # Re: Et l'exemple qmail ?
Posté par Linux_GTI . Évalué à 4.
man sigaction :
"sa_mask gives a mask of signals which should be blocked during execution of the signal handler. In addition, the signal which triggered the handler will be blocked, unless the SA_NODEFER or SA_NOMASK flags are used."
> plutot que l'infame methode utilisee par rotatelogs...
C'est ton avis. J'aime bien logrotate.
> le programme htpasswd fait usage de tmpnam(). D'apres son man elle n'est pas vraiment recommandee ...
info libc :
"Temporary Files
===============
If you need to use a temporary file in your program, you can use the `tmpfile' function to open it. Or you can use the `tmpnam' (better: `tmpnam_r') function to provide a name for a temporary file and then you can open it in the usual way with `fopen'. "
man tmpnam :
"If the argument s is NULL this name is generated in an internal static buffer and may be overwritten by the next call to tmpnam(). If s is not NULL, the name is copied to the character array (of length at least L_tmpnam) pointed at by s and the value s is returned in case of success."
Le problème c'est d'utiliser tmpnam(NULL).
de /usr/include/stdio.h :
"/* This is the reentrant variant of `tmpnam'. The only difference is
that it does not allow S to be NULL. */
extern char *tmpnam_r (char *__s) __THROW;"
> Pourquoi donc ce n'est pas la panacee ?
Parce qu'il faut réécrire un système pour loguer. Car il faut mettre en place un système pour communiquer avec le nouveau système pour loguer. Car par rapport à un système qui écrit directement dans un descripteur de fichier, c'est moins performant.
> Ensuite les pipe sous linux c'est PIPE_BUF: 4096 atomiquement.
Si les processus sont frères et/ou que les processus clients peuvent "mourrir" tu ne peux pas utiliser de pipe (ou alors il faut utiliser des pipes nommés).
> Les ipc permettent le 'privilege separation' qui _doit_ etre utilise tout le temps que c'est possible.
?
> Quid de la rotation de logs ? (cf premier message)
Tu passe par syslog, puis tout les journaux de syslog sont "rotationné" par logrotate toute les nuits. Aucun problème.
> Quid du format du timestamp ? (cf premier message)
Oui. Mais c'est pas un drame. De plus il ne doit pas être difficile de corriger ça si c'est indispensable.
> Quid des personnes ne sachant pas utiliser les formats ? (cf premier message)
Si c'est pour des logs apache (/var/log/httpd/access_log par exemple), le format est sous le contrôle d'apache. Si tu passes par syslog, rien ne d'interdit d'ajouter la date dans le format qui te plais.
> Syslog est a bannir.
Je me marre. Fait un "man syslogd" et "man syslog.conf".
exemple :
"Named Pipes
This version of syslogd(8) has support for logging output to named pipes (fifos)."
"Terminal and Console"
"Remote Machine
This syslogd(8) provides full remote logging, i.e. is able to send messages to a remote host running syslogd(8) and to receive messages from remote hosts. The remote host wont forward the message again, it will just log them locally. To forward messages to another host, prepend the hostname with the at sign (@).
Using this feature youre able to control all syslog messages on one host, if all other machines will log remotely to that. This tears down administration needs."
Avec pipe, rien ne t'empêche de faire un programme qui écoute le pipe (sur une autre machine si tu veux) et de logguer les messages dans une base de donnée et jamais d'utilisation de logrotate et en même temps d'avoir les logs en directe pour les consoles sous toto. Le possibilités sont nombreuses. Mais si tu veux coder un autre syslog, te gène pas.
> par exemple funlink() utilisant un fd au lieu d'une chaine. Pour eviter les problemes de 'race condition' que l'on trouve avec toutes les fonctions basees sur le nom.
Quels sont les problèmes ?
Aucun. La chaine passée à unlink n'est pas interprété. C'est totalement différent de system() par exemple. Puis pourquoi pas virer toutes les fonctions qui attende un char * (open() ?). Utilise dmalloc si tu as "peur". Mais attention, les performances vont en prendre un sérieu coup...
[^] # Re: Et l'exemple qmail ?
Posté par forc3 . Évalué à 6.
>> plutot que l'infame methode utilisee par rotatelogs...
> C'est ton avis. J'aime bien logrotate.
Logrotate parait au premier abord peut etre une bonne idee, cependant il necessite du programmeur de faire 1 daemon capable de reouvrir ses logs, d'ecrire dans un repertoire, de gerer le timestamp et la ligne a ecrire.
Toutes les fonctions pour faire cela sont loin d'etre simple a utiliser, snprintf() par exemple (cf premier post).
Lorsque l'on code un daemon on aimerait s'occuper plus de ce qu'il doit faire et non pas de comment il va ecrire ce qu'il a fait.
On parle juste de temps ici, si notre daemon utilise les daemontools il n'a pas besoin de forker, pas besoin de d'ecrire 1 pid dans /var/run, pas besoin d'ouvrir un fichier de log.
Pour faire des logs corrects, il suffit juste de faire
write(1, log.s, log.len);
avec stralloc log.
Ainsi peu importe ce qu'il se passera note deamon n'auras _jamais_ le probleme du manque de plus de place sur le disque, ou de gerer un eventuel SIGHUP, ou de bien tout fermer en redamarrant completement.
C'est beaucoup plus simple, c'est exactement ce que la securite necessite: des choses simples.
Le paranoiaque pourra tout a fait tester la valeur de retour du write pour la comparer avec log.len, et agir en consequence.
Apres vos logs peuvent faire tout ce qu'il veulent, par exemple,
gzippedSQLthruSSL (j'utilise ca en production).
Et le processus de log tourne sous une autre Id.
Compromettez le, sachant qu'il ne souffre d'aucun buffer overflow, et qu'il tourne sous une id faible.
'rotatelogs' au final complique la vie du programmeur.
Les daemontools simplifie grandement la vie du programmeur, deplus le code est tellement simple et sure qu'il serait vraiment idiot de ne pas les utiliser.
Si tu prefere les methodes compliquees de programmation, qui prennent du temps a developper et ne sont pas sures au final c'est ton choix, mais personnellement utiliser des methodes sures, simples qui fonctionnent a tous les coups, je trouve cela _necessaire_ quand on parle de securite. On ne peut pas se permettre de faire tourner des choses dont on ne controle pas a 100% leurs comportements.
>> Le problème c'est d'utiliser tmpnam(NULL).
Le probleme ce n'est pas ca. Ce n'est pas non plus sa reentracy c'est que le random associe est completement pourri. Du man:
BUGS
Never use this function. Use mkstemp(3) instead.
De plus les codeurs ne pensent pas a faire un sous repertoire avant de passer le template a la fonction, lorsque l'on est root on doit proteger ce repertoire cree dans /tmp par un fchown. Pour le rendre inaccessible aux autres utilisateurs...
>> Parce qu'il faut réécrire un système pour loguer. Car il faut mettre en place un système pour communiquer avec le nouveau système pour loguer. Car par rapport à un système qui écrit directement dans un descripteur de fichier, c'est moins performant.
Sauf que les daemontools font ca pour toi directement sans rien devoir coder...
Il te fournissent meme le loggeur, et meme un loggeur capable d'ecrire dans syslog ...
Si tu veux pas prendre la peine d'aller voir les daemontools sache au moins que ca utilise la sortie standard et la sortie d'erreur, soit 0 et 1...
C'est une des raisons qui font qu'un daemon monitore ne doit pas se detacher... J'ai explique tout ca dans le premier post...
Les liens present dans mon premier post etaient la pour etayer mes dires.
Je te mets le lien direct:
http://cr.yp.to/daemontools.html(...)
Pour syslog... l'udp c'est pas la 'panacee'... Donc il faut le faire via un tunnel
SSH ou mieux SSL. Mais il faut quand meme coder le lecteur lisant depuis le named pipe pour ecrire dans le fd du tunnel. Si ce processus tombe alors c'est fini. Si tu ne sais pas pourquoi l'udp n'est pas la 'panacee' essaie de te documenter plus serieusement.
Retourne voir socklog de pape.
http://www.smarden.org/socklog/(...)
On ne parle pas de buffer overflow mais de race condition ce qui n'est pas du tout la meme chose...
Les race conditions apparaissent lorsque plusieurs fonctions utilisent elle meme
un const char * comme argument. Entre deux appels le fichier decrit par le parametre peut etre devenu un lien symbolique ou hard sur autrechose...
Il faut donc toujours travailler avec des fd.
Ce qui peut etre t'as trouble, et ce que je n'ai pas dit, mais ne me semblait pas necessaire, c'est que nous parlons des fonctions qui accedent au filesystem...
Je ne parle pas de _toutes_les fonctions prenant des const char * comme arguments. Je suis un lamer mais pas a ce point la.
[^] # Re: Et l'exemple qmail ?
Posté par Linux_GTI . Évalué à 2.
Le timestamp, n'est pas nécessaire pour logrotate. Et logrotate peut même te gérer des fichiers binaires au format "stupide".
> Ainsi peu importe ce qu'il se passera note deamon n'auras _jamais_ le probleme du manque de plus de place sur le disque, ou de gerer un eventuel SIGHUP, ou de bien tout fermer en redamarrant completement.
J'ai rien contre les nouveaux systèmes, mais l'actuel est correct. S'il était "tout pourri" et devait être "bannit", il ne serait plus là depuis un moment.
> 'rotatelogs' au final complique la vie du programmeur.
Suffit de trouver un moyen pour ouvrir et fermer les fichiers logs pour les processus qui sont "résidants". Pas plus.
Je n'ai pas dit que logrotate était génial. J'ai seulement dit que j'aime bien.Le probleme ce n'est pas ca.
> Ce n'est pas non plus sa reentracy c'est que le random associe est completement pourri. Du man:
> BUGS
> Never use this function. Use mkstemp(3) instead.
C'est les pages infos qui font références. Je voulais dire que tmpnam() n'est pas un problème de sécurité si c'est bien utilisé (attention à l'umask entre autre). Je l'ai utilisé à une époque où il n'y avait pas le choi. mkstemp est meilleur, c'est claire.
Mais le mieux est d'utiliser tmpfile(). Avoir des noms de fichier, c'est pour le communiquer à d'autre processus.
> un const char * comme argument. Entre deux appels le fichier decrit par le parametre peut etre devenu un lien symbolique ou hard sur autrechose...
Il faut donc toujours travailler avec des fd.
Juste.
Plus globalement, je ne nie pas qu'il y a de meilleurs solutions. Mais tu critiques syslog, parles d'apache alors qu'apache n'utilise pas syslog etc... De plus apache utilise plusieurs fichiers de log (access, error, referer, ssl, etc...) (Et le format n'est pas dicté par syslog ou logrotate!). Tu critique l'utilisatation de /var/run/httpd.pid, alors que c'est aussi là pour avoir plusieurs serveurs web sur une même machine (dont un en chroot par exemple). Désolé mais tu fais dans le FUD (bannir syslog, tmpnam, etc...) pour caser des solutions plus innovantes et ça me gonfle.
Longue vie aux daemontools etc... qui font peut-être parti de l'avenir d'Unix/Linux. Mais c'est pour pour autant que l'existant est de la "merde" et n'a pas certains bénéfices. Je sais, je suis dure.
Bon, on va pas se facher. C'est beaucoup une histoire de "goûts et couleurs" et d'habitude.
[^] # Re: Et l'exemple qmail ?
Posté par Gyro Gearllose . Évalué à 1.
En tout cas, je dois dire que même si je ne suis pas d'un niveau suffisant pour pouvoir y donner le moindre avis technique, je dois bien avouer que j'ai appris des choses à vous lire.
A ce propos d'ailleurs, vous faites souvent référence dans les commentaires ci-dessus aux pages de manuel des fonctions utilisées et/ou aux pages info. Bien, mais il me semble que la tâche du programmeur est justement de programmer, pas de lire la doc.
Ce que je veux dire par là, inutile de s'enflamer inutilement, ce n'est pas qu'il faut banir la doc, loin de là, mais pourquoi ne trouve-t-on pas ou peu de doc sur ce que j'ai presque envie d'appeler les "bonnes façons de coder" ?
J'avoue qu'à cette heure (Il est 00h00), je n'ai pas le courage de chercher... Mais il me semble qu'une doc aussi bien argumentée que ce qui précède serait plus utile à un programmeur, en première approche que les pages du man....
Ca ne reste que mon avis....
[^] # Re: Et l'exemple qmail ?
Posté par Linux_GTI . Évalué à 1.
C'est comme le "bon parlé", ça n'existe pas :-)
Pour la doc, je te conseilles très vivement les pages info de la libc. C'est accessible en ligne de commande avec "info libc" ou "gnome-help info:libc" (et de 50 autres façons différentes). La libc te donne les éléments de base d'un système Unix et ça peut te resservir avec tout les autres languages.
Mais il n'y a pas que ça à lire...
[^] # Re: Et l'exemple qmail ?
Posté par Gyro Gearllose . Évalué à 1.
Non, sûrement pas, et c'est d'ailleurs pour ça que je l'avais mis entre guillemets. Je pensais en fait un peu plus à des techniques de programmation, dans le sens de ce qui est dit ci-dessus, et pas à une bibliothèque d'algo ou carément des sources toutes rédigées, sinon il n'y aurait plus rien à faire.
Une approche similaire serait les articles "briques de bases en C" diffusés dans GNU/Linux Mag. Par exemple, moi, j'aimerai bien me lancer dans la programmation d'une appli pour KDE. Visiblement la doc, très fournie, devrait suffire, mais de mon point de vue il n'en est rien.
Ce doit faire 5 ans que je n'ai pas rédigé une ligne de C++, et même si tous les objets sont décrits dans la doc (qui n'en reste pas moins agréable à parcourir sous Kdevelop), nulle part n'est expliqué simplement comment faire pour créer une appli, faire réagir les menus, etc.
Les exemples "standards" fournis par Kdevelop lorsqu'on créée un nouveau projet sont pas mal, mais il faut sans cesse consulter la doc, et ce n'est pas simple. Enfin, ce n'est là encore qu'un avis....
# Re: Exec Shield: protection contre les débordements de tampons
Posté par hideo . Évalué à 4.
----| Conclusion
1) StackGuard/StackShield can save you in case of accidental buffer overflows,
but not against a programmer's stupidity. Erreare humanum est, yeah
right, but security programmers must not only be human, they must be
security-aware-humans.
2) - By auditing your code - you may waste some time but you'll surely
increase the security of the programs you're writing.
- By using StackGuard/StackShield/whatever - you may decrease your system
performance but in turn you gain additional layer of security.
- By doing nothing to protect your program - you risk that someone will
humiliate you by exploiting an overflow in your code, and if it happens,
you deserve it!
So, be perfect, be protected, or let the others laugh at you.
---[ BYPASSING STACKGUARD AND STACKSHIELD ]
Bulba and Kil3r, < http://www.phrack.org/phrack/56/p56-0x05(...) >
non mais 8).
A lire pour atteindre l'éveil 0:)
---[ A Brief History of Hackerdom ]
http://www.l0t3k.org/biblio/hacking/english/hacker-history/(...)
ou cette approche du développement "sécurisé"
---[ Best Practices for Secure Development ]
Razvan Peteanu < http://members.rogers.com/razvan.peteanu/best_prac_for_sec_dev4.pdf(...) >
---[ How to find security holes ]
paulv < http://www.l0t3k.org/biblio/programming/english/security-holes.html(...) >
< http://www.canonical.org/(...) >
---[ Secure Programming for Linux and Unix HOWTO ]
David A. Wheeler < http://www.dwheeler.com/secure-programs/(...) >
---[ Secure UNIX Programming FAQ ]
< http://www.whitefang.com/sup/(...) >
Le vent nous portera...
hideo_nomura
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.