Mailinglist Archive: opensuse-es (1511 mails)
| < Previous | Next > |
Re: [suse-linux-s] Fwd: [suse-security] SUSE Security Announcement: cron local privilege escalation (SUSE-SA:2006:027)
- From: "Carlos E. R." <robin.listas@xxxxxxxxxxxxxx>
- Date: Fri, 2 Jun 2006 01:58:54 +0200 (CEST)
- Message-id: <Pine.LNX.4.61.0606020136590.24267@xxxxxxxxxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
El 2006-06-02 a las 00:30 +0200, miguel gmail escribió:
> > Hay hasta programs de esos de munchas pelas, que se dedican a auditar el
> > código y encontrarte problemillas y problemones.
>
> Imagino que esos programas no hacen sino aplicar reglas previamente
> definidas. Pues vaya. Yo quiero saber qué metología habría que seguir
> en una programación segura.
Si, bueno, imagino que aplican heurísticas que han ido desarrollando, pero
no precisamente lo que te explican en un libro de metodología, porque en
una buena metodología (que yo no he estudiado las de verdad, soy teleco,
no informático) puedes tardar un año hasta escribir la primera linea de
código. Esos programas son a posteriori, para cazar errores después de
producidos por no seguir un buen método.
> > No se ahora mismo un libro de eso... hay mucho "arte". Un buen libro de
> > programación, realmente bueno y no un sacacuartos, debe explicar esas
> > cosas.
>
> Uhm... realmente... un libro de programación para eso?? No sé, mas
> bien un libro de seguridad en si mismo.
Rafa ha dicho alguno. En informática tienen asignaturas enteras de
metodologías.
> > > Se que hay metodologías específicas de desarrollo a prueba de
> > > errores (por ejemplo, uno no espera que un avión se caiga por un
> > > error de sw,
> >
> > ¿NOOO? Yo si...
>
> 'sagerao'!
¡JA! :-P
> > Primer avión que cruza el ecuador: flip, panza arriba. Y el segundo,
> > flip.
> > Y el tercero, flip.
> >
> > No comment...
>
> Lo había oido... siempre pense que era una leyenda urbana. Veamos,
> seamos un poco practicos.
No, no lo es. Quien me lo contó, hace unos cuantos años, tenía motivos
para saberlo de verdad.
>
> Cuantos aviones vuelan cada día? Miles.
> Cuantos tienen problemas? Algunos
> Cuantos tienen problemas debido al sw? Bueno, no lo sabemos realmente.
Eso es el problema, no se sabe. No se publica, eso se oculta.
Mira, en yanquilandia tenían un grupo de la nasa, si no recuerdo mal, cuyo
trabajo era recibir anónimamente "denuncias" de los pilotos y otros
técnicos de problemas que habían encontrado, pero que no podían denunciar
oficialmente porque podían despedirlos. Esa gente localizó muchos fallos
de muchos tipos. Desafortunadamente, recortaron gastos y lo quitaron, o
quitaron la gente que luego los analizaban. (Lo se por un estudio que
salió en el ieee spectrum hace poco sobre la seguridad aerea relacionada
con las interferencias radioeléctricas).
No es el único problema informático gordo que conozco, he oído de otros.
Un avión que es temido por los pilotos es el airbus, porque toma sus
propias decisiones. Me contaron de un avión que estaba aterrizando, el
piloto decide abortar por no se que, tira de gas y de palanca a tope para
remontar el vuelo, y el ordenador cancela la orden y mantiene vuelo
nivelado, estrellándose.
¿Porqué? Pues porque el ordenador calculó que con esa orden del piloto el
avión iba a entrar en pérdida y estrellarse de cola a mayor altura, y
decidió que era mejor estrellarse en horizontal... No es exactamente un
fallo de software, es más bien un fallo de entrenamiento en lo que supone
un cacharro tan sofisticado.
> Hombre, estoy pensando que ha habido satélites que se han estrellado,
> perdido o cosas parecidas por errores como usar kms en un modulo y
> millas en otro, confundir el 'arriba' con el 'abajo' (daba gravedad
> negativa en lugar de positiva, con lo que el satelite de cuyo nombre
> no quier acordarme no abrío el paracaidas y se estampó contra el suelo
> con la tele dándolo en directo, y es que la gravedad nunca alcanzo
> cierto valor... positivo). Pero esto son errores de comunicación o
> como mucho de diseno, no de desarrollo _en si_.
El de la Nasa con la misión a Marte entre las medidas imperiales y las del
SI (la nasa usa el SI) fué muy estudiado. Fué un fallo de método en la
empresa, que no se leyó las especificaciones y trabajaron en medidas
imperiales en contra de las especificaciones de la nasa.
De esos hay muy gordos.
Los rusos perdieron otro. A ver si me acuerdo... ah, estos es que usanban
la misma cpu para análisis y experimentos y para navegación. Programaron
remotamente (en vuelo) un experimento, y colaron un bug. La cpu hizo el
experimento (enfocar una cámara, por ejemplo) y al terminar no pudo tomar
el control de navegación y reorientar la antena hacia la Tierra...
silencio absoluto, se perdió. Los americanos usaban dos procesadores, en
ese tiempo al menos. Falló la orientación, pero por culpa de un bug en el
código que mandaron desde la Tierra.
> Pero si que se que hay metodologías de desarrollo que minimizan al
> mínimo minimísimo el numero de errores (y creo recordar que valen 50
> veces más que un desarrollo 'normal')
Hubo un número del ieee dedicado precisamente a
fallos de software... uno de los artículos era de una empresa inglesa que
garantizaba código libre de fallos a la primera. O casi. Y lo consiguen.
Son los que dije que pueden estar un año o dos estudiando antes de
escribir una sóla linea de código.
- --
Saludos
Carlos Robinson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFEf39AtTMYHG2NR9URAuk6AJ0UEwENlwtmQWG+nazxKZmERfrafgCdFixu
ySERaZ5yare/m/+aV3DhsOM=
=R9gm
-----END PGP SIGNATURE-----
--
Para dar de baja la suscripción, mande un mensaje a:
suse-linux-s-unsubscribe@xxxxxxxx
Para obtener el resto de direcciones-comando, mande
un mensaje a:
suse-linux-s-help@xxxxxxxx
Hash: SHA1
El 2006-06-02 a las 00:30 +0200, miguel gmail escribió:
> > Hay hasta programs de esos de munchas pelas, que se dedican a auditar el
> > código y encontrarte problemillas y problemones.
>
> Imagino que esos programas no hacen sino aplicar reglas previamente
> definidas. Pues vaya. Yo quiero saber qué metología habría que seguir
> en una programación segura.
Si, bueno, imagino que aplican heurísticas que han ido desarrollando, pero
no precisamente lo que te explican en un libro de metodología, porque en
una buena metodología (que yo no he estudiado las de verdad, soy teleco,
no informático) puedes tardar un año hasta escribir la primera linea de
código. Esos programas son a posteriori, para cazar errores después de
producidos por no seguir un buen método.
> > No se ahora mismo un libro de eso... hay mucho "arte". Un buen libro de
> > programación, realmente bueno y no un sacacuartos, debe explicar esas
> > cosas.
>
> Uhm... realmente... un libro de programación para eso?? No sé, mas
> bien un libro de seguridad en si mismo.
Rafa ha dicho alguno. En informática tienen asignaturas enteras de
metodologías.
> > > Se que hay metodologías específicas de desarrollo a prueba de
> > > errores (por ejemplo, uno no espera que un avión se caiga por un
> > > error de sw,
> >
> > ¿NOOO? Yo si...
>
> 'sagerao'!
¡JA! :-P
> > Primer avión que cruza el ecuador: flip, panza arriba. Y el segundo,
> > flip.
> > Y el tercero, flip.
> >
> > No comment...
>
> Lo había oido... siempre pense que era una leyenda urbana. Veamos,
> seamos un poco practicos.
No, no lo es. Quien me lo contó, hace unos cuantos años, tenía motivos
para saberlo de verdad.
>
> Cuantos aviones vuelan cada día? Miles.
> Cuantos tienen problemas? Algunos
> Cuantos tienen problemas debido al sw? Bueno, no lo sabemos realmente.
Eso es el problema, no se sabe. No se publica, eso se oculta.
Mira, en yanquilandia tenían un grupo de la nasa, si no recuerdo mal, cuyo
trabajo era recibir anónimamente "denuncias" de los pilotos y otros
técnicos de problemas que habían encontrado, pero que no podían denunciar
oficialmente porque podían despedirlos. Esa gente localizó muchos fallos
de muchos tipos. Desafortunadamente, recortaron gastos y lo quitaron, o
quitaron la gente que luego los analizaban. (Lo se por un estudio que
salió en el ieee spectrum hace poco sobre la seguridad aerea relacionada
con las interferencias radioeléctricas).
No es el único problema informático gordo que conozco, he oído de otros.
Un avión que es temido por los pilotos es el airbus, porque toma sus
propias decisiones. Me contaron de un avión que estaba aterrizando, el
piloto decide abortar por no se que, tira de gas y de palanca a tope para
remontar el vuelo, y el ordenador cancela la orden y mantiene vuelo
nivelado, estrellándose.
¿Porqué? Pues porque el ordenador calculó que con esa orden del piloto el
avión iba a entrar en pérdida y estrellarse de cola a mayor altura, y
decidió que era mejor estrellarse en horizontal... No es exactamente un
fallo de software, es más bien un fallo de entrenamiento en lo que supone
un cacharro tan sofisticado.
> Hombre, estoy pensando que ha habido satélites que se han estrellado,
> perdido o cosas parecidas por errores como usar kms en un modulo y
> millas en otro, confundir el 'arriba' con el 'abajo' (daba gravedad
> negativa en lugar de positiva, con lo que el satelite de cuyo nombre
> no quier acordarme no abrío el paracaidas y se estampó contra el suelo
> con la tele dándolo en directo, y es que la gravedad nunca alcanzo
> cierto valor... positivo). Pero esto son errores de comunicación o
> como mucho de diseno, no de desarrollo _en si_.
El de la Nasa con la misión a Marte entre las medidas imperiales y las del
SI (la nasa usa el SI) fué muy estudiado. Fué un fallo de método en la
empresa, que no se leyó las especificaciones y trabajaron en medidas
imperiales en contra de las especificaciones de la nasa.
De esos hay muy gordos.
Los rusos perdieron otro. A ver si me acuerdo... ah, estos es que usanban
la misma cpu para análisis y experimentos y para navegación. Programaron
remotamente (en vuelo) un experimento, y colaron un bug. La cpu hizo el
experimento (enfocar una cámara, por ejemplo) y al terminar no pudo tomar
el control de navegación y reorientar la antena hacia la Tierra...
silencio absoluto, se perdió. Los americanos usaban dos procesadores, en
ese tiempo al menos. Falló la orientación, pero por culpa de un bug en el
código que mandaron desde la Tierra.
> Pero si que se que hay metodologías de desarrollo que minimizan al
> mínimo minimísimo el numero de errores (y creo recordar que valen 50
> veces más que un desarrollo 'normal')
Hubo un número del ieee dedicado precisamente a
fallos de software... uno de los artículos era de una empresa inglesa que
garantizaba código libre de fallos a la primera. O casi. Y lo consiguen.
Son los que dije que pueden estar un año o dos estudiando antes de
escribir una sóla linea de código.
- --
Saludos
Carlos Robinson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFEf39AtTMYHG2NR9URAuk6AJ0UEwENlwtmQWG+nazxKZmERfrafgCdFixu
ySERaZ5yare/m/+aV3DhsOM=
=R9gm
-----END PGP SIGNATURE-----
--
Para dar de baja la suscripción, mande un mensaje a:
suse-linux-s-unsubscribe@xxxxxxxx
Para obtener el resto de direcciones-comando, mande
un mensaje a:
suse-linux-s-help@xxxxxxxx
| < Previous | Next > |