guiones y la seguridad de Shell

6

Debido a la maleabilidad de la cáscara, es difícil verificar que una el script de shell realiza su función prevista y solo que funcionan frente a la entrada contradictoria. La forma en que se comporta el shell depende del entorno, más la configuración de sus propias variables de configuración. Cada línea de comando está sujeta a múltiples niveles de expansión, evaluación e interpolación. Algunas construcciones de shell se ejecutan en subprocesos mientras que las variables que contiene la construcción se expanden en el proceso principal. Todo esto es contrario al principio KISS cuando se diseñan sistemas que podrían ser atacados.

Fuente

2012-01-20 00:13:43

3

Probablemente porque es sólo fácil de meter la pata. Cuando el PATH no está configurado correctamente, su secuencia de comandos comenzará a ejecutar los comandos incorrectos. Poner un espacio en alguna parte de una cadena puede hacer que se convierta en dos cadenas más adelante. Esto puede conducir a agujeros de seguridad explotables. En resumen: las shells te dan algunas garantías de cómo se comportará tu script, pero son demasiado débiles o demasiado complejas para una programación realmente segura.

(A esto me gustaría añadir que la programación segura es un arte en sí mismo, y metiendo la pata es posible en cualquier idioma.)

Fuente

2012-01-20 00:09:35

1

estoy de acuerdo con esa afirmación, ya que no hay nada acerca de los scripts que los hacen inherentemente insegura. Los scripts de Bash son perfectamente seguros si se siguen algunas pautas simples:

¿El script contiene información que otros no deberían poder ver? Si es así, asegúrese de que solo sea legible por el propietario.
¿El script depende de datos de entrada de alguna parte? Si es así, asegúrese de que los datos de entrada no se puedan manchar de ninguna manera, o que los datos viciados se puedan detectar y desechar.
qué importa si los demás eran para tratar de ejecutar el script ? Si es así, como con el primer punto, asegúrese de que nadie pueda ejecutarlo, y preferiblemente no lea de él. chmod 0700 es generalmente una buena idea para las secuencias de comandos que realizan funciones del sistema.
Y los casos en los que te gustaría una secuencia de comandos para tener un setuid (a través de su intérprete) son extremadamente raros

Los dos puntos que separan un guión de un programa compilado sería que la fuente es visible y que un intérprete lo ejecuta. Siempre y cuando el intérprete no se haya visto comprometido (como por ejemplo tener un pequeño inconveniente), estarás bien.

Al escribir scripts para realizar tareas del sistema, errores tipográficos y errores humanos al escribirlo representan hasta cierto punto un posible fallo de seguridad, pero ese también sería el caso con los programas compilados (y mucha gente tiende a ignore el hecho de que los programas compilados también pueden ser desmontados)

Vale la pena señalar que en la mayoría (si no en todos) los sabores de Linux, la mayoría (si no todos, de hecho, no se puede pensar en ninguno que no lo sean) los servicios se inician a través de un shellscript.

Fuente

2012-01-20 00:15:27 Jarmund

+1

Cuando un script no es legible, no es ejecutable. Setuid en scripts ni siquiera es posible. –

1

es más fácil para los chicos malos para hacer el trabajo shell script diferente (que interactúa mucho con otros procesos, trayectoria, funciones de shell, prifile)
Es más difícil para los chicos buenos para hacer frente a los datos sensibles (que pasa contraseñas, etc.)

Fuente

2012-01-20 00:17:09

Respuesta

Cuestiones relacionadas