diff --git a/es/FAQ/admin.sgml b/es/FAQ/admin.sgml index 6e1cf8d8e4..1fcc2bd0a4 100644 --- a/es/FAQ/admin.sgml +++ b/es/FAQ/admin.sgml @@ -1,4 +1,4 @@ - + Administración de sistema @@ -1085,5 +1085,79 @@ cd /cdrom/bin # exit + + ¿Qué es un sandbox? + +

Sandbox es un término de seguridad. Puede significar dos + cosas: + + + +

Un proceso que es situado en el interior de una serie de muros + virtuales diseñados como prevención e imposibilitar + el acceso al sistema principal en caso de que alguien comprometa + la seguridad de ese proceso. + +

Se dice que el proceso es capaz de "jugar" entre los muros. + Esto significa que se supone que nada de lo que haga el proceso + referente a la ejecución de código, puede ser capaz + de romper los muros, así no es necesario hacer + auditorías detalladas de su código para poder conocer + todo lo referente a los riesgos de seguridad del proceso. + +

Los muros pueden, por ejemplo, un userid. Esta es la + definición usada en las páginas man de seguridad y del + programa named. + +

Veamos como ejemplo el servicio 'ntalk' (consultar /etc/inetd.conf). + Este servicio solía ejecutarse con el userid de root. Ahora se + ejecuta con el userid tty. El usuario tty esta diseñado para ser + usado como usuario sandbox, dificultando así la tarea de un + intruso que haya conseguido penetrar en el sistema a través del + servicio ntalk. De esta manera, el intruso solo puede afectar a los + servicios, programas o procesos propiedad del usuario tty. + + + +

Un proceso que se ha situado en el interior de una simulación + de la máquina. Esto es más hard-core. Básicamente, + significa que alguien que sea capaz de penetrar en el proceso, + creerá que ha penetrado en el sistema principal, pero de hecho, + ha penetrado en una simulación de esa máquina y no puede + modificar ningún dato real. + +

El sistema más común de conseguir esto es crear un + entorno simulado en un subdirectorio y ejecutar los procesos en ese + subdirectorio mediante chroot (la raiz "/" para ese proceso es este + directorio, no la raiz "/" real del sistema). + +

Otro sistema habitual es montar un sistema de ficheros de solo + lectura y a continuació,n crear un nivel de sistema de ficheros + por encima del anterior que dé al proceso la sensación + de encontrarse en un sistema de ficheros de lectura/escritura. El + proceso creerá que es capaz de escribir esos ficheros, pero + sólo el proceso ve los efectos; otros procesos del sistema + no ven absolutamente nada. + +

Se intenta crear este tipo de sandbox totalmente transparentes para + que el usuario (o intruso) no se de cuenta que está en él. + + + +

UNIX implementa dos tipos de sandboxes. Uno es a nivel de procesos, + y el otro es a nivel de usuarios (userid). + +

Cada proceso UNIX es totalmente independiente de cualquier otro proceso + UNIX. Un proceso no puede modificar el espacio de direcciones de otro. Es + diferente a los sistemas Windows en los que un proceso puede sobreescribir + facilmente el espacio de direcciones de otro proceso, probocando una caida + de la máquina. + +

Un proceso UNIX es propiedad de un userid determinado. Si el userid no + es el usuario root, éste solo podrá acceder a los procesos + de su propiedad, evitando la intrusión en procesos ajenos. El + userid también se usa como sistema de protección para datos + grabados en disco. + diff --git a/es_ES.ISO8859-1/FAQ/admin.sgml b/es_ES.ISO8859-1/FAQ/admin.sgml index 6e1cf8d8e4..1fcc2bd0a4 100644 --- a/es_ES.ISO8859-1/FAQ/admin.sgml +++ b/es_ES.ISO8859-1/FAQ/admin.sgml @@ -1,4 +1,4 @@ - + Administración de sistema @@ -1085,5 +1085,79 @@ cd /cdrom/bin # exit + + ¿Qué es un sandbox? + +

Sandbox es un término de seguridad. Puede significar dos + cosas: + + + +

Un proceso que es situado en el interior de una serie de muros + virtuales diseñados como prevención e imposibilitar + el acceso al sistema principal en caso de que alguien comprometa + la seguridad de ese proceso. + +

Se dice que el proceso es capaz de "jugar" entre los muros. + Esto significa que se supone que nada de lo que haga el proceso + referente a la ejecución de código, puede ser capaz + de romper los muros, así no es necesario hacer + auditorías detalladas de su código para poder conocer + todo lo referente a los riesgos de seguridad del proceso. + +

Los muros pueden, por ejemplo, un userid. Esta es la + definición usada en las páginas man de seguridad y del + programa named. + +

Veamos como ejemplo el servicio 'ntalk' (consultar /etc/inetd.conf). + Este servicio solía ejecutarse con el userid de root. Ahora se + ejecuta con el userid tty. El usuario tty esta diseñado para ser + usado como usuario sandbox, dificultando así la tarea de un + intruso que haya conseguido penetrar en el sistema a través del + servicio ntalk. De esta manera, el intruso solo puede afectar a los + servicios, programas o procesos propiedad del usuario tty. + + + +

Un proceso que se ha situado en el interior de una simulación + de la máquina. Esto es más hard-core. Básicamente, + significa que alguien que sea capaz de penetrar en el proceso, + creerá que ha penetrado en el sistema principal, pero de hecho, + ha penetrado en una simulación de esa máquina y no puede + modificar ningún dato real. + +

El sistema más común de conseguir esto es crear un + entorno simulado en un subdirectorio y ejecutar los procesos en ese + subdirectorio mediante chroot (la raiz "/" para ese proceso es este + directorio, no la raiz "/" real del sistema). + +

Otro sistema habitual es montar un sistema de ficheros de solo + lectura y a continuació,n crear un nivel de sistema de ficheros + por encima del anterior que dé al proceso la sensación + de encontrarse en un sistema de ficheros de lectura/escritura. El + proceso creerá que es capaz de escribir esos ficheros, pero + sólo el proceso ve los efectos; otros procesos del sistema + no ven absolutamente nada. + +

Se intenta crear este tipo de sandbox totalmente transparentes para + que el usuario (o intruso) no se de cuenta que está en él. + + + +

UNIX implementa dos tipos de sandboxes. Uno es a nivel de procesos, + y el otro es a nivel de usuarios (userid). + +

Cada proceso UNIX es totalmente independiente de cualquier otro proceso + UNIX. Un proceso no puede modificar el espacio de direcciones de otro. Es + diferente a los sistemas Windows en los que un proceso puede sobreescribir + facilmente el espacio de direcciones de otro proceso, probocando una caida + de la máquina. + +

Un proceso UNIX es propiedad de un userid determinado. Si el userid no + es el usuario root, éste solo podrá acceder a los procesos + de su propiedad, evitando la intrusión en procesos ajenos. El + userid también se usa como sistema de protección para datos + grabados en disco. + diff --git a/es_ES.ISO_8859-1/FAQ/admin.sgml b/es_ES.ISO_8859-1/FAQ/admin.sgml index 6e1cf8d8e4..1fcc2bd0a4 100644 --- a/es_ES.ISO_8859-1/FAQ/admin.sgml +++ b/es_ES.ISO_8859-1/FAQ/admin.sgml @@ -1,4 +1,4 @@ - + Administración de sistema @@ -1085,5 +1085,79 @@ cd /cdrom/bin # exit + + ¿Qué es un sandbox? + +

Sandbox es un término de seguridad. Puede significar dos + cosas: + + + +

Un proceso que es situado en el interior de una serie de muros + virtuales diseñados como prevención e imposibilitar + el acceso al sistema principal en caso de que alguien comprometa + la seguridad de ese proceso. + +

Se dice que el proceso es capaz de "jugar" entre los muros. + Esto significa que se supone que nada de lo que haga el proceso + referente a la ejecución de código, puede ser capaz + de romper los muros, así no es necesario hacer + auditorías detalladas de su código para poder conocer + todo lo referente a los riesgos de seguridad del proceso. + +

Los muros pueden, por ejemplo, un userid. Esta es la + definición usada en las páginas man de seguridad y del + programa named. + +

Veamos como ejemplo el servicio 'ntalk' (consultar /etc/inetd.conf). + Este servicio solía ejecutarse con el userid de root. Ahora se + ejecuta con el userid tty. El usuario tty esta diseñado para ser + usado como usuario sandbox, dificultando así la tarea de un + intruso que haya conseguido penetrar en el sistema a través del + servicio ntalk. De esta manera, el intruso solo puede afectar a los + servicios, programas o procesos propiedad del usuario tty. + + + +

Un proceso que se ha situado en el interior de una simulación + de la máquina. Esto es más hard-core. Básicamente, + significa que alguien que sea capaz de penetrar en el proceso, + creerá que ha penetrado en el sistema principal, pero de hecho, + ha penetrado en una simulación de esa máquina y no puede + modificar ningún dato real. + +

El sistema más común de conseguir esto es crear un + entorno simulado en un subdirectorio y ejecutar los procesos en ese + subdirectorio mediante chroot (la raiz "/" para ese proceso es este + directorio, no la raiz "/" real del sistema). + +

Otro sistema habitual es montar un sistema de ficheros de solo + lectura y a continuació,n crear un nivel de sistema de ficheros + por encima del anterior que dé al proceso la sensación + de encontrarse en un sistema de ficheros de lectura/escritura. El + proceso creerá que es capaz de escribir esos ficheros, pero + sólo el proceso ve los efectos; otros procesos del sistema + no ven absolutamente nada. + +

Se intenta crear este tipo de sandbox totalmente transparentes para + que el usuario (o intruso) no se de cuenta que está en él. + + + +

UNIX implementa dos tipos de sandboxes. Uno es a nivel de procesos, + y el otro es a nivel de usuarios (userid). + +

Cada proceso UNIX es totalmente independiente de cualquier otro proceso + UNIX. Un proceso no puede modificar el espacio de direcciones de otro. Es + diferente a los sistemas Windows en los que un proceso puede sobreescribir + facilmente el espacio de direcciones de otro proceso, probocando una caida + de la máquina. + +

Un proceso UNIX es propiedad de un userid determinado. Si el userid no + es el usuario root, éste solo podrá acceder a los procesos + de su propiedad, evitando la intrusión en procesos ajenos. El + userid también se usa como sistema de protección para datos + grabados en disco. +