SYSCTRL granting itself SYSADM

Chuck Hinchey

SYSCTRL granting itself SYSADM
I found this in the V5 Admin manual.

¦ SYSCTRL authority is intended for separation of ¦
¦ function, not for added security. If any plans have ¦
¦ their EXECUTE privilege granted to PUBLIC, an ID with ¦
¦ SYSCTRL authority can grant itself SYSADM authority. The ¦
¦ only control over such actions is to audit the activity ¦
¦ of IDs with high levels of authority. ¦

What about "any plans have there EXECUTE authority granted to PUBLIC" allows
a SYSCTRL to grant itself SYSADM? This was the only reference to this that
I could find, although there was another statement that implied something
similar.

I thought that "SYSCTRL" WAS for added data security, otherwise why have it?
Does anyone know if this is correct? Is anyone using SYSCTRL?


Chuck Hinchey
[login to unmask email]

Mike Vaughan

Re: SYSCTRL granting itself SYSADM
(in response to Chuck Hinchey)
As far as syscntrl authority existing for data-security, think of it this
way -- Syscntrl authority includes the ability to bind a plan/package with any
authid as the owner. If someone with syscntrl wanted to access some data that
they did not have access to, it would be as simple as binding a plan used by
something like spufi or qmf with dynamicrules(bind), and putting a sysadm
authid as the plan-owner (If the "RETAIN" keyword is used, then the syscntrl
authid still has execute access on the plan, which can now access any data).
Also keep in mind that syscntrl includes dbctrl over any database, and could
load, stop, or even drop that same table.
This doesn't explain how someone with syscntrl could grant themselves
sysadm since the grant statement cannot be dynamically prepared in a plan
bound with dynamicrules(bind), but this could be done easily enough using
static sql (and a plan having execute access granted to public wouldn't need
to exist in order for this to happen).
I don't think this necessarily makes using syscntrl authority worthless. I
look at it as a way of telling people what they "shouldn't" do instead of what
they "can't" do. Look at the first sentence of the description of syscntrl in
the Administration guide: "has nearly complete control of the DB2 subsystem".
Generally, the people given this level of authority are the people that can be
trusted not to take advantage of it.

Mike.

..all my own opinions, etc.
-----Original Message-----
From: Chuck Hinchey [mailto:[login to unmask email]
Sent: Friday, October 08, 1999 11:02 AM
To: [login to unmask email]
Subject: SYSCTRL granting itself SYSADM


I found this in the V5 Admin manual.

¦ SYSCTRL authority is intended for separation of ¦
¦ function, not for added security. If any plans have ¦
¦ their EXECUTE privilege granted to PUBLIC, an ID with ¦
¦ SYSCTRL authority can grant itself SYSADM authority. The ¦
¦ only control over such actions is to audit the activity ¦
¦ of IDs with high levels of authority. ¦

What about "any plans have there EXECUTE authority granted to PUBLIC" allows
a SYSCTRL to grant itself SYSADM? This was the only reference to this that
I could find, although there was another statement that implied something
similar.

I thought that "SYSCTRL" WAS for added data security, otherwise why have it?
Does anyone know if this is correct? Is anyone using SYSCTRL?


Chuck Hinchey
[login to unmask email]