Quand le bureau KDE et toutes ses applications seront portés sur Windows
(on s'en rapproche pour ceux qui suivent, les applications deviennent de
plus en plus stables), celui-ci envahira Windows car, contrairement à
Linux qui possède des dizaines de bureaux, il sera l'unique alternative
au bureau Windows : KDE apporterait un souffle nouveau à Windows, en
tous cas plus que le bureau de Seven.
Du coup, l'utilisateur lambda (qui est l'utilisateur très largement
majoritaire) ne verra plus la différence entre un Windows et un linux
(ou un OpenSolaris ou un BSD) qui tournera derrière et au bout du
compte, il préférera naturellement se tourner vers l'OS qui lui coûte le
moins cher.
Yves Lambert, dans le message <4b430255$0$24763$, a écrit :
Le suid est un appel noyau.
Absolument pas. C'est deux bits dans les droits d'un fichier.
Quand tu fais chmod u+s, le shell fait l'appel noyau en question quand tu lance l'exécutable.
Absolument pas.
HAL comment ça fonctionne à ton avis ?
C'est un serveur.
En exploitant une faille de HAL ou d'une autre bibliothèque privilégiée.
HAL n'est pas une bibliothèque.
JKB
Le 05-01-2010, ? propos de Re: KDE tuera Windows, Yves Lambert ?crivait dans fr.comp.os.linux.debats :
In article , JKB writes:
(iconv -f utf8 -t latin9 j'oublie de créer un alias et je le retape à chaque fois.)
La gestion des signaux n'est pas très différente sous *BSD et linux ? Je pensais que tu parlais de programmes en userland.
La gestion est la même, ce sont les bugs qui sont différents ;-)
POSIX fige la gestion des signaux ou bien c'est un choix consensuel ?
POSIX 2001 et 2001c figent un tas de choses, mais les développeurs se gauffent sur des points de détail. Exemples : - pthread_kill() avec un signal nul risque de renvoyer sous Linux un segfault alors que sous tous les autres OS POSIX, ça fonctionne. Les specs disent 'shall return ESRCH' si le thread n'existe plus et Drepper de la glibc a traduit 'should return' et balance un segfault pour raisons de performance car il ne teste pas l'existence du thread; - sig_info pas renseigné dans FreeBSD 8 alors que c'était le cas dans FreeBSD 7.x; - sigpending() qui renvoie toujours 0 sous NetBSD 4.x alors qu'il fonctionne sous 5.x... et j'en passe des vertes et des pas mures. Je ne suis pas convaincu qu'il s'agit d'un choix mas de bugs sournois.
Et OpenBSD se permet de modifier des appels parfaitement spécifiés dans Posix parce que c'est très compliqué de les rendre sûrs (aux dires de Theo). Ça permet d'avoir des comportements assez amusant de programmes qui fonctionnent partout sauf sous OpenBSD...
Ils n'ont pas le bon patch pour tourner sous OpenBSD ou bien c'est le patch OpenBSD qui les empeche de tourner correctement ?
sigaltstack() est parfaitement documenté. L'implantation d'OpenBSD est moisie et ne résiste pas à l'utilisation simultanée de la libpthread. J'ai viré ma contrainte de portabilité sous OpenBSD en raisons de ce genre de dysfonctionnement. POSIX est déjà assez compliqué pour ne pas rajouter des workaround un peu partout pour se plier aux problèmes de lecture/compréhension/bugs des différents Unix.
Je me contrefiche de la sécurité de ces machines de test
Là il était plus question de fonctionnalité que de sécurité. Ou alors j'ai pas suivi le film.
On peut sécuriser de deux façons : sécuriser directement la machine ou s'arranger pour que ladite machine ne soit pas accessible sauf au travers de frontaux. C'est pour cela que mes frontaux sont tous sous Linux autre chose que x86 ou VMS et que mes machines de calcul tournent sous du Solaris ou du xBSD. Maintenir une debian à jour, c'est très facile et ça ne provoque que très peu d'indisponibilité.
Vu que tu n'es pas sur i386, je présume que tu as ta propre ferme de compilation, il n'y a pas grand chose dans les dépots binaires hors x86, avec debian, non ?
Les dépôts binaires contiennent toutes les architectures (pour les mirroirs, c'est différent).
Idem pour un VMS. Pour un xBSD ou un Solaris, c'est autre chose.
Et Debian/BSD ça ne te tente pas ?
Ce serait sur un noyau NetBSD, je ne dirais pas. Le noyau FreeBSD ayant déjà des problèmes avec le userland FreeBSD, je ne tente pas l'expérience tout de suite ;-)
car elles ne sont pas directement sur le grand ternet (adresses non routables et derrière des firewall sérieux). Les frontales sont toutes sous debian avec les patches de sécurité.
LAMP c'est d'un commun :)
Dans mon cas, c'est surtout LAPR (Linux, Apache, PostgreSQL, RPL/2),
PostgreSQL est je crois un clone de INGRES. C'est plus adapté aux BD réparties, commit sur un réseau etc. non ? C'est sans doute plus stable que MySQL pour pouvoir permettre le //isem (revert commit etc.), mais est-ce qu'on peut exporter une table MySQL sur une base PostgreSQL ?
Si ça n'utilise aucune fioriture de MySQL, je ne vois pas en quoi ce serait impossible.
voir VWRR (VMS, WASD [le truc qui éclate Apache],
C'est porté sur autre chose que VMS ?
Non. Ça utilise les interruptions système (à la place des threads), interruptions qui sont accessibles depuis le userland VMS et non depuis un userland Unix.
RDB,
connais pas. ça s'interroge en SQL ?
De mémoire, oui (mais j'avoue qu'il y a longtemps que je n'ai plus touché RDB). Il y a différents frontend dont un truc qui permet de gérer des fichiers _indexés_ directement depuis les langages de programmation courants.
RPL/2) ;-) J'ai eu tellement de merdes avec MySQL que je refuse d'utiliser ce truc sur des bases sensibles.
M'en vais réviser SQL, moi. M'enfin MySQL sur une base sensible (quelle que soit l'acception du terme) c'est osé.
Si tu savais ce que je voyais...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 05-01-2010, ? propos de
Re: KDE tuera Windows,
Yves Lambert ?crivait dans fr.comp.os.linux.debats :
In article <slrnhk5u09.mka.knatschke@rayleigh.systella.fr>,
JKB <knatschke@koenigsberg.fr> writes:
(iconv -f utf8 -t latin9 j'oublie de créer un alias et je le retape à
chaque fois.)
La gestion des signaux n'est pas très différente sous *BSD et linux ? Je
pensais que tu parlais de programmes en userland.
La gestion est la même, ce sont les bugs qui sont différents ;-)
POSIX fige la gestion des signaux ou bien c'est un choix consensuel ?
POSIX 2001 et 2001c figent un tas de choses, mais les développeurs
se gauffent sur des points de détail. Exemples :
- pthread_kill() avec un signal nul risque de renvoyer sous Linux un
segfault alors que sous tous les autres OS POSIX, ça fonctionne. Les
specs disent 'shall return ESRCH' si le thread n'existe plus et
Drepper de la glibc a traduit 'should return' et balance un segfault
pour raisons de performance car il ne teste pas l'existence du
thread;
- sig_info pas renseigné dans FreeBSD 8 alors que c'était le cas
dans FreeBSD 7.x;
- sigpending() qui renvoie toujours 0 sous NetBSD 4.x alors qu'il
fonctionne sous 5.x...
et j'en passe des vertes et des pas mures. Je ne suis pas convaincu
qu'il s'agit d'un choix mas de bugs sournois.
Et OpenBSD se permet de modifier des appels parfaitement spécifiés
dans Posix parce que c'est très compliqué de les rendre sûrs (aux
dires de Theo). Ça permet d'avoir des comportements assez amusant de
programmes qui fonctionnent partout sauf sous OpenBSD...
Ils n'ont pas le bon patch pour tourner sous OpenBSD ou bien c'est le
patch OpenBSD qui les empeche de tourner correctement ?
sigaltstack() est parfaitement documenté. L'implantation d'OpenBSD
est moisie et ne résiste pas à l'utilisation simultanée de la
libpthread. J'ai viré ma contrainte de portabilité sous OpenBSD en
raisons de ce genre de dysfonctionnement. POSIX est déjà assez
compliqué pour ne pas rajouter des workaround un peu partout pour se
plier aux problèmes de lecture/compréhension/bugs des différents
Unix.
Je me contrefiche de la sécurité de ces machines de test
Là il était plus question de fonctionnalité que de sécurité. Ou alors
j'ai pas suivi le film.
On peut sécuriser de deux façons : sécuriser directement la machine
ou s'arranger pour que ladite machine ne soit pas accessible
sauf au travers de frontaux. C'est pour cela que mes frontaux sont
tous sous Linux autre chose que x86 ou VMS et que mes machines de calcul
tournent sous du Solaris ou du xBSD. Maintenir une debian à jour,
c'est très facile et ça ne provoque que très peu d'indisponibilité.
Vu que tu n'es pas sur i386, je présume que tu as ta propre ferme de
compilation, il n'y a pas grand chose dans les dépots binaires hors x86,
avec debian, non ?
Les dépôts binaires contiennent toutes les architectures (pour les
mirroirs, c'est différent).
Idem pour un VMS. Pour un xBSD ou un Solaris, c'est autre chose.
Et Debian/BSD ça ne te tente pas ?
Ce serait sur un noyau NetBSD, je ne dirais pas. Le noyau FreeBSD
ayant déjà des problèmes avec le userland FreeBSD, je ne tente pas
l'expérience tout de suite ;-)
car elles
ne sont pas directement sur le grand ternet (adresses non routables
et derrière des firewall sérieux). Les frontales sont toutes sous
debian avec les patches de sécurité.
LAMP c'est d'un commun :)
Dans mon cas, c'est surtout LAPR (Linux, Apache, PostgreSQL, RPL/2),
PostgreSQL est je crois un clone de INGRES. C'est plus adapté aux BD
réparties, commit sur un réseau etc. non ? C'est sans doute plus stable
que MySQL pour pouvoir permettre le //isem (revert commit etc.), mais
est-ce qu'on peut exporter une table MySQL sur une base PostgreSQL ?
Si ça n'utilise aucune fioriture de MySQL, je ne vois pas en quoi ce
serait impossible.
voir VWRR (VMS, WASD [le truc qui éclate Apache],
C'est porté sur autre chose que VMS ?
Non. Ça utilise les interruptions système (à la place des threads),
interruptions qui sont accessibles depuis le userland VMS et non
depuis un userland Unix.
RDB,
connais pas. ça s'interroge en SQL ?
De mémoire, oui (mais j'avoue qu'il y a longtemps que je n'ai plus
touché RDB). Il y a différents frontend dont un truc qui permet de
gérer des fichiers _indexés_ directement depuis les langages de
programmation courants.
RPL/2) ;-)
J'ai eu tellement de merdes avec MySQL que je refuse d'utiliser ce
truc sur des bases sensibles.
M'en vais réviser SQL, moi. M'enfin MySQL sur une base sensible (quelle
que soit l'acception du terme) c'est osé.
Si tu savais ce que je voyais...
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 05-01-2010, ? propos de Re: KDE tuera Windows, Yves Lambert ?crivait dans fr.comp.os.linux.debats :
In article , JKB writes:
(iconv -f utf8 -t latin9 j'oublie de créer un alias et je le retape à chaque fois.)
La gestion des signaux n'est pas très différente sous *BSD et linux ? Je pensais que tu parlais de programmes en userland.
La gestion est la même, ce sont les bugs qui sont différents ;-)
POSIX fige la gestion des signaux ou bien c'est un choix consensuel ?
POSIX 2001 et 2001c figent un tas de choses, mais les développeurs se gauffent sur des points de détail. Exemples : - pthread_kill() avec un signal nul risque de renvoyer sous Linux un segfault alors que sous tous les autres OS POSIX, ça fonctionne. Les specs disent 'shall return ESRCH' si le thread n'existe plus et Drepper de la glibc a traduit 'should return' et balance un segfault pour raisons de performance car il ne teste pas l'existence du thread; - sig_info pas renseigné dans FreeBSD 8 alors que c'était le cas dans FreeBSD 7.x; - sigpending() qui renvoie toujours 0 sous NetBSD 4.x alors qu'il fonctionne sous 5.x... et j'en passe des vertes et des pas mures. Je ne suis pas convaincu qu'il s'agit d'un choix mas de bugs sournois.
Et OpenBSD se permet de modifier des appels parfaitement spécifiés dans Posix parce que c'est très compliqué de les rendre sûrs (aux dires de Theo). Ça permet d'avoir des comportements assez amusant de programmes qui fonctionnent partout sauf sous OpenBSD...
Ils n'ont pas le bon patch pour tourner sous OpenBSD ou bien c'est le patch OpenBSD qui les empeche de tourner correctement ?
sigaltstack() est parfaitement documenté. L'implantation d'OpenBSD est moisie et ne résiste pas à l'utilisation simultanée de la libpthread. J'ai viré ma contrainte de portabilité sous OpenBSD en raisons de ce genre de dysfonctionnement. POSIX est déjà assez compliqué pour ne pas rajouter des workaround un peu partout pour se plier aux problèmes de lecture/compréhension/bugs des différents Unix.
Je me contrefiche de la sécurité de ces machines de test
Là il était plus question de fonctionnalité que de sécurité. Ou alors j'ai pas suivi le film.
On peut sécuriser de deux façons : sécuriser directement la machine ou s'arranger pour que ladite machine ne soit pas accessible sauf au travers de frontaux. C'est pour cela que mes frontaux sont tous sous Linux autre chose que x86 ou VMS et que mes machines de calcul tournent sous du Solaris ou du xBSD. Maintenir une debian à jour, c'est très facile et ça ne provoque que très peu d'indisponibilité.
Vu que tu n'es pas sur i386, je présume que tu as ta propre ferme de compilation, il n'y a pas grand chose dans les dépots binaires hors x86, avec debian, non ?
Les dépôts binaires contiennent toutes les architectures (pour les mirroirs, c'est différent).
Idem pour un VMS. Pour un xBSD ou un Solaris, c'est autre chose.
Et Debian/BSD ça ne te tente pas ?
Ce serait sur un noyau NetBSD, je ne dirais pas. Le noyau FreeBSD ayant déjà des problèmes avec le userland FreeBSD, je ne tente pas l'expérience tout de suite ;-)
car elles ne sont pas directement sur le grand ternet (adresses non routables et derrière des firewall sérieux). Les frontales sont toutes sous debian avec les patches de sécurité.
LAMP c'est d'un commun :)
Dans mon cas, c'est surtout LAPR (Linux, Apache, PostgreSQL, RPL/2),
PostgreSQL est je crois un clone de INGRES. C'est plus adapté aux BD réparties, commit sur un réseau etc. non ? C'est sans doute plus stable que MySQL pour pouvoir permettre le //isem (revert commit etc.), mais est-ce qu'on peut exporter une table MySQL sur une base PostgreSQL ?
Si ça n'utilise aucune fioriture de MySQL, je ne vois pas en quoi ce serait impossible.
voir VWRR (VMS, WASD [le truc qui éclate Apache],
C'est porté sur autre chose que VMS ?
Non. Ça utilise les interruptions système (à la place des threads), interruptions qui sont accessibles depuis le userland VMS et non depuis un userland Unix.
RDB,
connais pas. ça s'interroge en SQL ?
De mémoire, oui (mais j'avoue qu'il y a longtemps que je n'ai plus touché RDB). Il y a différents frontend dont un truc qui permet de gérer des fichiers _indexés_ directement depuis les langages de programmation courants.
RPL/2) ;-) J'ai eu tellement de merdes avec MySQL que je refuse d'utiliser ce truc sur des bases sensibles.
M'en vais réviser SQL, moi. M'enfin MySQL sur une base sensible (quelle que soit l'acception du terme) c'est osé.
Si tu savais ce que je voyais...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Stephane TOUGARD
Nicolas George a perdu son temps a nous dire:
Si smtpd accepte tous les emails, les mets dans un spool, puis tu traites l'anti-spam avec un nombre connu de process, tu vas mettre du delai dans le traitement, mais ton service sera toujours debout.
Et tu vas émettre un nombre incalculable de bounces et te retrouver dans toutes les blacklists du monde en moins de deux jours.
Et pourquoi veux-tu que j'emette des bounces ? Un anti-spam n'est pas la pour emettre des bounces mais pour attriber un spam rate a un email que l'utilisateur final peut filtrer a son bon besoin.
-- http://unices.over-blog.com/ Un Francais en Chine
Nicolas George a perdu son temps a nous dire:
Si smtpd accepte tous les emails, les mets dans un spool, puis tu
traites l'anti-spam avec un nombre connu de process, tu vas mettre du
delai dans le traitement, mais ton service sera toujours debout.
Et tu vas émettre un nombre incalculable de bounces et te retrouver dans
toutes les blacklists du monde en moins de deux jours.
Et pourquoi veux-tu que j'emette des bounces ? Un anti-spam n'est pas la
pour emettre des bounces mais pour attriber un spam rate a un email que
l'utilisateur final peut filtrer a son bon besoin.
--
http://unices.over-blog.com/ Un Francais en Chine
Si smtpd accepte tous les emails, les mets dans un spool, puis tu traites l'anti-spam avec un nombre connu de process, tu vas mettre du delai dans le traitement, mais ton service sera toujours debout.
Et tu vas émettre un nombre incalculable de bounces et te retrouver dans toutes les blacklists du monde en moins de deux jours.
Et pourquoi veux-tu que j'emette des bounces ? Un anti-spam n'est pas la pour emettre des bounces mais pour attriber un spam rate a un email que l'utilisateur final peut filtrer a son bon besoin.
-- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
Yves Lambert a perdu son temps a nous dire:
HAL comment ça fonctionne à ton avis ? Comment tu fais pour monter, démonter un volume, éteindre, redémarrer une machine ou la mettre en hibernation sans etre root ?
HAL ? Celui de Discovery One ?
Je vois toujours pas le rapport avec des "bibliotheques".
En exploitant une faille de HAL ou d'une autre bibliothèque privilégiée.
Va falloir que tu donnes plus de details que ca. Parce que la, je penche plutot comme le petit Nicolas : "Techniquement, ca veut rien dire".
-- http://unices.over-blog.com/ Un Francais en Chine
Yves Lambert a perdu son temps a nous dire:
HAL comment ça fonctionne à ton avis ? Comment tu fais pour monter,
démonter un volume, éteindre, redémarrer une machine ou la mettre en
hibernation sans etre root ?
HAL ? Celui de Discovery One ?
Je vois toujours pas le rapport avec des "bibliotheques".
En exploitant une faille de HAL ou d'une autre bibliothèque privilégiée.
Va falloir que tu donnes plus de details que ca. Parce que la, je penche
plutot comme le petit Nicolas : "Techniquement, ca veut rien dire".
--
http://unices.over-blog.com/ Un Francais en Chine
HAL comment ça fonctionne à ton avis ? Comment tu fais pour monter, démonter un volume, éteindre, redémarrer une machine ou la mettre en hibernation sans etre root ?
HAL ? Celui de Discovery One ?
Je vois toujours pas le rapport avec des "bibliotheques".
En exploitant une faille de HAL ou d'une autre bibliothèque privilégiée.
Va falloir que tu donnes plus de details que ca. Parce que la, je penche plutot comme le petit Nicolas : "Techniquement, ca veut rien dire".
-- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
Yves Lambert a perdu son temps a nous dire:
Tiu n'es absolument pas obligé d'en accepter tant à la fois. Tu les traite 1 par 1 et le spammeur attend. Le temps total de traitement est le meme.
Toi, t'as jamais gere un serveur MX. Tu sais, un MX, c'est pas fait QUE de spam et d'anti-spam. Dans la vraie vie, il y a aussi des vrais emails et des vrais gens qui recoivent ces vrais emails.
-- http://unices.over-blog.com/ Un Francais en Chine
Yves Lambert a perdu son temps a nous dire:
Tiu n'es absolument pas obligé d'en accepter tant à la fois. Tu les
traite 1 par 1 et le spammeur attend. Le temps total de traitement est
le meme.
Toi, t'as jamais gere un serveur MX. Tu sais, un MX, c'est pas fait QUE
de spam et d'anti-spam. Dans la vraie vie, il y a aussi des vrais emails
et des vrais gens qui recoivent ces vrais emails.
--
http://unices.over-blog.com/ Un Francais en Chine
Tiu n'es absolument pas obligé d'en accepter tant à la fois. Tu les traite 1 par 1 et le spammeur attend. Le temps total de traitement est le meme.
Toi, t'as jamais gere un serveur MX. Tu sais, un MX, c'est pas fait QUE de spam et d'anti-spam. Dans la vraie vie, il y a aussi des vrais emails et des vrais gens qui recoivent ces vrais emails.
-- http://unices.over-blog.com/ Un Francais en Chine
talon
Yves Lambert wrote:
> Faire tourner un programme n'est pas vraiment un probleme sur Unix, pas > besoin d'un compilo pour ca.
Il n'est pas question de le faire tourner mais de le linker avec une bibliothèque vulnérable qui permet une escalade de privilège puis de le faire tourner. Explique comment tu fais sans compiler ?
Mais il doit bien exister des systèmes de compilation minuscules comme tcc que tu peux faire venir si tu as déjà obtenu un accés local. A mon avis ce genre de sécurité c'est la sécurité par l'absurdité. Si tu as déjà un compte local, en général vu que tous les systèmes ont des failles d"élévation de sécurité, c'est game over face à un pirate professionnel. Peut être OpenBSD permet de dormir un peu mieux sur ses deux oreilles.
--
Michel TALON
Yves Lambert <yl@bidart.net> wrote:
> Faire tourner un programme n'est pas vraiment un probleme sur Unix, pas
> besoin d'un compilo pour ca.
Il n'est pas question de le faire tourner mais de le linker avec une
bibliothèque vulnérable qui permet une escalade de privilège puis de
le faire tourner. Explique comment tu fais sans compiler ?
Mais il doit bien exister des systèmes de compilation minuscules comme
tcc que tu peux faire venir si tu as déjà obtenu un accés local. A mon
avis ce genre de sécurité c'est la sécurité par l'absurdité. Si tu as
déjà un compte local, en général vu que tous les systèmes ont des
failles d"élévation de sécurité, c'est game over face à un pirate
professionnel. Peut être OpenBSD permet de dormir un peu mieux sur ses
deux oreilles.
> Faire tourner un programme n'est pas vraiment un probleme sur Unix, pas > besoin d'un compilo pour ca.
Il n'est pas question de le faire tourner mais de le linker avec une bibliothèque vulnérable qui permet une escalade de privilège puis de le faire tourner. Explique comment tu fais sans compiler ?
Mais il doit bien exister des systèmes de compilation minuscules comme tcc que tu peux faire venir si tu as déjà obtenu un accés local. A mon avis ce genre de sécurité c'est la sécurité par l'absurdité. Si tu as déjà un compte local, en général vu que tous les systèmes ont des failles d"élévation de sécurité, c'est game over face à un pirate professionnel. Peut être OpenBSD permet de dormir un peu mieux sur ses deux oreilles.
--
Michel TALON
Nicolas George
Michel Talon, dans le message <hhvget$23q4$, a écrit :
Mais il doit bien exister des systèmes de compilation minuscules comme tcc que tu peux faire venir si tu as déjà obtenu un accés local.
Ce n'est même pas nécessaire. Un compilateur ne fait strictement rien de magique, il se contente de produire un fichier avec le bon contenu.
Michel Talon, dans le message <hhvget$23q4$1@asmodee.lpthe.jussieu.fr>,
a écrit :
Mais il doit bien exister des systèmes de compilation minuscules comme
tcc que tu peux faire venir si tu as déjà obtenu un accés local.
Ce n'est même pas nécessaire. Un compilateur ne fait strictement rien de
magique, il se contente de produire un fichier avec le bon contenu.
Michel Talon, dans le message <hhvget$23q4$, a écrit :
Mais il doit bien exister des systèmes de compilation minuscules comme tcc que tu peux faire venir si tu as déjà obtenu un accés local.
Ce n'est même pas nécessaire. Un compilateur ne fait strictement rien de magique, il se contente de produire un fichier avec le bon contenu.
Patrice Karatchentzeff
(Michel Talon) a écrit :
Mais il doit bien exister des systèmes de compilation minuscules comme tcc que tu peux faire venir si tu as déjà obtenu un accés local. A mon avis ce genre de sécurité c'est la sécurité par l'absurdité. Si tu as déjà un compte local, en général vu que tous les systèmes ont des failles d"élévation de sécurité, c'est game over face à un pirate professionnel.
Avec ta façon de raisonner, on laisse tout ouvert parce que cela ne sert à rien de fermer : il y aura toujours quelqu'un pour percer.
C'est de la prudence élémentaire : on n'ouvre que ce qui est nécessaire. Sur un serveur (qui ne sert pas à la compil), un compilo n'a rien à foutre.
Il est évident qu'un serveur autorisant un accès local est vulnérable. Comme *tout* serveur accessible, quelque soit le moyen.
Mais il doit bien exister des systèmes de compilation minuscules
comme tcc que tu peux faire venir si tu as déjà obtenu un accés
local. A mon avis ce genre de sécurité c'est la sécurité par
l'absurdité. Si tu as déjà un compte local, en général vu que tous
les systèmes ont des failles d"élévation de sécurité, c'est game
over face à un pirate professionnel.
Avec ta façon de raisonner, on laisse tout ouvert parce que cela ne
sert à rien de fermer : il y aura toujours quelqu'un pour percer.
C'est de la prudence élémentaire : on n'ouvre que ce qui est
nécessaire. Sur un serveur (qui ne sert pas à la compil), un compilo
n'a rien à foutre.
Il est évident qu'un serveur autorisant un accès local est vulnérable.
Comme *tout* serveur accessible, quelque soit le moyen.
Mais il doit bien exister des systèmes de compilation minuscules comme tcc que tu peux faire venir si tu as déjà obtenu un accés local. A mon avis ce genre de sécurité c'est la sécurité par l'absurdité. Si tu as déjà un compte local, en général vu que tous les systèmes ont des failles d"élévation de sécurité, c'est game over face à un pirate professionnel.
Avec ta façon de raisonner, on laisse tout ouvert parce que cela ne sert à rien de fermer : il y aura toujours quelqu'un pour percer.
C'est de la prudence élémentaire : on n'ouvre que ce qui est nécessaire. Sur un serveur (qui ne sert pas à la compil), un compilo n'a rien à foutre.
Il est évident qu'un serveur autorisant un accès local est vulnérable. Comme *tout* serveur accessible, quelque soit le moyen.
*toutes* les distributions sont basée sur la slack. Par définition.
Non, toutes les distrib sont basees sur la SLS (Slack incluse).
le grand retour de la Secte du Logiciel Solaire :)
talon
Patrice Karatchentzeff wrote:
C'est de la prudence élémentaire : on n'ouvre que ce qui est nécessaire.
Oui.
Sur un serveur (qui ne sert pas à la compil), un compilo n'a rien à foutre.
Certes il n'a aucune raison d'y être, mais croire que sa présence ou son absence modifient en quoi que ce soit la sécurité est de la démence.
Il est évident qu'un serveur autorisant un accès local est vulnérable.
Accés local -> accés root de façon à peu près certaine. C'est la raison pour laquelle il faut faire tourner uniquement les services nécessaires sur l'extérieur et être raisonnablement surs que ces services n'ont pas de trou. C'est aussi la raison pour laquelle on préconise un firewall vers l'extérieur, un vers l'intérieur et les services entre les deux, pour essayer de limiter la contagion. Les firewalls doivent être inaccessibles sauf depuis une console physique.
Comme *tout* serveur accessible, quelque soit le moyen.
En particulier s'il est physiquement accessible, ce n'est même pas la peine de se poser la question de sa sécurité logicielle.
C'est de la prudence élémentaire : on n'ouvre que ce qui est
nécessaire.
Oui.
Sur un serveur (qui ne sert pas à la compil), un compilo
n'a rien à foutre.
Certes il n'a aucune raison d'y être, mais croire que sa présence ou son
absence modifient en quoi que ce soit la sécurité est de la démence.
Il est évident qu'un serveur autorisant un accès local est vulnérable.
Accés local -> accés root de façon à peu près certaine. C'est la raison
pour laquelle il faut faire tourner uniquement les services nécessaires
sur l'extérieur et être raisonnablement surs que ces services n'ont pas de
trou. C'est aussi la raison pour laquelle on préconise un firewall vers
l'extérieur, un vers l'intérieur et les services entre les deux, pour
essayer de limiter la contagion. Les firewalls doivent être
inaccessibles sauf depuis une console physique.
Comme *tout* serveur accessible, quelque soit le moyen.
En particulier s'il est physiquement accessible, ce n'est même pas la
peine de se poser la question de sa sécurité logicielle.
C'est de la prudence élémentaire : on n'ouvre que ce qui est nécessaire.
Oui.
Sur un serveur (qui ne sert pas à la compil), un compilo n'a rien à foutre.
Certes il n'a aucune raison d'y être, mais croire que sa présence ou son absence modifient en quoi que ce soit la sécurité est de la démence.
Il est évident qu'un serveur autorisant un accès local est vulnérable.
Accés local -> accés root de façon à peu près certaine. C'est la raison pour laquelle il faut faire tourner uniquement les services nécessaires sur l'extérieur et être raisonnablement surs que ces services n'ont pas de trou. C'est aussi la raison pour laquelle on préconise un firewall vers l'extérieur, un vers l'intérieur et les services entre les deux, pour essayer de limiter la contagion. Les firewalls doivent être inaccessibles sauf depuis une console physique.
Comme *tout* serveur accessible, quelque soit le moyen.
En particulier s'il est physiquement accessible, ce n'est même pas la peine de se poser la question de sa sécurité logicielle.
