[pyar] Peligrosidad de un lambda

[Ricardo Araoz]

On 01/10/10 18:22, QliX=D! [aka EHB] wrote:
> 2010/10/1 Ricardo Araoz <ricaraoz en gmail.com>:
> [...]
>   
>> Si, conozco administradores que bloquean tooooodos los lugares de download,
>> especialmente sourceforge. Seguro que también hay administradores que
>> directamente bloquean internet y correo externo, a la vez que quitan
>> posibilidad de acceder a almacenamiento externo (cd, usb, etc).
>> Pero eso es seguridad sin criterio.
>>     
> No, eso es tomar medidas extremas de seguridad para no educar a tus
> empleados respecto al tema.
> Este tipo de normas se toman muchas veces como resultado de la cultura
> general de la empresa.
> Si uno educa a sus empleados sobre riesgos, puede lograr flexibilizar
> en ciertos niveles la seguridad, pero no en todos.
> Aunque puede ser que algunos hagan cosas por que si, sin un criterio
> realista, pero bueno, tambien tenes lugares donde la seguridad es un
> viva la pepa (¿75% de las pymes?). Y que despues tienen largas
> perdidas de tiempo productivo (AKA plata) por problemas operativos
> debido a:
> * Gusanos
> * Virus
> * Uso indebido de recursos (ej1. una pyme de un conocido compro mas
> ancho de banda por que la conexion era lenta... por que habia gente
> bajando torrentillos a morir!, ej2. Se compro mas espacio de hosting
> de su sitio web... por que colgaban ISOs de boludeo y peliculas para
> "la comunidad")
>
> [...]
>   
>> El OP simplemente preguntó por un raw_input() y su pregunta estaba dirigida
>> a usar un lambda.
>> De ahí partieron en una caza de gansos salvajes con
>> preocupaciones de seguridad dignas de la CIA.
>>     
> No, la NSA en todo caso, y casa de gansos no, creo que simplemente fue
> aportar los puntos flojos que se vieron de esa implementacion.
>
>   
>> Antes de todo eso creo que es
>> racional preguntar el caso de uso y *recien* ahí dar curso a la seguridad si
>> hace falta.
>>     
> Caso de uso = cualquiera, Progamar inseguramente es programar mal, y
> programar mal no tiene excusas de entorno.
> Cuando uno empieza a ser descuidado de ves en cuando, termina siendo
> descuidado en cualquier momento sin darse cuenta del "entorno".
> Al menos es mi idea del asunto...
>
>   
>> Recordemos que no hay que optimizar prematuramente y creo que
>> algo similar se puede aplicar a la seguridad.
>>
>>     
>
> AAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> AAAAAAAHHHHHHHH!!!!!!!
> AAAHHHHH!
> No. nononononono.
> Nooooo..
> N-O.
> no.
> De verdad. No.
>
> Que la mayoria de los programadores no tengan un concepto de
> seguridad, y terminemos viendo basura y horrores en algunas
> aplicaciones, sea java c# o python, no implica que debamos seguir de
> esa forma.
>
> Los desarrolladores deben HACERSE RESPONSABLES de la seguridad de su
> aplicacion como algo integral, no metiendo un servicio por SSL...
> nonono.
>
> By Design hay que implementar la seguridad dentro de lo posible, para
> facilitar las cosas.
>   

Creo que te referís sólo a aplicaciones web.

Veamos el caso de eval(). Digamos que lo que meto dentro de eval
proviene de una base de datos en la que tengo scripts que permito
modificar a ciertos usuarios de confianza. Ves como siempre hay que usar
el criterio?
Digamos que lo que meto dentro de eval proviene del usuario local de la
máquina y NO hago setuid. En ese caso con eval sólo se puede hacer lo
que el usuario de todas maneras puede hacer. Ves como siempre hay que
usar el criterio?
En el caso que se presentó de un script que usa eval y setuid, acá el
problema no es el eval(). Es el setuid!!!! Ves como siempre hay que usar
el criterio?