Add "What's a sandbox" entry
This commit is contained in:
Jesus Rodriguez Cuesta
parent
01ef19c47f
commit
89bd27d45f
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=5340
3 changed files with 225 additions and 3 deletions
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: admin.sgml,v 1.11 1999-08-03 17:43:34 jesusr Exp $ -->
|
||||
<!-- $Id: admin.sgml,v 1.12 1999-08-09 13:45:55 jesusr Exp $ -->
|
||||
<!-- The FreeBSD Documentation Spanish Project -->
|
||||
<sect>
|
||||
<heading>Administración de sistema<label id="admin"></heading>
|
||||
|
|
@ -1085,5 +1085,79 @@ cd /cdrom/bin
|
|||
# exit
|
||||
</verb>
|
||||
|
||||
<sect1>
|
||||
<heading>¿Qué es un sandbox?</heading>
|
||||
|
||||
<p>Sandbox es un término de seguridad. Puede significar dos
|
||||
cosas:
|
||||
|
||||
<itemize>
|
||||
<item>
|
||||
<p>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.
|
||||
|
||||
<p>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.
|
||||
|
||||
<p>Los muros pueden, por ejemplo, un userid. Esta es la
|
||||
definición usada en las páginas man de seguridad y del
|
||||
programa named.
|
||||
|
||||
<p>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.
|
||||
</item>
|
||||
|
||||
<item>
|
||||
<p>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.
|
||||
|
||||
<p>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).
|
||||
|
||||
<p>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.
|
||||
|
||||
<p>Se intenta crear este tipo de sandbox totalmente transparentes para
|
||||
que el usuario (o intruso) no se de cuenta que está en él.
|
||||
</item>
|
||||
</itemize>
|
||||
|
||||
<p>UNIX implementa dos tipos de sandboxes. Uno es a nivel de procesos,
|
||||
y el otro es a nivel de usuarios (userid).
|
||||
|
||||
<P>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.
|
||||
|
||||
<p>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.
|
||||
|
||||
</sect>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: admin.sgml,v 1.11 1999-08-03 17:43:34 jesusr Exp $ -->
|
||||
<!-- $Id: admin.sgml,v 1.12 1999-08-09 13:45:55 jesusr Exp $ -->
|
||||
<!-- The FreeBSD Documentation Spanish Project -->
|
||||
<sect>
|
||||
<heading>Administración de sistema<label id="admin"></heading>
|
||||
|
|
@ -1085,5 +1085,79 @@ cd /cdrom/bin
|
|||
# exit
|
||||
</verb>
|
||||
|
||||
<sect1>
|
||||
<heading>¿Qué es un sandbox?</heading>
|
||||
|
||||
<p>Sandbox es un término de seguridad. Puede significar dos
|
||||
cosas:
|
||||
|
||||
<itemize>
|
||||
<item>
|
||||
<p>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.
|
||||
|
||||
<p>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.
|
||||
|
||||
<p>Los muros pueden, por ejemplo, un userid. Esta es la
|
||||
definición usada en las páginas man de seguridad y del
|
||||
programa named.
|
||||
|
||||
<p>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.
|
||||
</item>
|
||||
|
||||
<item>
|
||||
<p>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.
|
||||
|
||||
<p>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).
|
||||
|
||||
<p>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.
|
||||
|
||||
<p>Se intenta crear este tipo de sandbox totalmente transparentes para
|
||||
que el usuario (o intruso) no se de cuenta que está en él.
|
||||
</item>
|
||||
</itemize>
|
||||
|
||||
<p>UNIX implementa dos tipos de sandboxes. Uno es a nivel de procesos,
|
||||
y el otro es a nivel de usuarios (userid).
|
||||
|
||||
<P>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.
|
||||
|
||||
<p>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.
|
||||
|
||||
</sect>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: admin.sgml,v 1.11 1999-08-03 17:43:34 jesusr Exp $ -->
|
||||
<!-- $Id: admin.sgml,v 1.12 1999-08-09 13:45:55 jesusr Exp $ -->
|
||||
<!-- The FreeBSD Documentation Spanish Project -->
|
||||
<sect>
|
||||
<heading>Administración de sistema<label id="admin"></heading>
|
||||
|
|
@ -1085,5 +1085,79 @@ cd /cdrom/bin
|
|||
# exit
|
||||
</verb>
|
||||
|
||||
<sect1>
|
||||
<heading>¿Qué es un sandbox?</heading>
|
||||
|
||||
<p>Sandbox es un término de seguridad. Puede significar dos
|
||||
cosas:
|
||||
|
||||
<itemize>
|
||||
<item>
|
||||
<p>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.
|
||||
|
||||
<p>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.
|
||||
|
||||
<p>Los muros pueden, por ejemplo, un userid. Esta es la
|
||||
definición usada en las páginas man de seguridad y del
|
||||
programa named.
|
||||
|
||||
<p>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.
|
||||
</item>
|
||||
|
||||
<item>
|
||||
<p>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.
|
||||
|
||||
<p>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).
|
||||
|
||||
<p>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.
|
||||
|
||||
<p>Se intenta crear este tipo de sandbox totalmente transparentes para
|
||||
que el usuario (o intruso) no se de cuenta que está en él.
|
||||
</item>
|
||||
</itemize>
|
||||
|
||||
<p>UNIX implementa dos tipos de sandboxes. Uno es a nivel de procesos,
|
||||
y el otro es a nivel de usuarios (userid).
|
||||
|
||||
<P>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.
|
||||
|
||||
<p>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.
|
||||
|
||||
</sect>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue