dacscheck - Online en la nube

PROGRAMA:

NOMBRE

dacscheck - verificación de autorización

SINOPSIS

dacscheck [-administración] [-app nombre de la aplicación] [-contexto presentar] [-DNombre = valor]
[-F campo_sep] [-fd dominio] [-fh hostname] [-fj apellido] [-fn nombre federal]
[-tugurio] [-grupos grupo_vfs] [-h] [-i ident] [-Illinois ident]
[-ilg ident] [-ieuida] [-ieuidg] [-iuido] [-iuidg] [-lg] [-ll nivel de registro]
[-nombre_comparar Método] [-q]
[-redirecto] [-roles roles_vfs] [-normas regla_vfs] [-v] [-var Nombre = valor]
[-vfs vfs_uri] [--] objeto

DESCRIPCIÓN

Este programa es parte del DACS suite. Es un programa independiente que ninguno acepta
lo normal DACS opciones de línea de comando (dacsopciones) ni accede a ninguna DACS configuración
archivos.

En pocas palabras, dacscheck analiza las reglas de control de acceso para probar si un usuario determinado está autorizado
hacer algo o acceder a algo. El estado de salida del comando da el resultado de la
prueba, y a menos que el -q se da una bandera, se imprime una línea en stdout que indica el
resultado. Proporciona acceso simplificado de uso general a DACSregla de control de acceso
motor de evaluación, incluso para programas distintos de los servicios web, y se presta a
decisiones de control de acceso detalladas.

Más específicamente, dacscheck comprueba si una solicitud de objeto debe concederse de acuerdo con
reglas de control de acceso especificadas y un contexto de evaluación dado. Para hacer su trabajo dacscheck
necesita saber solo algunas cosas:

1. dónde encontrar las reglas de control de acceso para aplicar;

2. el nombre del objeto al que se accede; y

3. opcionalmente, un contexto de evaluación que especifica una identidad para la cual se está accediendo
probadas y variables a las que pueden hacer referencia las reglas.

El comando no realiza ninguna autenticación; asume que la persona que llama (o el
entorno de ejecución) ya ha establecido la identidad para la cual un control de acceso
se requiere decisión. Puede usarse como cualquier otro comando: ejecutar desde la línea de comando o
un script de shell, ejecutado por un programa compilado, o llamado desde un lenguaje de script como
as Perl[1], PHP[2]. Python[3], Rubí[4], y Tcl / Tk[5].

Algunos ejemplos simples ilustrarán cómo dacscheck puede ser usado.

Nota
Los ejemplos de este documento se han simplificado para facilitar la lectura; en uso real,
deben aparecer nombres de ruta absolutos, debe realizarse una comprobación de errores, etc. También,
los dacscheck programa y las reglas que requiere deben tener permisos de archivo establecidos
apropiadamente.

El primer ejemplo muestra cómo un script de shell podría llamar dacscheck para probar si el usuario
ejecutarlo está permitido. Obtiene la identidad del usuario del sistema operativo;
asume que el usuario ha invocado el script desde la línea de comando y, por lo tanto, ha
ya iniciado sesión en el sistema. En el ejemplo, dacscheck obtiene la identidad a través de un
llamada al sistema, pero una secuencia de comandos puede optar por pasar el valor de la NOMBRE DE REGISTRO or USUARIO
Variable ambiental.

El script de shell simplemente pregunta dacscheck si el fluido efectivo (ver geteuid(2)[6]) es
permitido acceder a / myapp. El estado de salida de dacscheck ($?) da el resultado. los
pathname / myapp es esencialmente una etiqueta que se usa para encontrar la regla de control de acceso para
solicitar; en este ejemplo, simplemente representa el nombre del programa. Podría ser el
nombre de archivo del programa, pero no es necesario.

#! / Bin / sh

dacscheck -q -ieuid -rules / usr / local / myapp / rules / myapp
st = "$?"
si prueba "$ {st}"! = 0
después
echo "Acceso denegado"
salir de "$ {st}"
fi

echo "Acceso concedido"

# Haz algunas cosas

salir de 0

El directorio / usr / local / myapp / rules puede incluir un archivo llamado acl-app.0 que otorga
acceso solo a bob y alice:








usuario (": bob") o usuario (": alice")




Nota
Las reglas de control de acceso se describen en dacs.acls(5)[7]. Al igual que con dacs_acs(8)[8], estos
las reglas deben estar indexadas por dacsacl(1)[9]. Por ejemplo, en un caso de uso común donde un DACS
archivo de configuración no se está utilizando, el conjunto de reglas consultado por dacscheck puede ser
indexado usando un comando como:

% dacsacl -un -vfs "[acls] file: /// users / bobo / my-rules" -vfs "[dacsacls]: file: /// dev / null"

If dacsacl tiene éxito en el ejemplo anterior, se creará un archivo llamado ÍNDICE o
actualizado en el directorio / users / bobo / my-rules, donde los archivos que contienen las reglas
también se encuentran. Los mensajes de advertencia generalmente se pueden ignorar siempre que INDEX parezca correcto.

Un programa CGI puede obtener la identidad del usuario que lo invoca desde el REMOTE_USER
variable de entorno y llamada dacscheck, como se demuestra en el siguiente script de shell,
que usa la misma regla que la anterior:

#! / Bin / sh

si prueba "$ {REMOTE_USER} x" = "x"
después
idarg = ""
más
idarg = "- i $ {REMOTE_USER}"
fi

echo "Tipo de contexto: texto / sin formato"
eco ""

# Nota: agregue 2> & 1 al final de la siguiente línea para capturar los mensajes de error
dacscheck -q $ {idarg} -rules / usr / local / myapp / rules / myapp

st = "$?"
si prueba "$ {st}" = 0
después
echo "Acceso concedido"
más
echo "Acceso denegado"
fi

salir de 0

Este ejemplo se puede traducir fácilmente a cualquier lenguaje de secuencias de comandos que permita un
programa que se va a llamar y su estado de salida examinado. Aquí hay un ejemplo similar en PHP:

$ usuario = $ _SERVER ["REMOTE_USER"];
putenv ("REMOTE_USER = $ usuario");
system ("/ usr / local / dacs / bin / dacscheck -q -fn DEMO -icgi
-rules / usr / local / myapp / rules / myapp ", $ st);
if ($ st! = 0) {
// Acceso denegado, rescate
salir ($ st);
}

// Se concede acceso, proceda

Nota
Algunos pueden cuestionar el punto de tener una llamada de programa dacscheck para probar si el usuario
invocarlo se permite simplemente ejecutar el programa. A primera vista, podría parecer que
uno podría lograr el mismo resultado simplemente estableciendo permisos de archivo de modo que solo
Bob y Alice pueden ejecutar el programa. Si eso pudiera hacerse, la prueba de grano grueso
realizado por dacscheck en los ejemplos sería innecesario. Resulta que hay
más que eso.

Establecer permisos de archivo para lograr esto en un sistema tradicional de tipo Unix requiere
creando un nuevo grupo en / etc / group, algo que generalmente solo puede hacer un
administrador de sistema. Por lo tanto, los usuarios comunes deben molestar al sistema
administrador cada vez que un grupo de este tipo deba crearse o modificarse, o encontrar algún otro
manera de lograr el mismo resultado (por ejemplo, mediante encriptación, usando un setuid especial o setgid
comando que proporciona acceso protegido con contraseña, o algún otro torpe y posiblemente
solución insegura).

Para abordar esta limitación y otras, muchos sistemas operativos de tipo Unix ahora incluyen
sistemas de archivos que amplían los permisos de archivos tradicionales de Unix con un sistema de archivos ACL
mecanismo (por ejemplo, proporcionar el obtenerfacl(1)[10] y setfacl(1)[11] comandos, y el
acl(3)[12] API de seguridad ACL).

dacscheck proporciona una funcionalidad similar pero para arbitrario nombres, no solo para objetos
en el sistema de archivos, y con respecto a arbitrario identidades, no solo para los conocidos
al sistema operativo. Por ejemplo, un script CGI puede llamar dacscheck para probar el acceso
en nombre de un usuario conocido por el servidor web (por ejemplo, a través de una cuenta creada usando
htpasswd(1)[13]) pero no tener una cuenta en el sistema subyacente. Por lo tanto,
además de ser portátil a través de plataformas y disponible en sistemas sin archivo de tipo ACL
permisos, dacscheck es una solución mucho más general de lo que la mayoría de las operaciones
proporcionan los sistemas. Sin embargo, a diferencia de un mecanismo basado en ACL proporcionado por el sistema,
dacscheck is no invocado de forma transparente (es decir, no es llamado automáticamente por el
sistema operativo cuando se accede a un recurso como un archivo). Además, con respecto a
probando si un usuario puede ejecutar un programa, ese programa normalmente
realizar la prueba en sí y, por lo tanto, debe comenzar la ejecución.

Para información adicional:

· Gracias a FreeBSD's ACL[14], Dru Lavigne, ONLamp.com[15], 22 de septiembre de 05.

· POSIX ACL in Linux[16], Mike Peters, linux.com[17], 2 de agosto de 04.

· Para Solaris, Solaris 10 acl(2)[18], Dom Microsistemas[19] y Gracias a Solaris
ACL[20] por el Depto. of Módulo Ciencia, Duque Universidad[21].

Porque la verificación de autorización realizada por dacscheck está completamente separado de eso
realizado por el sistema operativo para las llamadas al sistema, un Unix identidad como root no tiene
derechos o capacidades especiales en la medida en que dacscheck está preocupado a menos que las reglas hayan sido
escrito para concederlos. Lo mismo se aplica a la aplicación de Unix grupos.

El siguiente ejemplo demuestra cómo algunos Perl el código se puede mejorar dacscheck.
fragmento de código:

if ($ log_in_as_root || $ log_in_as_current_admin) {
# Haz algo privilegiado ...
}

que depende de que las dos variables se inicialicen correctamente en función del valor de
$ nombre de usuario, puede ser reemplazado por esto:

# Determine si $ username tiene privilegios de administrador
$ salida = `dacscheck -q -i $ nombre de usuario -app myapp / myapp / admin`;
$ is_admin = ($? >> 8) == 0;

if ($ is_admin) {
# Haz algo privilegiado ...
}

# Más tarde...
if ($ is_admin) {
# Hacer algo más privilegiado ...
}

La nueva prueba de autorización depende de la identidad que ejecuta el programa ($ nombre de usuario)
y el conjunto de reglas separado que determina si a esa identidad se le debe otorgar acceso a
/ myapp / admin, que es simplemente una etiqueta para una regla que podría verse así:








usuario ("%: admin")




Esta regla otorga acceso si y solo si $ nombre de usuario es un miembro de la DACS grupo llamado administrador
o está asociado con eso DACS papel. La pertenencia a ese grupo se puede cambiar de forma dinámica,
e incluso se puede reducir a cero.

La observación importante es que los condiciones que determinar sean los usuario correr
este vídeo Perl código tiene administrativo privilegios están se define outside of los programa y can be
cambiado sin modificador los código y often sin even modificador de la máquina control reglas.

Algunos conceptos que se utilizan en este documento se describen en otra parte. Variables, variable
los espacios de nombres y las expresiones que se utilizan en las reglas de control de acceso se tratan en
dacs.exprs(5)[22]. Nombrando en DACS se discute en dacs(1)[23], y DACS grupos y roles
están cubiertos en dacs.grupos(5)[24].

Seguridad
Claramente dacscheck, su interlocutor, y los recursos en cuestión deben estar "aislados" de
el usuario en cuyo nombre dacscheck se está ejecutando, de lo contrario, el usuario podría acceder al
recursos directamente o subvertir las pruebas de control de acceso. Por lo tanto, dacscheck y su
La persona que llama debe tener más privilegios que el usuario en cuyo nombre se está ejecutando o
ambos programas deben ejecutarse en un contexto seguro. Esto generalmente significa que tanto dacscheck
y su llamador debe ejecutarse de forma aislada de los usuarios (como en un servidor remoto) o como un
ID de usuario efectivo diferente al del usuario.

Ventajas
Los programas que realizan pruebas de autorización suelen contener código como:

· "Si el usuario actual ha proporcionado una contraseña adecuada, ejecute lo siguiente
código, de lo contrario no ", o

· "Si el usuario actual es el administrador, haga lo siguiente", o

· "Si el usuario actual puede realizar una operación de actualización, muestre este menú
elementos, de lo contrario no los muestre "

Las aplicaciones complicadas pueden llenarse de este tipo de pruebas, lo que las hace propensas a
errores y problemas de seguridad. Los cambios en las políticas de seguridad pueden implicar modificaciones
en una aplicación o conjunto de aplicaciones. Además, el manejo de contraseñas es a menudo
incorporado en tales programas; porque la gestión de contraseñas puede requerir una
esfuerzo de implementación y es difícil de hacer de forma segura, parece prudente intentar aprovechar
implementaciones existentes.

En comparación con las soluciones codificadas a medida, dacscheck tiene muchas ventajas:

Políticas basadas en datos
A diferencia de la lógica de control de acceso especialmente escrita, basada en datos (basada en reglas)
la funcionalidad es superior porque:

· Las reglas de control de acceso están separadas del código, por lo que los cambios en un conjunto de reglas
se aplica automáticamente a todos los usos de esas reglas en una aplicación o conjunto
de aplicaciones; no es necesario modificar el código si se cambia la política.

· Las correcciones de errores y las mejoras a las reglas están disponibles automáticamente para los programas que
use dacscheck; no es necesaria la recopilación de aplicaciones.

· La persona que administra las reglas no tiene que ser la aplicación
programador (o incluso alguien que entienda el código), por lo que delegar
la responsabilidad es mucho más fácil. Esto reduce la cantidad de programación requerida
cuando se requieren cambios, reduce el esfuerzo de mantenimiento del código y disminuye la
posibilidad de error.

· Suele ser más fácil comprender (y expresar) un conjunto de reglas que describen una
política de control de acceso; el código que implementa la misma política será más complejo
y difícil de entender, aumentando la posibilidad de error.

Eficiencia de programación

· Las aplicaciones se simplifican y el tiempo y el esfuerzo de programación se reducen porque
código de control de acceso existente (es decir, dacscheck) se reutiliza.

· Se pueden construir reglas sofisticadas sin tener que escribir ningún código. DACS
Las características están disponibles, como roles y grupos, y se pueden usar para construir
Políticas de autorización más simples y expresivas de las que probablemente sean
codificado a mano.

Portabilidad
Las reglas son independientes de la plataforma, se pueden almacenar de forma remota desde las aplicaciones que utilizan
ellos, y potencialmente pueden ser evaluados de forma remota. dacscheck está disponible para una variedad
de plataformas.

Mayor intercambio
Las reglas se pueden compartir y usar en diferentes situaciones y por diferentes programas.

Flexibilidad

· Dado que no depende de un servidor web, puede ser utilizado por prácticamente cualquier
Programa basado en CGI.

· Con respecto a DACS, se puede utilizar en circunstancias en las que mod_auth_dacs[ 25 ]
el módulo no se puede utilizar con APACHE, o donde APACHE no se puede utilizar en absoluto.

· Debido a que se implementa como un comando ordinario, dacscheck se puede utilizar desde el
línea de comandos o invocado desde casi cualquier script o programa.

· Para programas basados ​​en CGI, dacscheck se puede utilizar sin la ayuda de un sistema
administrador; por ejemplo, no requiere que se configure un servidor web para proporcionar
autorización para un programa CGI porque toda la funcionalidad de control de acceso es
realizado dentro del programa.

Seguridad incrementada
dacscheck no realiza autenticación ni se basa en ninguna autenticación en particular
método, por lo que el método de autenticación se puede cambiar sin afectar el
uso de la aplicación de dacscheck. Se puede utilizar cualquier medio de autenticación compatible, no
solo el método típico basado en contraseña.

Mientras que la actuación de dacscheck no debería ser un factor para muchas aplicaciones, la
La API de C / C ++ se puede utilizar cuando sea un problema. Esta API se puede utilizar para incorporar dacscheck
funcionalidad en programas compilados y lenguajes extensibles, como Perl, Python,
Tcl / Tky PHP.

Identidades
La identidad para la que se va a probar el acceso se da al programa o se obtiene por el
programa desde su entorno de ejecución. Esta identidad se convierte en DACS interno
representación.

Se puede especificar más de una identidad; el cheque se hace en nombre del sindicato de todos
las identidades. Si se especifican las identidades Bob y Alice, por ejemplo, una regla que
está satisfecho con cualquiera de las identidades puede otorgar acceso.

Si no se proporciona identidad, la verificación se realiza en nombre de un usuario no autenticado.

Una identidad puede ser:

· Un nombre de inicio de sesión que dacscheck mapas desde el uid real o efectivo del programa
(es decir, el usuario que está ejecutando el programa);

· un DACS identidad de usuario (p. ej.,: carol, DSS: bob o EXAMPLE-COM :: DEMO: alice, consulte
dacs(1)[26]);

· Un nombre simple (bob es equivalente a: bob); o

· Un nombre expresado en el conciso sintaxis[27], que proporciona un nombre de usuario y, opcionalmente,
roles y atributos para la identidad. No se utiliza ninguna identidad que haya expirado.

Notas
· dacscheck valida la sintaxis de una identidad que se le da, la convierte y la expande
a la sintaxis concisa si es necesario, y luego la convierte en su
representación de credenciales. Estas credenciales se destruyen cuando el programa
termina.

Independientemente de cómo se especifique, cada identidad debe satisfacer las características sintácticas
requisitos de un DACS identidad del usuario después de esta conversión y expansión (ver
dacs(1)[26]). Si se especifica un nombre de inicio de sesión como identidad, por ejemplo, debe
válido como componente de un DACS identidad de usuario; por lo tanto, no puede contener ninguna
Caracteres inválidos.

· Si no se proporciona una dirección IP para una identidad, se obtiene del REMOTE_ADDR
variable de entorno cuando esté disponible; de ​​lo contrario, se utiliza un valor predeterminado de 127.0.0.1. los
La dirección IP asociada con las credenciales se prueba utilizando el usuario() predicado.

· Si una identidad que se está probando incluye un nombre de federación, ya que el valor predeterminado
Es poco probable que el nombre de la federación sea correcto, probablemente será necesario decirlo
dacscheck qué nombre de federación comparar con el uso del -fn bandera.

A continuación se muestran algunos ejemplos de identidades que pueden seguir la -i bandera:

grano
:Beto
DSS: bob
{u = bob}
{u = "bob"}
{u = "alice", g = "admin"}
{u = "DSS: bob", g = "invitado"}
{u = "bob", a = "a", g = "guest"}

Nota
Es posible que esta cadena deba citarse adecuadamente en la línea de comando porque la llave
los personajes son importantes para algunas conchas; p.ej,

-i '{u = "bob"}'

APACHE y otros servidores web establecen la variable de entorno REMOTE_USER a los autenticados
identidad que invocaba un servicio web. Siempre que su sintaxis sea adecuada, esta identidad puede ser
pasó a dacscheck. For DACS-servicios web envueltos, DACS las identidades están disponibles en este
variable.

De forma predeterminada, la federación, la jurisdicción y los nombres de host asociados con las reglas son
derivado del nombre de host del sistema como lo devuelve obtener nombre de host(3)[28]. Si ese nombre es
inadecuado porque no es un FQDN (es decir, no es un nombre de dominio completamente calificado porque
no contiene un punto), cada uno de los nombres de alias se examina (usando
gethostbyname(3)[29]) hasta que se encuentre un FQDN. El nombre de la jurisdicción proviene del
El componente más a la izquierda del FQDN seleccionado y el dominio y el nombre de la federación provienen del
componentes restantes. Si no se encuentra ningún FQDN, el nombre de host del sistema se seleccionará como el
El nombre de la jurisdicción y los valores predeterminados se utilizarán como el dominio y el nombre de la federación (EXAMPLE.COM
y EJEMPLO-COM, respectivamente).

Si se encuentra que el nombre de host del sistema es (o se da explícitamente como) demo.example.com, por
Por ejemplo, las siguientes variables se establecerán como se indica durante la evaluación de la regla:

· $ {Conf :: FEDERATION_NAME} y $ {DACS :: FEDERATION} ambos se establecen en EXAMPLE-COM (los puntos son
mapeado a guiones para formar un nombre válido)

· $ {Conf :: FEDERATION_DOMAIN} está configurado en EXAMPLE.COM

· $ {Conf :: JURISDICTION_NAME} y $ {DACS :: JURISDICCIÓN} se establecen en el nombre de la jurisdicción,
DEMO

· $ {DACS :: HTTP_HOST} está configurado en demo.example.com:80

A menudo, las reglas e identidades se pueden expresar de manera que los nombres elegidos para la federación
y la jurisdicción no son importantes. Sin embargo, cuando este no es el caso, y los valores predeterminados
elegido por dacscheck son incorrectos, se pueden configurar en la línea de comando. En algunos
circunstancias, podría ser apropiado que el nombre de la jurisdicción sea el nombre del
aplicación, por ejemplo.

Independientemente de sus orígenes, los nombres de las federaciones y jurisdicciones siempre deben
sintácticamente válido (ver dacs(1)[26]).

Objetos
Si bien un objeto suele ser algo real, como un archivo, menú o variable, puede
también puede ser una abstracción, como una operación. dacscheck trabaja con nombres - en forma de
URI, en lugar de objetos per se. It sí no asociar any particular sentido con
nombres, it simplemente usos them a localizar an aplicable de la máquina control gobernar. Por lo tanto, el
siempre que el redactor de reglas y las aplicaciones que consultan las reglas acuerden la denominación
esquema, los nombres que se eligen son en gran medida irrelevantes.

Una aplicación asigna nombres a cada objeto o clase de objetos que necesitan ser
referenciado por las reglas de control de acceso. En su forma más simple, solo se requiere un nombre (el nombre
de la aplicación, por ejemplo). En situaciones más complejas, una amplia variedad de objetos
necesita ser nombrado. La elección de los nombres y los detalles de la jerarquía de nombres dependen de
la aplicación en particular, al igual que la organización del tiempo de ejecución de un paquete de software
La organización de archivos y directorios depende del paquete en particular.

El objeto argumento es el nombre que se compara con los servicios especificados en el acceso
reglas de control. Puede ser un URI o un nombre de ruta absoluto (uno que comienza con un
barra diagonal), y cualquiera de los dos puede tener adjunto un componente de cadena de consulta opcional. Un
nombre de ruta absoluto camino se asigna internamente a un URI como file: //camino; p. ej., / myapp es
interpretado como archivo: /// myapp (ver RFC 1738[30]).

Los diversos componentes del URI que nombra el objeto están disponibles como DACS las variables
y variables de entorno (ver más abajo). Si se proporciona una cadena de consulta, se analiza y el
Los argumentos individuales se ponen a disposición de las reglas a través del argumentos espacio de nombres, al igual que para
DACS-servicios web envueltos.

Nota
Solo el camino componente de la URI se considera cuando DACS coincide con el nombre de un objeto
contra el url_pattern de una regla de control de acceso. En la actualidad, el nombre del objeto no es
canonicalizado o resuelto automáticamente (ver RFC 3986[31]), como suele hacer un
servidor web, por lo que componentes de ruta relativa como "." y debe evitarse "..".

Regla Evaluación Contexto
Las reglas se evalúan dentro de un contexto de ejecución que puede afectar la evaluación de expresiones
implícitamente o pueden examinarse explícitamente a través de variables.

Since dacscheck no consulta el DACS archivos de configuración, el Conf. el espacio de nombres es
instanciado con pocas variables. En la actualidad, solo las directivas VFS están disponibles en él.

El argumentos se crea una instancia del espacio de nombres si un objeto El argumento tiene un componente de cadena de consulta.

El DACS el espacio de nombres se instancia con algunas variables estándar (como
$ {DACS :: JURISDICCIÓN}) pero también se pueden crear instancias de varias formas desde la línea de comando
y de archivos.

El Env el espacio de nombres se crea una instancia del entorno. Variable sintácticamente inválida
los nombres se ignoran en silencio.

Muchas variables normalmente establecidas por un servidor web son instanciadas por dacscheck basado en la
nombre del objeto. Estas variables están disponibles en el Env y DACS espacios de nombres. Por ejemplo, si
el nombre del objeto es https://example.com:8443/myapp/edit-menu?entry=item1, el siguiente
las variables se establecerán como se indica:

$ {Env :: HTTPS} = activado
$ {Env :: SERVER_NAME} = example.com
$ {Env :: SERVER_ADDR} = 142.179.101.118
$ {Env :: HTTP_HOST} = example.com: 8443
$ {Env :: SERVER_PORT} = 8443
$ {Env :: REQUEST_URI} = / myapp / edit-menu
$ {Env :: DOCUMENT_ROOT} = /
$ {Env :: REQUEST_METHOD} = OBTENER
$ {Env :: SERVER_SOFTWARE} = dacscheck-1.4.8b
$ {Env :: QUERY_STRING} = entrada = elemento1
$ {Env :: ARG_COUNT} = 1
$ {Env :: CURRENT_URI} = / myapp / edit-menu? Entry = item1
$ {Env :: CURRENT_URI_NO_QUERY} = / myapp / edit-menu

Las variables del mismo nombre también se establecerán en el DACS espacio de nombres y exportado como
Variables de entorno. El valor de $ {Args :: entrada} será item1. El método de solicitud
por defecto es GET. La variable $ {Env :: REMOTE_USER} (y por lo tanto $ {DACS :: REMOTE_USER} y
la variable de entorno REMOTE_USER) se establecerá en función de la primera identidad especificada en
la línea de comando; si no se ha especificado una identidad, esta variable no estará definida.

An Ejemplo Applicación
Para ilustrar cómo encajan las piezas, consideremos un hipotético (pero realista)
aplicación de calendario llamada caballo que esta escrito en Perl e invocado como un programa CGI. Bien
Permitir que un usuario que ha sido autenticado por el servidor web lea, cree o actualice solo
sus propios calendarios, a menos que el propietario de un calendario le dé permiso para realizar una lectura
o actualización de la operación en el calendario. Cada propietario puede especificar qué usuarios tienen acceso a ella.
propio calendario y el (los) tipo (s) de acceso permitido.

Esta política de autorización se puede especificar con bastante facilidad. Un enfoque es utilizar:

· Una regla principal que delega la responsabilidad de especificar una política de seguridad para cada
calendarios del usuario a ese usuario.

· Reglas por usuario y por calendario que indican qué usuarios pueden acceder a un calendario y en qué
camino o caminos.

El administrador del programa puede recopilar todos los archivos en tiempo de ejecución de la aplicación en
el directorio / usr / local / cal y sus subdirectorios, y organícelo de la siguiente manera:

/usr/local/cal/rules/{acl-rule.0,acl-rule.1, ...}
Reglas generales para la aplicación

/ usr / local / cal / users /nombre de usuario
Directorio raíz para calendarios propiedad de nombre de usuario

/ usr / local / cal / users /nombre de usuario/ cal-1 / data / *
Archivos de datos por calendario

/ usr / local / cal / users /nombre de usuario/rules/{acl-cal1.0,acl-cal2.0, ...}
Por calendario DACS archivos de control de acceso

/ usr / local / cal / users /nombre de usuario/ grupos / *
Por usuario DACS listas de grupos, una por archivo

Dadas estas convenciones de nomenclatura:

· Para probar si debe realizar una operación en particular, la aplicación llamaría
dacscheck, diciéndole que use las reglas que encuentra en / usr / local / cal / rules.

· Las reglas generales para la aplicación delegarían decisiones de control de acceso para
objetos con nombres que coinciden con / users /nombre de usuario/ * a las reglas de control de acceso que se encuentran en el
directorio / usr / local / cal / users /nombre de usuario/normas. Estas reglas describirían qué usuarios,
en su caso, se le permitiría realizar una determinada operación en el calendario.

· La aplicación usaría nombres de objeto de la forma / users /nombre de usuario/ cal-1? OP =Inteligente
como argumentos para dacscheck. El conjunto de reglas para cal-1 determinaría si un determinado
la identidad está autorizada para realizar lo solicitado Inteligente en el calendario. Por ejemplo,
Alice (la propietaria) podría tener acceso independientemente del valor de la OP argumento,
mientras que a Bob se le puede otorgar acceso solo si OP = read, y todos los demás pueden ser denegados
acceso. Más tarde, Alice podría definir un conjunto de usuarios a los que nombra familia y cambiar la
regla para permitir que cualquier miembro de ese grupo lea y actualice el acceso.

Las propias reglas de control de acceso de los usuarios podrían estar bajo control de acceso. Una línea de comando, GUI,
o la interfaz web daría al administrador y a los usuarios la capacidad de administrar reglas.

Consulte las EJEMPLOS[32] sección, por ejemplo, reglas.

Esta no es de ninguna manera la única forma de organizar los calendarios, y una delegación basada
enfoque no es necesario. En cambio, el administrador podría poner todas las reglas bajo un
directorio común, como / usr / local / cal / rules / acl-nombre de usuario.0 / {acl-cal1.0, acl-cal2.0, ...} o
acercarlos al calendario que controlan, como
/ usr / local / cal / users /nombre de usuario/cal-1/acl-cal1.0.

En lugar de probar si una operación está permitida, se pueden escribir reglas para devolver un
Cadena de restricción que le dice a la persona que llama qué tipo (o tipos) de acceso están permitidos. los
La línea de salida del programa incluirá la cadena de restricción entre comillas.

Comparando dacscheck con dacs_acs
dacs_acs(8)[8] es el DACS componente que es llamado por APACHE (por el DACS
mod_auth_dacs[25] módulo, en realidad) para realizar el procesamiento de control de acceso en el servicio web
peticiones. Su funcionamiento es normalmente invisible para los servicios web; dacs_acs hace todo su
funcionan antes de que se ejecute un servicio web o se devuelva una página web.

dacscheck realiza una función similar a la -check_only modo de funcionamiento de dacs_acs in
que simplemente devuelve una decisión de control de acceso. Existen importantes diferencias entre
los dos programas, sin embargo.

dacscheck:

· No es un programa CGI (aunque se puede llamar desde uno);

· no requiere mod_auth_dacs[25]

· No usa ninguna DACS Archivos de configuración;

· No interactúa directamente con un servidor web o cualquier otro DACS programas; y

· Se ejecuta en el nivel de privilegio del usuario que lo invoca en lugar del nivel de privilegio de
APACHE.

Aunque la dacscheck utiliza ordinario DACS reglas de control de accesodacs.acls(5)[7]), a diferencia de la mayoría
DACS comandos no consulta ningún DACS Archivos de configuración. El entorno de evaluación
para las reglas de control de acceso es similares al de las pruebas de servicios web, pero no es
idéntico ya que no es necesario que haya un servidor web en la imagen. Aparte de los atributos
relacionados con las restricciones, atributos como pass_credentials no tienen ningún significado para dacscheck.

Uso y configuración de DACS by dacscheck se simplifica enormemente porque no hay
se definen federación o jurisdicciones; un entorno completamente autónomo es
creado de modo que un solo programa o conjunto de programas relacionados pueda realizar ambos
pruebas de control de acceso detalladas y detalladas. Sin federación ni jurisdicción
se utilizan claves criptográficas, y no reales DACS se crean las credenciales. Federación y
Se crean instancias de nombres de jurisdicciones, pero aquellos que escriben reglas a menudo no necesitarán ser
consciente de ellos.

OPCIONES

Los argumentos se procesan a medida que se examinan (de izquierda a derecha) y su orden se puede
significativo; por ejemplo, los valores establecidos por el -fh La bandera puede afectar las opciones que
seguirlo, como los que utilizan la interpolación de cadenas. Exactamente uno objeto el argumento es
requerida.

-administración
Todas las identidades que siguen en la línea de comando son DACS identidades que satisfacen el
dacs_admin () función. Consulte la directiva de configuración ADMIN_IDENTITY en
dacs.conf(5)[33] y el atributo "a" para las identidades.

-app nombre de la aplicación
Especifique un nombre de aplicación que se utilizará para construir rutas predeterminadas (consulte la -normas y
-grupos banderas).

-contexto presentar
Definiciones de variables para DACS los espacios de nombres se leen, uno por línea, en el formato
nombre =propuesta de (con comillas opcionales alrededor del propuesta de). La nombre debe ser sintácticamente
válido. Si presentar is -, se lee la entrada estándar. Por ejemplo, si presentar contiene los dos
líneas:

FOO = uno
BAZ = dos

luego dentro de las reglas de control de acceso $ {DACS :: FOO} tendrá el valor "uno" y
$ {DACS :: BAZ} tendrá el valor "dos". Esta bandera puede repetirse, aunque la
La entrada estándar solo se puede leer una vez.

-DNombre = valor
Esto es equivalente a -var Nombre = valor.

-tugurio
Realice todas las inicializaciones, muestre el contexto de evaluación y luego salga.

-F campo_sep
Cuando se buscan roles, use el personaje campo_sep como el carácter separador de campo
en lugar del predeterminado. Para obtener más información, consulte la descripción de la directiva VFS en
dacs.conf(5)[34].

Nota
Tenga en cuenta que solo la primera aparición del carácter (de izquierda a derecha) es
tratado como el carácter separador.

-fd dominio
Usa dominio como nombre de dominio de la federación. Debe ser sintácticamente válido.

-fh hostname
Usa hostname, un nombre de dominio completamente calificado, como el nombre de host del sistema y para derivar
los nombres de la federación y jurisdicción. Debe ser sintácticamente válido.

-fj apellido
Usa apellido como nombre de la jurisdicción. Debe ser sintácticamente válido.

-fn nombre federal
Usa nombre federal como nombre de la federación. Debe ser sintácticamente válido.

-grupos grupo_vfs
De forma predeterminada, dacscheck espera encontrar DACS definiciones de grupo arraigadas en el directorio
dacscheck / groups relativos a DACS_HOME (por ejemplo, / usr / local / dacs / dacscheck / groups), o si
-app nombre de la aplicación se da, arraigado en el directorio dacscheck /nombre de la aplicación/ grupos relativos a
DACS_HOME (por ejemplo, / usr / local / dacs / dacscheck / myapp / groups) Esta bandera especifica un
diferente ubicación. Puede ser un nombre de ruta absoluto (que será una cadena interpolada
- ver dacs.conf(5)[35]) o un URI en la sintaxis del VFS[34] directiva de configuración.
Ejemplos:

-groups "[grupos] dacs-fs: / local / groups"
-grupos / inicio / bob / mygroups

De forma predeterminada, una referencia al grupo% FOO: las personas se asignarán a un archivo llamado
people.grp dentro del directorio FOO relativo al DACS directorio de grupo.

-h
Imprime la propaganda de uso.

-i ident
La identidad dada se agrega al conjunto de identidades en vigor durante la verificación. Esta
La identidad no necesariamente tiene una cuenta en el sistema. Si ident es el vacio
cadena, sin embargo, la bandera no tiene ningún efecto; este es un comportamiento conveniente cuando la bandera está
usado como -i $ {Env :: REMOTE_USER: - ""}, por ejemplo, donde REMOTE_USER puede no haber sido
conjunto.

-icgi
Si la variable de entorno REMOTE_USER se establece en un nombre simple válido o DACS
identidad, se agrega al conjunto de identidades en vigor durante la verificación. Si el
La variable no está configurada o no es válida, esta bandera no tiene ningún efecto.

-icgig
Como en el -icgi , excepto que se agregarán los roles asociados con el nombre de usuario.

-Illinois ident
La identidad dada es "local" y debe corresponder a una cuenta en el sistema; Si el
-grupos la bandera está en efecto, la membresía del grupo de la cuenta se agregará como roles para
ident.

-ilg ident
Como en el -ilg marca, excepto que la membresía del grupo de la cuenta se agregará como roles a
ident independientemente de si el -grupos la bandera está en efecto.

-ieuida
El uid efectivo del programa se suma al conjunto de identidades. Si el -grupos
la bandera está en efecto, la membresía del grupo de la cuenta se agregará como roles para ident.

-ieuidg
El uid efectivo del programa se agrega al conjunto de identidades. Las cuentas
la membresía de grupo se agregará como roles a ident independientemente de si el -grupos
la bandera está en efecto.

-iuido
El uid real del programa se agrega al conjunto de identidades. Si el -grupos bandera es
en efecto, la membresía del grupo de la cuenta se agregará como roles para ident.

-iuidg
El uid real del programa se agrega al conjunto de identidades. El grupo de la cuenta
la membresía se agregará como roles a ident independientemente de si el -grupos bandera es
en efecto.

-lg
Para cada identidad local que sigue en la línea de comando, use su grupo Unix
pertenencia a los roles de la identidad.

-ll nivel de registro
Establezca el nivel de salida de depuración en nivel de registro (consulta: dacs(1)[23]). El nivel predeterminado es
advertir, y el -v bandera sube el nivel para depurar o rastrear.

-nombre_comparar Método
Exactamente como el NOMBRE_COMPARAR[36] directiva, establece el método predeterminado utilizado para comparar
Nombres DACS en varios contextos para Método, que puede ser (sin distinción entre mayúsculas y minúsculas) mayúscula,
nocase, o por defecto.

-q
Cállate, a excepción de los mensajes de error; el resultado no se imprimirá en la salida estándar. los -v
y -ll las banderas son independientes de esto.

-redirecto
Si se deniega el acceso y la regla aplicable llama redireccionar ()[37] con el
BY_SIMPLE_REDIRECT, luego la URL especificada se imprime en stdout. Esta bandera
permite que el -q bandera.

-roles roles_vfs
Los roles para cada identidad que sigue en la línea de comando se buscarán usando
roles_vfs. Puede ser un nombre de ruta absoluto (que se interpolará en cadenas; consulte
dacs.conf(5)[35]) o un URI en la sintaxis del VFS[34] directiva de configuración. Si
se encuentran roles, se agregarán a cualquier otro rol especificado para el usuario
(ya sea que se enumere explícitamente o se obtenga de la membresía del grupo Unix). Por ejemplo, si
/ usr / local / myapp / roles contiene:

bobo: usuarios
auggie: administrador, usuarios
harley: invitado

luego la línea de comando:

% dacscheck -roles / usr / local / myapp / roles -i auggie / myapp / admin

probará el acceso para la identidad {u = "auggie", g = "admin, users"}.

-normas regla_vfs
De forma predeterminada, dacscheck espera usar un conjunto de reglas enraizado en el directorio dacscheck / acls
relativo a DACS_HOME (por ejemplo, / usr / local / dacs / dacscheck / acls), o si el indicador -app
nombre de la aplicación se da, arraigado en el directorio dacscheck /nombre de la aplicación/ acls relativo a DACS_HOME
(por ejemplo, / usr / local / dacs / dacscheck / myapp / acls). Esta bandera especifica un conjunto de reglas diferente
para ser utilizado. Puede ser un nombre de ruta absoluto (que se interpolará en cadenas; consulte
dacs.conf(5)[35]) o un URI en la sintaxis del VFS[34] directiva de configuración.
Ejemplos:

-reglas "[acls1] dacs-fs: / local / acls"
-reglas / usr / local / myrules

Esta bandera puede repetirse; Los conjuntos de reglas se examinarán en el orden en que se
especificado en la línea de comando.

-v
Aumente el nivel de salida de depuración. La bandera puede repetirse.

-var Nombre = valor
Como en el -contexto bandera, esto agrega una definición de variable a la DACS espacio de nombres. La
variable DACS :: nombre se le asignará la cadena propuesta de. nombre debe ser sintácticamente
válido. Esta bandera puede repetirse.

-vfs vfs_uri
Añadir el archivo vfs_uri como herramienta de edición del VFS[34] directiva de configuración. Esta bandera puede repetirse, con
sucesos posteriores que tienen una "prioridad" más alta que los anteriores (como si
apareció más tarde en dacs.conf; ver dacs.conf(5)[33]).

--
Esto marca el final de los argumentos de la bandera.

EJEMPLOS

Para ilustrar como dacscheck podría usarse con aplicaciones reales, aquí hay algunos ejemplos.
Los primeros continúan con la aplicación de calendario hipotético descrita anteriormente.

1. El archivo /usr/local/cal/rules/acl-rule.0 podría verse así:



<delegate url_pattern="/usuarios/alice/*"
rule_uri = "/ usr / local / cal / users / alice / rules />
<delegate url_pattern="/usuarios/bob/*"
rule_uri = "/ usr / local / cal / users / bob / rules />





usuario ("auth")




Esta regla redirige las solicitudes del calendario de un usuario en particular al acceso de ese usuario.
reglas de control. También dice que el acceso a los binarios de la aplicación está restringido a
usuarios autenticados. La aplicación puede emitir un comando como:

% dacscheck -i $ REMOTE_USER -rules / usr / local / cal / rules objeto

que devolverá un estado de salida de 0 si REMOTE_USER se le concede acceso a objeto;
de lo contrario, se devolverá un estado de salida de 1. Una mejor opción es usar el comando:

% dacscheck -icgi -rules / usr / local / cal / rules objeto

que dejará al usuario sin autenticar si REMOTE_USER no está configurado o no es válido.

2. El archivo /usr/local/cal/users/alice/rules/acl-cal1.0 contiene la regla para el usuario
el "Calendario 1" de Alice y podría verse así:








usuario (": alice")


volvemos(1)





$ {Args :: OP} eq "leer"


usuario (": bob")





Esta regla dice que a Alice se le permite acceso completo al calendario (no hay
restricción en la operación), pero Bob solo tiene acceso de lectura. dacscheck sería
llamado con / users / alice / cal-1? OP = create, / users / alice / cal-1? OP = update, o
/ users / alice / cal-1? OP = leer para probar la autorización para realizar una creación, actualización o
leer operación en el calendario, respectivamente.

3. Si Alice define un DACS grupo que ella llama familia y agrega los nombres de Julia y
auggie a ese grupo, podría modificar la regla anterior agregando lo siguiente:



$ {Args :: OP} eq "leer"
o $ {Args :: OP} eq "actualizar"


usuario ("%: alice-family")



Esta regla dice que cualquier miembro del grupo alice-family puede leer y actualizar
acceso a este calendario. El comando:

% dacscheck -i julia / users / alice / cal-1? OP = actualizar

informaría que se concede el acceso.

4. La membresía del grupo de alice llamado alice-family puede especificarse en el archivo
/ usr / local / cal / users / alice / groups / family








usuario (": alice")


volvemos(1)




Esta regla permite que solo Alice administre la membresía de este grupo, pero es libre
modificar la regla para permitir que otros administren sus grupos.

5. Como ejemplo final de esta aplicación, las reglas de Alice también pueden estar en acceso
Control:








usuario (": alice")


volvemos(1)




Esta regla permite que solo Alice administre la membresía de este grupo, pero es libre
modificar la regla para permitir que otros administren sus grupos.

6. Un popular programa analizador de registros web de código abierto, escrito en Perl, se puede invocar como
Programa CGI. El programa incluye disposiciones de seguridad mediante las cuales puede restringir el acceso
a cualquier usuario autenticado por el servidor web, por nombre de usuario (usando REMOTE_USER, ya que
exportado por el servidor web), o basado en la dirección IP del usuario (utilizando REMOTE_ADDR).
Las aproximadamente 40 líneas de código (más una variedad de inicializaciones) que implementa
esta política de seguridad se puede reemplazar esencialmente por unas pocas líneas de código:

my $ valor_salida = 0;
sistema "/ usr / local / dacs / bin / dacscheck", "-q", "-icgi", "-rules",
"/ usr / local / webstats / acls", "/ webstats";
$ valor_salida = $? >> 8;
# print "dacscheck devolvió $ valor_salida para el usuario \" $ usuario_remoto \ "\ n";
if ($ valor_salida! = 0) {
# dacscheck deniega el acceso; imprimir mensaje y salir
salida 1;
}

# dacscheck otorga acceso, así que continúe

Consejo
El DACS la distribución incluye un módulo Perl
(/usr/local/dacs/lib/perl/DACScheck.pm) para hacer dacscheck un poco más fácil de usar.
El ejemplo anterior se escribiría como:

utilice DACScheck.pm;
dacscheck_rules ("/ usr / local / webstats / acls");

my $ resultado = dacscheck_cgi ("/ webstats");
if ($ resultado! = 1) {
# dacscheck deniega el acceso; imprimir mensaje y salir
salida 1;
}

# dacscheck otorga acceso, así que continúe

Un simple DACS La regla de control de acceso se puede escribir para duplicar la seguridad del programa.
funcionalidad (usando el usuario() y de() predicados, ver dacs.exprs(5)[22]), pero
Se pueden agregar fácilmente políticas más sofisticadas, todo sin tener que modificar el Perl.
programa de nuevo.

La diagnostica

El programa sale 0 si se concede acceso y 1 si se deniega el acceso. Cualquier otro estado de salida
indica que ocurrió un error.

Use dacscheck en línea usando los servicios de onworks.net