Question & Answer
Question
Why the 200 - 300 grants from public by TERADATA are not included by default in Guardium Vulnerability Assessment Test ID 2029?
Cause
TERADATA allows 200 - 300 grants from public. Just to name a few critical objects
- GRANT SELECT ON DBC.IndexConstraints TO PUBLIC;
- GRANT SELECT ON DBC.Authorizations TO PUBLIC;
- GRANT SELECT ON DBC.Table_LevelConstraintsV TO PUBLIC;
The 200 - 300 grants are tailored out of the box. If you do not restrict them, it means any users have access to the database (DBC) inherit the privileged rights to do anything listed as GRANT TO PUBLIC. On any mission critical system, it is NOT good to grant to public even as best practice we advise against giving grant to public. So it is not the correct data access protection security level that any database can have.
Revoking privileges from PUBLIC grantee is subjective discussion. There are application grants to PUBLIC. Then, there are database vendors grants to PUBLIC. In many cases, it is not trivial to know who is doing the grants (DB vendor or customers.) One can look at the grantor column, but that can be just a system ID which customers can initiate the grants. There are no flags available to know whether system grants exist.
Currently, Test ID 2029 has pre-defined group contains 12 members. These 12 grants were given by TERADATA Security Architecture team as the list of grants to PUBLIC that is required at the minimum for database server operational. Most of these grants can be revoked from PUBLIC. It means any tools or application that use some of these default grants would stop working unless you create specific roles and for them to the require tools.
If client wants to include more members into TERADATA Vulnerability Assessment Test ID 2029 (Object privileges granted TO PUBLIC), we have pre-defined group "TERADATA Allowed Grants to Public" to exclude default grants from TERADATA.
Customers have two choices:
1. Use our exception group or clone it and revoke everything else that is granted to PUBLIC on the DB level that is not in our exception group.
2. Create your own exception group and remove everything they do not feel comfortable by revoking from PUBLIC.
Answer
The resolution is:
Step 1: Add new members into exception group
Step 2: Create roles for users and grant remaining 200 - 300 grant from public to users individually
Step 3: Revoke those remaining 200 - 300 grants from public one by one from the database.
Removal of grant from public run this command:
REVOKE ALL ON DB_NAME.OBJECT_NAME FROM PUBLIC;
Was this topic helpful?
Document Information
Modified date:
31 August 2021
UID
ibm10732245