Pour faire très concis,
RSBAC est capable de controler les appels systèmes.
C'est à dire que tu peux définir des ROLES pour une application,
un processus, un binaire (pour séparer les différents états).
Avec RSBAC tu peux faire un sorte qu'une appli écrite avec les pieds
qui ne comprends rien à la sécurité tourne sans problème sans jamais
pouvoir intéragir avec le reste dont il n'a normalement rien à faire.
Pour donner un peu une image facile à comprendre, c'est comme si il validait chaque ligne d'un strace.
Definir un role d'application de log qui aurait comme seul droit de pouvoir lire /proc/kmsg et d'ecrire dans /var/log sans pouvoir lire ce
répertoire ni d'effacer les fichiers que lui même aurait créé, tournant dans un chroot au sens rsbac (rsbac_chroot) qui pourrait être lancer
par un user sans privilège.
RSBAC te permet de TOUT controler, par controle il faut comprendre validation; il donnera l'accès seulement parce que tu l'as décidé.
PS le roles ne sont qu'une partie de ce que tu peux faire mais c'est déjà un concept très intéressant.
Il me vient une idée pour illustrer un peu mes dires c'est qu'avec RSBAC tu peux créer un automate de ton application.
Un schéma dans lequel tu controles toutes les possibilités de cette application.
Accessoirement ca te permet de voir des messages d'erreurs que tu n'aurait jamais vu par ailleurs :p
Salut,
J'ai parcouru vite fait le code, et je pense que tu va vite
transformer tous tes 'sprintf' en 'snprintf', et peut être tu vas ajouter le cas du connect entrain de se connecter, histoire de ne pas bloquer
l'application qui utilise ta lib pendant que tu te connectes au server pop3. (errno = EINPROGRESS)
Oublie les buffer static de 512.
Ensuite, jettes un coup d'oeil à gperf.
Quoi qu'il en soit au niveau du controles des acces,
il est tout a fait possible d'interroger les pages web lues par
le navigateur sans passer par leurs interfaces webservices.
Cela fait maintenant plus de 3 ans que mon bot d'interrogation des
pages google fonctionne. Je parcourais seulement les balises
HTML. J'en suis le premier étonné, mais c'est un fait, interroger
directement les pages web reste tout a fait possible.
C'est sûr le parsing est un peu plus compliqué, mais si la maintenance
se fait tous les 3 ans c'est pas la peine de chercher plus loin...
Ainsi tout ce qui est API d'interrogation est tout à fait 'bypassable' sans problème...
Avec la democratisation des CSS en plus il suffit de chercher
des id= qui vont bien pour retrouver ses petits...
> Dis moi, t'as pas l'impression de te compliquer la vie pour rien avec
> l'utilisation de poll() etc. Sachant que tu peux envoyer à yylex() un FILE
> *, pourquoi ne pas en profiter ?
Je ne comprends pas ce que tu veux dire. Quel est le rapport entre timeout, et FILE ?
Présentant un cas d'utilsation de leur 'superbe' outil DTrace, qui
en se limitant à ce seul document est un strace scriptable.
(j'aime bien restreindre ;p).
Le premier exemple est tout naturellement intitulé:
Example 1: Porting the smbfs Driver From Linux to the Solaris OS
> je cherche un module apache qui permettrait de faire la chose suivante. Je
> voudrais pouvoir dire à Apache de balancer sur un programme (par
> l'intermédiaire d'un fichier fifo ou autre) toutes les informations pour une
> requête d'un client, et ce programme pourrait dire à apache ce qu'il faut
> faire.
Les informations contenues dans l'environnement d'execution d'un CGI
ne te suffisent pas ? Le seul developpement à faire serait de parser
les QUERY_STRING.
A moins que apache dispose de plus d'informations que ce qu'il transmet
au CGI, ton problème trouve sa solution dans un CGI appelé avec la méthode
POST qui et je pense que tu dois le savoir écrit sur l'entrée standard du
cgi la partie body de la requete http (les headers étant positionnés dans
l'environnement)
Je dis tout ca car c'est exactement comme ca que je fais pour avoir un
server web minimal qui n'a qu'une seule vocation, être un serveur d'application,
il se contente donc d'appeler des binaires.
Pourquoi mes utilisateurs auraient accès à cette machine?
Malheureusement non.
Je suis obligé de patché le programme car il existe des environnements
ou tu ne peux pas être root, tu peux juste demander au root
de lancer tes trucs.
Mon problème se pose surtout dans le cas ou la machine héberge
des logiciels propriétaires qui ne permettent pas de toucher à
quoi que ce soit sous peine de plus être supporté.
Je n'ai pas la chance d'utiliser postgresql sur une machine dédiée.
Et je ne suis pas root sur la machine.
L'admin local ne sait pas comment on fait une cage chroot. Donc
je lui mache le travail...
> J'y comprend rien. Pourquoi tu veux chrooter alors que postgresql tourne sous
> le compte postgresql ?
Ce n'est absolument pas suffisant, que faire si le programme exécute un binaire
suid'é ? Que faire s'il écrit dans un répertoire du système ?
LOAD de mysql afin de lire n'importe quel fichier sur la machine hote, depuis
PHP ne te rappelle rien ?
De toute facon tout daemon doit se chrooter... Et changer d'identité, et en
aucun ne doit pouvoir lire autrechose que ses données.
> commande : CREATE USER
Merci.
> Les mots de passe sont cryptés (comme /etc/passwd, .htaccess, etc). Ils sont
> dans la base de donnée (comme mysql). Puis comment tu veux faire une
> authentification sans avoir accès aux mots de passe ?
C'est d'écriture dont je parlais, mais c'était dans un environnement particulier
ou le système disposait de 'roles' particuliers. Dans certains environnements ajouter
ou modifier un utilisateur ne se fait pas à n'importe quel heure et nécessite
beaucoup d'échanges de mails...
Ensuite,
CREATE USER peut visiblement modifier ce fichier.
Tu as parfaitement raison. Encore merci.
Ce qui me gêne un tout petit peu, et qui peut être n'est plus
d'actualité, c'est deux choses principalement:
1) pour sécuriser un postgresql, écrire un patch pour qu'il se chroot
n'est pas trivial, en effet, lors de la création de tables il utilise
les commandes cp et rm, donc coder le patch n'a plus vraiment d'interet
puisque l'idee c'était justement de ne plus devoir recreer une arborescence
propre... J'ai régler le problème en utiliser des binaire cp et rm compilé
statiquement avec la dietlibc. La conclusion c'est que c'était un peu
plus long que prévu.
2) Comment on fait pour ajouter des utilisateurs dynamiquement ? Chose
triviale avec Mysql, il m'est impensable de laisser le fichier d'authentification
accessible au processus postmaster ou à un de ses fils. Du coup je ne
peux pas utiliser cette base pour faire de l'hébergement de manière simple.
Ce sont vraiment ces deux points qui me chagrinent. Car pour le reste,
je lis beaucoup mieux le C que le C++ et je trouve les capacités d'extensions
de cette base beaucoup plus intéressantes.
En fait il faut chercher du côté des fonctions qui porte un nom avec Select dedans :)
Je veux dire par exemple AsyncSelect ou un truc du genre sous windows.
Maintenant si ton programme est prévu pour supporter une lourde charge, je pense
qu'il faut l'adapter a la plateforme.
Penser Thread pour win et faire un choix sous linux entre Thread ou Automate...
Apres choisir une bon implem de thread.
Le top reste la possibilité de changer facilement le moteur afin d'avoir juste une
modification minime a effectuer pour utiliser la fonction propre au systeme.
Et du coup réaliser des benchs et enfin faire un choix...
1) utilisation de select, donc de ses limitations, alors que tout
est dynamique ->dommage pas scalable, et limité en nombre de fd.
Pourquoi utiliser nap() et appeler également select() au début de
la boucle ? Pourquoi appeler FD_ZERO à chaque fois alors que il
suffit d'avoir un FD_SET déjà initialisé qui remettrait à 0
'setSockets' ?
FD_ZERO(&blankSockets)
while ()
setSockets = blankSockets;
(mm_net_server.c) (mm_net_nap.c)
2) remplacer tous les appels à strncpy par memcpy...
2) le connect est bloquant, penser a mettre le fd on O_NONBLOCK et
gerer le EINPROGRESS... Idem pour accept. (mm_net_socket.c)
3) Le type string_t est nase, il aurait fallu avoir un unsigned int
en plus dans la structure contenant le nombre exacte de bytes
disponibles différent de la longeur de la string véritable, et
allouer toujours un peu plus que necessaire. (mm_core_string.c)
4) trop de semaphore.
5) trop d'allocation mémoire dans tous les sens, penser à faire des
pool ou alors allouer les maximums d'objets au début. Malloc est le
point noir de toute application.
Les threads c'est bien pour ne pas se prendre la tête à faire
mieux. Mais pour un serveur c'est pas vraiment le top...
#include <stdio.h>
#include <string.h>
#include <alloca.h>
#define METHOD_SIZE (sizeof("http://") - 1)
int get_host(const char *url, unsigned int len, char **res, unsigned int size)
{
unsigned int i;
/* chaine vide */
if ( 0 > len )
return 0;
/* chaine ne contenant meme pas la methode ... */
if ( METHOD_SIZE > len )
return 0;
for ( i = METHOD_SIZE; i < len; i++ ) {
if ( '/' == url[i] )
break;
}
/* pas assez de memoire pour contenir le resultat */
if ( size < len )
return -1;
len = i - METHOD_SIZE;
memcpy(*res, &url[METHOD_SIZE], len );
return len;
}
int main(int ac, char *av[])
{
char *host = 0;
int len = 0;
if ( ac < 2 )
return 1;
host = (char *) alloca(32);
len = get_host(av[1], strlen(av[1]), &host, 32);
if ( 0 < len )
printf("host: %.*s\n", len, host);
else
printf("ret: %d\n", len);
return 0;
}
Travailler moins ca veut surtout dire passer plus de temps pour que
le chose fonctionne mieux. Passer peu de temps à developper c'est
avoir beaucoup de temps pour faire des tests unitaires et des
validation fonctionnelle. Et c'est fort appréciable.
> Blague à part, ce que tu dis sur la génération d'un parser HTTP à
> partir de l'EBNF m'interresse.
Et moi dont, malheureusement je ne le génère pas a partir de
l'EBNF, ce que je génère c'est un 'parser.yacc' et un 'lexer.lex'
issus de template. Voici comment cela se passe :
Première étape définir ce qui nous intéresse, c'est à dire mettre
dans un fichier server_definition.txt la syntaxe suivante non
exhaustive pour simplifier:
GET data
POST data
"connection:" CONNECTION data
"accept:" ACCEPT data
"accept-encoding:" ACCEPTENCODING data
"cache-control:" CACHECONTROL data
"pragma:" PRAGMA data
Voila c'est la liste de ce que mon parser va comprendre.
Maintenant générons les différents fichiers:
sh> gen_yacc
Désormais j'ai un fichier parser.yacc qui sait que CONNECTION
prend 1 argument
sh> gen_lex
Désormais je dispose d'un lexer.lex qui sait que la token
CONNECTION c'est "connection:"
sh> gen_files
Désormais dans le répertoire commands/ j'ai les fonctions
suivantes: cmd_get.c, cmd_post.c, cmd_connection.c, cmd_accept.c,
cmd_acceptencoding.c, cmd_cachecontrol.c, cmd_pragma.c.
Chacune ne seront appelées que si la grammaire est correcte.
Derniere étape:
sh> make
Je dipose maintenant d'un binaire qui comprends
server_definition.txt.
Le but final est bien sur de pas partir de server_definition.txt
mais de l'EBNF contenu dans la RFC.
Ce n'est qu'une premier étape car vous pouvez bien imaginer que il
reste un peu de parsing a faire dans les fonction cmd_xxx.
L'exemple typique c'est
GET /url HTTP/1.1.
Car mon parseur va appeler cmd_get avec comme paramètre
"/url/ HTTP/1.1"
je suis donc dans l'obligation de découper, cependant et vous me
l'accorderez facilement, ce découpage n'a rien de très compliqué.
La difficulté du parseur HTTP c'est que les valeurs peuvent
s'étendre sur plusieurs lignes, en effet la valeur d'un header
n'est pas terminée tant qu'on n'as pas trouver un autre header ou
alors la fin des headers '\r\n\r\n'.
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
peut s'ecrire
Accept-encoding: gzip;q=1.0,
identity;q=0.5,
*;q=0
C'est une des raisons pour lesquelles j'utilise de ''templates''.
Un pour le lexer et un pour le parser.
La dessus je ne te contredis pas cyklo.
Le propos de ce journal c'est plus sur l'idee que chaque gros
développement a choisi de refaire des choses que l'on trouve
dans la libC de base.
Je veux juste mettre l'accent sur le fait qu'il n'y ai pas vraiment de raison
pour lesquelles l'argument de réinventer la roue ne s'applique
pas ici...
_ Programme pourri, utilise libc et fonctions de string pourries
_ Programme 'secure', recode un lib de base...
Pourquoi ne pas avoir fait dans la libc un lib 'secure' ?
Dans enormément de cas c'est l'API qu'il faut remettre en cause,
pourquoi ne pas diriger les jeunes developpeurs vers des apis
mieux faites ?
(parce que si t'es jeune tu penses que le java c'est ultime ...)
Excuse moi, le strlen etait peut etre mal choisi,
ce que je veux dire c'est que cette lib rends le developpement
un peu trop permissif a mon gout, Et que des bugs ne sont
jamais corriges car non bloquant.
Maintenant Glib fournit des g_string, qui sont beaucoup mieux
que de simple char *.
Humm oui,
le problème de cette lib, c'est qu'elle utilise trop d'assert,
qu'elle est bloated, et que surtout elle ne segfault pas quand
elle devrait...
C'est pas un hasard si enormement d'appli GTK sorte des warning
sur ton terminal... Trop d'appli ne sont pas corrigée parceque justement ce ne sont pas des erreurs bloquantes.
Un strlen sur un string NULL _doit_ segfaulter...
Trop de flexibilité rends les programmeurs trop lazy ...
C'est mon point de vue. On peut ne pas etre d'accord. Mais mon
experience me conforte dans cette idée.
Absolument pas,
En fait c'est justement pour nous faire travailler moins.
Un parser c'est toujours chiant à ecrire et on rencontre toujours
pas mal de difficultés.
Si maintenant on arrive à ne plus y penser on se concentre alors
sur le but du developpement.
Actuellement faire un parseur qui comprends HTTP/1.1 et juste ca
ca me prends environ 20 secondes. (test unitaire compris)
Pour les signaux j'ai jamais dit non plus que c'etait impossible je dis juste que du code qui les utilise mal est tres tres courant...
>> 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.
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.
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.
Pour apache, comme pour tout deamon il est toujours plus sage de ne pas faire des handler de signaux complexe. Les signaux sont asyncrhones, lorsqu'un SIGHUP est delivre le handler de ce signal est appele, le signal SIGHUP est bloque, par contre si ce handler mets du temps a s'executer, et qu'un autre signal arrive, l'autre handler va etre execute. Nous n'aurons alors execute qu'une partie des instructions du handler du SIGCHLD.
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.
# KDE installé
Posté par forc3 . En réponse au journal Je cherche une distro Kde qui marche !. Évalué à 3.
J'ai arrété de me prendre la tête avec les trucs qui marchent pas trop
et maintenant la seule distribution que j'installe c'est.
KNOPPIX !
Tu l'installes après tu trouves l'option pour tout installer sur ton disque.
Et c'est terminé.
En 10 minutes tu as un KDE rutilant.
J'ai jamais été déçu.
Au moins fait le test, installe la sur ton dur pour t'en rendre compte par toi même.
[^] # Re: Différences
Posté par forc3 . En réponse à la dépêche Sortie de RSBAC 1.2.5. Évalué à 5.
RSBAC est capable de controler les appels systèmes.
C'est à dire que tu peux définir des ROLES pour une application,
un processus, un binaire (pour séparer les différents états).
Avec RSBAC tu peux faire un sorte qu'une appli écrite avec les pieds
qui ne comprends rien à la sécurité tourne sans problème sans jamais
pouvoir intéragir avec le reste dont il n'a normalement rien à faire.
Pour donner un peu une image facile à comprendre, c'est comme si il validait chaque ligne d'un strace.
Definir un role d'application de log qui aurait comme seul droit de pouvoir lire /proc/kmsg et d'ecrire dans /var/log sans pouvoir lire ce
répertoire ni d'effacer les fichiers que lui même aurait créé, tournant dans un chroot au sens rsbac (rsbac_chroot) qui pourrait être lancer
par un user sans privilège.
RSBAC te permet de TOUT controler, par controle il faut comprendre validation; il donnera l'accès seulement parce que tu l'as décidé.
PS le roles ne sont qu'une partie de ce que tu peux faire mais c'est déjà un concept très intéressant.
Il me vient une idée pour illustrer un peu mes dires c'est qu'avec RSBAC tu peux créer un automate de ton application.
Un schéma dans lequel tu controles toutes les possibilités de cette application.
Accessoirement ca te permet de voir des messages d'erreurs que tu n'aurait jamais vu par ailleurs :p
Oua(h)la
:p
# Code de ta bibliothèque
Posté par forc3 . En réponse au journal libspopc 0.6 is out. Évalué à 1.
J'ai parcouru vite fait le code, et je pense que tu va vite
transformer tous tes 'sprintf' en 'snprintf', et peut être tu vas ajouter le cas du connect entrain de se connecter, histoire de ne pas bloquer
l'application qui utilise ta lib pendant que tu te connectes au server pop3. (errno = EINPROGRESS)
Oublie les buffer static de 512.
Ensuite, jettes un coup d'oeil à gperf.
[^] # Re: Systèmes de clefs/Protocoles utilisés
Posté par forc3 . En réponse au journal Yahoo! s'ouvre aux développeurs.. Évalué à 1.
il est tout a fait possible d'interroger les pages web lues par
le navigateur sans passer par leurs interfaces webservices.
Cela fait maintenant plus de 3 ans que mon bot d'interrogation des
pages google fonctionne. Je parcourais seulement les balises
HTML. J'en suis le premier étonné, mais c'est un fait, interroger
directement les pages web reste tout a fait possible.
C'est sûr le parsing est un peu plus compliqué, mais si la maintenance
se fait tous les 3 ans c'est pas la peine de chercher plus loin...
Ainsi tout ce qui est API d'interrogation est tout à fait 'bypassable' sans problème...
Avec la democratisation des CSS en plus il suffit de chercher
des id= qui vont bien pour retrouver ses petits...
# Accès aux sources.
Posté par forc3 . En réponse à la dépêche RCC : un nouveau logiciel de gestion de QoS pour Linux. Évalué à 2.
exécuter ?
Ce n'est pas lisible sur une plateforme qui ne dispose pas du shell, et
c'est parfait pour se retrouver vite fait avec un trojan.
Merci d'avance.
[^] # Re: Euuuuuh...
Posté par forc3 . En réponse au journal Flex mon ami !. Évalué à 1.
> l'utilisation de poll() etc. Sachant que tu peux envoyer à yylex() un FILE
> *, pourquoi ne pas en profiter ?
Je ne comprends pas ce que tu veux dire. Quel est le rapport entre timeout, et FILE ?
Raconte moi tout...
[^] # Re: Le partage ne marche pas vraiment dans les deux sens...
Posté par forc3 . En réponse à la dépêche Solaris officiellement annoncé sous licence Open Source. Évalué à 3.
Et je me rends compte que c'est toujours la phrase qui ne sert à rien qui
est utilisée comme base au commentaire.
# Le partage ne marche pas vraiment dans les deux sens...
Posté par forc3 . En réponse à la dépêche Solaris officiellement annoncé sous licence Open Source. Évalué à 3.
visiblement prendre du code regit par une autre licence et
l'inclure dans OpenSolaris ne les gènes guère, pour preuve la
page suivante:
http://developers.sun.com/solaris/articles/dtrace_for_dev.html(...)
Présentant un cas d'utilsation de leur 'superbe' outil DTrace, qui
en se limitant à ce seul document est un strace scriptable.
(j'aime bien restreindre ;p).
Le premier exemple est tout naturellement intitulé:
Example 1: Porting the smbfs Driver From Linux to the Solaris OS
Ils sont vraiment sympas chez Sun.
# Un CGI avec la méthode POST ?
Posté par forc3 . En réponse au journal Identifications modulaire / apache et autres. Évalué à 1.
> voudrais pouvoir dire à Apache de balancer sur un programme (par
> l'intermédiaire d'un fichier fifo ou autre) toutes les informations pour une
> requête d'un client, et ce programme pourrait dire à apache ce qu'il faut
> faire.
Les informations contenues dans l'environnement d'execution d'un CGI
ne te suffisent pas ? Le seul developpement à faire serait de parser
les QUERY_STRING.
A moins que apache dispose de plus d'informations que ce qu'il transmet
au CGI, ton problème trouve sa solution dans un CGI appelé avec la méthode
POST qui et je pense que tu dois le savoir écrit sur l'entrée standard du
cgi la partie body de la requete http (les headers étant positionnés dans
l'environnement)
Je dis tout ca car c'est exactement comme ca que je fais pour avoir un
server web minimal qui n'a qu'une seule vocation, être un serveur d'application,
il se contente donc d'appeler des binaires.
[^] # Re: Critiques et interrogations.
Posté par forc3 . En réponse à la dépêche Sortie de PostgreSQL 8.0. Évalué à 1.
Malheureusement non.
Je suis obligé de patché le programme car il existe des environnements
ou tu ne peux pas être root, tu peux juste demander au root
de lancer tes trucs.
Mon problème se pose surtout dans le cas ou la machine héberge
des logiciels propriétaires qui ne permettent pas de toucher à
quoi que ce soit sous peine de plus être supporté.
Je n'ai pas la chance d'utiliser postgresql sur une machine dédiée.
Et je ne suis pas root sur la machine.
L'admin local ne sait pas comment on fait une cage chroot. Donc
je lui mache le travail...
[^] # Re: Critiques et interrogations.
Posté par forc3 . En réponse à la dépêche Sortie de PostgreSQL 8.0. Évalué à 2.
> le compte postgresql ?
Ce n'est absolument pas suffisant, que faire si le programme exécute un binaire
suid'é ? Que faire s'il écrit dans un répertoire du système ?
LOAD de mysql afin de lire n'importe quel fichier sur la machine hote, depuis
PHP ne te rappelle rien ?
De toute facon tout daemon doit se chrooter... Et changer d'identité, et en
aucun ne doit pouvoir lire autrechose que ses données.
> commande : CREATE USER
Merci.
> Les mots de passe sont cryptés (comme /etc/passwd, .htaccess, etc). Ils sont
> dans la base de donnée (comme mysql). Puis comment tu veux faire une
> authentification sans avoir accès aux mots de passe ?
C'est d'écriture dont je parlais, mais c'était dans un environnement particulier
ou le système disposait de 'roles' particuliers. Dans certains environnements ajouter
ou modifier un utilisateur ne se fait pas à n'importe quel heure et nécessite
beaucoup d'échanges de mails...
Ensuite,
CREATE USER peut visiblement modifier ce fichier.
Tu as parfaitement raison. Encore merci.
Je vais pouvoir me repencher dessus du coup !
[^] # Re: Il y a pire...
Posté par forc3 . En réponse au journal Paris ne migre pas vers les LL et Microsoft l'utilise comme argument marketing. Évalué à 2.
Je compilais quelques noyaux en fonctions des différentes archi, et je
deployaient ces noyaux en les copiant.
Je ne passais pas plus d'une heure a faire cela.
Pas la peine de recompiler sur toutes tes machines...
# Critiques et interrogations.
Posté par forc3 . En réponse à la dépêche Sortie de PostgreSQL 8.0. Évalué à 1.
d'actualité, c'est deux choses principalement:
1) pour sécuriser un postgresql, écrire un patch pour qu'il se chroot
n'est pas trivial, en effet, lors de la création de tables il utilise
les commandes cp et rm, donc coder le patch n'a plus vraiment d'interet
puisque l'idee c'était justement de ne plus devoir recreer une arborescence
propre... J'ai régler le problème en utiliser des binaire cp et rm compilé
statiquement avec la dietlibc. La conclusion c'est que c'était un peu
plus long que prévu.
2) Comment on fait pour ajouter des utilisateurs dynamiquement ? Chose
triviale avec Mysql, il m'est impensable de laisser le fichier d'authentification
accessible au processus postmaster ou à un de ses fils. Du coup je ne
peux pas utiliser cette base pour faire de l'hébergement de manière simple.
Ce sont vraiment ces deux points qui me chagrinent. Car pour le reste,
je lis beaucoup mieux le C que le C++ et je trouve les capacités d'extensions
de cette base beaucoup plus intéressantes.
[^] # Re: Thread ou processus ?
Posté par forc3 . En réponse au message Le mystère du pointeur global. Évalué à 1.
Je veux dire par exemple AsyncSelect ou un truc du genre sous windows.
Maintenant si ton programme est prévu pour supporter une lourde charge, je pense
qu'il faut l'adapter a la plateforme.
Penser Thread pour win et faire un choix sous linux entre Thread ou Automate...
Apres choisir une bon implem de thread.
Le top reste la possibilité de changer facilement le moteur afin d'avoir juste une
modification minime a effectuer pour utiliser la fonction propre au systeme.
Et du coup réaliser des benchs et enfin faire un choix...
[^] # Re: Thread ou processus ?
Posté par forc3 . En réponse au message Le mystère du pointeur global. Évalué à 4.
1) utilisation de select, donc de ses limitations, alors que tout
est dynamique ->dommage pas scalable, et limité en nombre de fd.
Pourquoi utiliser nap() et appeler également select() au début de
la boucle ? Pourquoi appeler FD_ZERO à chaque fois alors que il
suffit d'avoir un FD_SET déjà initialisé qui remettrait à 0
'setSockets' ?
FD_ZERO(&blankSockets)
while ()
setSockets = blankSockets;
(mm_net_server.c) (mm_net_nap.c)
2) remplacer tous les appels à strncpy par memcpy...
2) le connect est bloquant, penser a mettre le fd on O_NONBLOCK et
gerer le EINPROGRESS... Idem pour accept. (mm_net_socket.c)
3) Le type string_t est nase, il aurait fallu avoir un unsigned int
en plus dans la structure contenant le nombre exacte de bytes
disponibles différent de la longeur de la string véritable, et
allouer toujours un peu plus que necessaire. (mm_core_string.c)
4) trop de semaphore.
5) trop d'allocation mémoire dans tous les sens, penser à faire des
pool ou alors allouer les maximums d'objets au début. Malloc est le
point noir de toute application.
Les threads c'est bien pour ne pas se prendre la tête à faire
mieux. Mais pour un serveur c'est pas vraiment le top...
http://www.kegel.com/c10k.html(...)
[^] # Re: Trop compliqué ton truc
Posté par forc3 . En réponse au message Sockets.... Évalué à 1.
Un buffer de 1500 suffit amplement pour un recvfrom ...
# Trop compliqué ton truc
Posté par forc3 . En réponse au message Sockets.... Évalué à 3.
max possible ?
Après tu le parcours tout simplement...
[^] # Re: GNet lib
Posté par forc3 . En réponse au message Avoir le host d'une url. Évalué à 2.
#include <stdio.h> #include <string.h> #include <alloca.h> #define METHOD_SIZE (sizeof("http://") - 1) int get_host(const char *url, unsigned int len, char **res, unsigned int size) { unsigned int i; /* chaine vide */ if ( 0 > len ) return 0; /* chaine ne contenant meme pas la methode ... */ if ( METHOD_SIZE > len ) return 0; for ( i = METHOD_SIZE; i < len; i++ ) { if ( '/' == url[i] ) break; } /* pas assez de memoire pour contenir le resultat */ if ( size < len ) return -1; len = i - METHOD_SIZE; memcpy(*res, &url[METHOD_SIZE], len ); return len; } int main(int ac, char *av[]) { char *host = 0; int len = 0; if ( ac < 2 ) return 1; host = (char *) alloca(32); len = get_host(av[1], strlen(av[1]), &host, 32); if ( 0 < len ) printf("host: %.*s\n", len, host); else printf("ret: %d\n", len); return 0; }[^] # Re: Salaud !
Posté par forc3 . En réponse au journal Générateur de générateur de 'parser'.. Évalué à 1.
le chose fonctionne mieux. Passer peu de temps à developper c'est
avoir beaucoup de temps pour faire des tests unitaires et des
validation fonctionnelle. Et c'est fort appréciable.
> Blague à part, ce que tu dis sur la génération d'un parser HTTP à
> partir de l'EBNF m'interresse.
Et moi dont, malheureusement je ne le génère pas a partir de
l'EBNF, ce que je génère c'est un 'parser.yacc' et un 'lexer.lex'
issus de template. Voici comment cela se passe :
Première étape définir ce qui nous intéresse, c'est à dire mettre
dans un fichier server_definition.txt la syntaxe suivante non
exhaustive pour simplifier:
Voila c'est la liste de ce que mon parser va comprendre.
Maintenant générons les différents fichiers:
sh> gen_yacc
Désormais j'ai un fichier parser.yacc qui sait que CONNECTION
prend 1 argument
sh> gen_lex
Désormais je dispose d'un lexer.lex qui sait que la token
CONNECTION c'est "connection:"
sh> gen_files
Désormais dans le répertoire commands/ j'ai les fonctions
suivantes: cmd_get.c, cmd_post.c, cmd_connection.c, cmd_accept.c,
cmd_acceptencoding.c, cmd_cachecontrol.c, cmd_pragma.c.
Chacune ne seront appelées que si la grammaire est correcte.
Derniere étape:
sh> make
Je dipose maintenant d'un binaire qui comprends
server_definition.txt.
Le but final est bien sur de pas partir de server_definition.txt
mais de l'EBNF contenu dans la RFC.
Ce n'est qu'une premier étape car vous pouvez bien imaginer que il
reste un peu de parsing a faire dans les fonction cmd_xxx.
L'exemple typique c'est
GET /url HTTP/1.1.
Car mon parseur va appeler cmd_get avec comme paramètre
"/url/ HTTP/1.1"
je suis donc dans l'obligation de découper, cependant et vous me
l'accorderez facilement, ce découpage n'a rien de très compliqué.
La difficulté du parseur HTTP c'est que les valeurs peuvent
s'étendre sur plusieurs lignes, en effet la valeur d'un header
n'est pas terminée tant qu'on n'as pas trouver un autre header ou
alors la fin des headers '\r\n\r\n'.
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
peut s'ecrire
Accept-encoding: gzip;q=1.0,
identity;q=0.5,
*;q=0
C'est une des raisons pour lesquelles j'utilise de ''templates''.
Un pour le lexer et un pour le parser.
[^] # Re: glib
Posté par forc3 . En réponse au journal libc et sécurité.... Évalué à 1.
Le propos de ce journal c'est plus sur l'idee que chaque gros
développement a choisi de refaire des choses que l'on trouve
dans la libC de base.
Je veux juste mettre l'accent sur le fait qu'il n'y ai pas vraiment de raison
pour lesquelles l'argument de réinventer la roue ne s'applique
pas ici...
_ Programme pourri, utilise libc et fonctions de string pourries
_ Programme 'secure', recode un lib de base...
Pourquoi ne pas avoir fait dans la libc un lib 'secure' ?
Dans enormément de cas c'est l'API qu'il faut remettre en cause,
pourquoi ne pas diriger les jeunes developpeurs vers des apis
mieux faites ?
(parce que si t'es jeune tu penses que le java c'est ultime ...)
[^] # Re: glib
Posté par forc3 . En réponse au journal libc et sécurité.... Évalué à 1.
ce que je veux dire c'est que cette lib rends le developpement
un peu trop permissif a mon gout, Et que des bugs ne sont
jamais corriges car non bloquant.
Maintenant Glib fournit des g_string, qui sont beaucoup mieux
que de simple char *.
[^] # Re: glib
Posté par forc3 . En réponse au journal libc et sécurité.... Évalué à 2.
le problème de cette lib, c'est qu'elle utilise trop d'assert,
qu'elle est bloated, et que surtout elle ne segfault pas quand
elle devrait...
C'est pas un hasard si enormement d'appli GTK sorte des warning
sur ton terminal... Trop d'appli ne sont pas corrigée parceque justement ce ne sont pas des erreurs bloquantes.
Un strlen sur un string NULL _doit_ segfaulter...
Trop de flexibilité rends les programmeurs trop lazy ...
C'est mon point de vue. On peut ne pas etre d'accord. Mais mon
experience me conforte dans cette idée.
[^] # Re: Salaud !
Posté par forc3 . En réponse au journal Générateur de générateur de 'parser'.. Évalué à 1.
En fait c'est justement pour nous faire travailler moins.
Un parser c'est toujours chiant à ecrire et on rencontre toujours
pas mal de difficultés.
Si maintenant on arrive à ne plus y penser on se concentre alors
sur le but du developpement.
Actuellement faire un parseur qui comprends HTTP/1.1 et juste ca
ca me prends environ 20 secondes. (test unitaire compris)
C'est étendre cette idée qui m'intéresse...
[^] # Re: Et l'exemple qmail ?
Posté par forc3 . En réponse à la dépêche Exec Shield: protection contre les débordements de tampons. É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 forc3 . En réponse à la dépêche Exec Shield: protection contre les débordements de tampons. É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().