Cómo asegurar los trabajos planificados

Los trabajos planificados pueden ser un agujero en la seguridad del sistema si no

están convenientemente protegidos. Aunque el sistema operativo impone bastantes
restricciones para planificar y ejecutar un trabajo, un usuario con las suficientes
habilidades podría aprovechar alguna debilidad para manipular fraudulentamente
la lista de trabajos. De hecho, la política de seguridad que aquí se propone surge al
descubrir una vulnerabilidad en un sistema aparentemente protegido.

Configuración de fábrica

Los trabajos planificados se gestionan con seis mandatos CL:

 Añadir entrada de planificación de trabajos (ADDJOBSCDE)

 Cambiar entrada de planificación de trabajos (CHGJOBSCDE)
 Eliminar entrada de planificación de trabajos (RMVJOBSCDE)
 Retener entrada de planificación de trabajos (HLDJOBSCDE)
 Liberar entrada de planificación de trabajos (RLSJOBSCDE)
 Trabajar con entradas de planificación de trabajos (WRKJOBSCDE)

y con la API List Job Schedule Entries (QWCLSCDE).

Toda la información sobre los trabajos planificados se registra en el objeto
QDFTJOBSCD en la biblioteca QUSRSYS y con el tipo *JOBSCD.
Las dos tablas siguientes resumen las autorizaciones de fábrica de los objetos
anteriores.

Autorizaciones de fábrica de los mandatos JOBSCDE

Usuario ADDJOBSCDE CHGJOBSCDE RMVJOBSCDE HLDJOBSCDE RLSJOBSCDE WRKJOBSCDE

Propietario QSYS QSYS QSYS QSYS QSYS QSYS

*PUBLIC *USE *USE *USE *USE *USE *USE

QSYS *ALL *ALL *ALL *ALL *ALL *ALL

QSRVAGT *USE *USE

Autorizaciones del objeto QDFTJOBSCD tipo *JOBSCD

Usuario Autorización Propietario

*PUBLIC *CHANGE

QSYS *ALL SI
Nota: La comprobación de estos valores se ha realizado en dos equipos con
versiones 6.1 y 7.2. Ninguno de los objetos está protegido con lista de autorizaciones
ni tiene asignado Grupo primario.
A primera vista se observa que cualquier usuario que pudiera introducir un mandato
en el sistema podría planificar o manipular entradas de trabajos. En realidad esta
situación no es exactamente así. Por ejemplo, para añadir un trabajo planificado
además se requiere:

 Autorización *USE sobre el mandato especificado en el parámetro CMD.

 Autorización *USE sobre la descripción del trabajo especificada en el
parámetro JOBD.
 Autorización *USE sobre la cola de trabajos especificada en el parámetro
JOBQ. La autorización no puede proceder de una autorización adoptada.
 Autorización *USE sobre el perfil de usuario que ejecuturá el trabajo
(parámetro USER).
 Autorización *USE y *ADD sobre la cola de mensajes especificada en el
parámetro MSGQ. La autorización no puede proceder de una autorización
adoptada.
 Autorización *CHANGE sobre el objeto QDFTJOBSCD de tipo *JOBSCD
ubicado en la biblioteca QUSRSYS.
 Autorización *EXECUTE sobre las bibliotecas de todos los objetos anteriores.

Por otro lado, un usuario sólo podrá utilizar los mandatos CHGJOBSCDE,
RMVJOBSCDE, HLDJOBSCDE y RLSJOBSCDE con las entradas planificadas por él
mismo. Si se intenta modificar una entrada planificada por otro usuario se emitirá
el mensaje de error CPF1630.
La siguiente tabla resume las autorizaciones que debe tener un usuario para
gestionar los trabajos planificados:

Resumen de autorizaciones
Autorización
Aut Planificado Aut Aut Aut Aut Aut sobre
Mandato QDFTJOBSCD
mandato por JOBD JOBQ USER MSGQ bibliotecas
*JOBSCD

*USE
ADDJOBSCDE *USE *USE *USE *USE *CHANGE *EXECUTE
*ADD

*USE
CHGJOBSCDE *USE Usuario ADD *USE *USE *USE *CHANGE *EXECUTE
*ADD

RMVJOBSCDE *USE Usuario ADD *CHANGE (1) *EXECUTE

HLDJOBSCDE *USE Usuario ADD *CHANGE (1) *EXECUTE

RLSJOBSCDE *USE Usuario ADD *CHANGE (1) *EXECUTE

WRKJOBSCDE *USE *USE *EXECUTE

(1) En la ayuda de los mandatos RMVJOBSCDE, HLDJOBSCDE y RLSJOBSCDE se
indica claramente que se necesita la autorización *USE sobre el objeto
QDFTJOBSCD, pero si se utilizan con ese permiso el sistema alertará al usuario con
el mensaje CPF1629 e impedirá la operación. Las pruebas se realizaron en la versión
7.2 con el nivel de PTF acumulativo 15310.
Cualquier usuario con la autorización especial *JOBCTL podrá alterar cualquier
entrada (aunque no la haya planificado) si tiene los permisos necesarios sobre los
distintos objetos involucrados (mandatos, usuarios, colas, etc). Con una autorización
especial *ALLOBJ se ignora cualquier requisito y permite hacer lo que se quiera
sobre la planificación.

Protección extrema

Se pueden aplicar diferentes políticas para proteger los trabajos planificados, desde
la más suave que consiste en dejar las cosas como vienen de fábrica; o exageradas
como impedir cualquier tipo de operación sobre la lista de trabajos.
El siguiente ejemplo ilustra una proteción extrema que impide que cualquier
usuario sin autorizaciones explícitas pueda planificar o cambiar una entrada. Ni
siquiera extraer información de los trabajos planificados. Sin embargo, todos los
usuarios autorizados podrán hacer de todo siempre que se cumplan los requisitos
para la entrada en cuestión.
El esquema propuesto se sustenta en dos elementos clave: en un grupo de usuarios
y en una lista de autorizaciones. Todos los miembros del grupo podrán alterar la lista
de trabajos. La lista de autorizaciones establece los permisos del grupo de usuarios y
se empleará para proteger los mandatos de planificación. Esta estructura permite
que un usuario quede autorizado por hacerle miembro del grupo. La lista de
autorizaciones facilita un cambio en los permisos del grupo en un solo paso, sin tener
que cambiar cada uno de los objetos protegidos.
En el ejemplo, el grupo de usuarios se ha llamadao GRPJOBSCD (Grupo para
trabajos planificados) y será el responsable de los trabajos planificados:
CrtAutL AutL( JOBSCDE ) +
Text( 'Proteger trabajos planificados.' ) +
Aut( *EXCLUDE )
AddAutlE AutL( JOBSCDE ) +
User( GRPJOBSCD ) Aut( *USE )
La lista de autorizaciones se crea con *PUBLIC *EXCLUDE por dos motivos: para
evitar que los usuarios sin permisos específicos puedan alterarla y para impedir el
empleo de los mandatos protegidos. Los miembros del grupo podrán utilizar los
mandatos al diponer de la autorización *USE.
A continuación, el mandato ADDJOBSCDE se protege con la lista de
autorizaciones:
GrtObjAut Obj( ADDJOBSCDE ) ObjType( *CMD ) +
AutL( JOBSCDE )
GrtObjAut Obj( ADDJOBSCDE ) ObjType( *CMD ) +
User( *PUBLIC ) Aut( *AUTL )
Indirectamente, estas dos operaciones otorgan al grupo GRPJOBSCD el permiso
para utilizar el mandato ADDJOBSCDE y se le impide al público en general
(*PUBLIC). Repítanse estas operaciones con los mandatos CHGJOBSCDE,
RMVJOBSCDE, HLDJOBSCDE, RLSJOBSCDE y WRKJOBSCDE.
Finalmente se protege el objeto que contiene la información de los trabajos
planificados:
GrtObjAut Obj( QDFTJOBSCD ) ObjType( *JOBSCD ) +
User( *PUBLIC ) Aut( *EXCLUDE )
GrtObjAut Obj( QDFTJOBSCD ) ObjType( *JOBSCD ) +
User( GRPJOBSCD ) Aut( *CHANGE )
GrtObjAut Obj( QDFTJOBSCD ) ObjType( *JOBSCD ) +
User( QSRVAGT ) Aut( *CHANGE )
Se prohibe al público en general cualquier operación sobre los trabajos planificados,
como por ejemplo: salvarlos o restaurarlos, obtener una lista de los trabajos
mediante una API del sistema, etc. Se le concede autorización *CHANGE a los
miembros del grupo GRPJOBSCD. También se incluye al usuario QSRVAGT por
prudencia ya que está autorizado a usar los mandatos ADDJOBSCDE y
CHGJOBSCDE.
Este esquema no habilita a los usuarios del grupo a planificar cualquier trabajo, el
sistema seguirá comprobando las autorizaciones sobre todos los objetos
especificados en los mandatos ADDJOBSCDE y CHGJOBSCDE. Además, el usuario
deberá tener la autorización especial *JOBCTL si quisiera cambiar, retener, liberar
o eliminar una entrada planificada por otro usuario.
Finalmente, estos cambios en la seguridad no parecen afectar a los procesos
realizados por el sistema para someter los trabajos a su hora y para modificar la
información de último sometimiento. Probablemente sea el usuario QSYS quien
realice todas estas operaciones.