KaiGai Kohei wrote:
Andy Warner wrote:
looks good to me.
One minor comment. For the superuser permission, this may be common use
of DBMS's but I believe is not a standard SQL feature. RUBIX has no such
concept, so we would generally ignore that permission. Also, it is
unclear to me what abilities the superuser should have (in the general
sense, not necessarily within sepostgresql).
It is a request from the pgsql-hackers.
In addition, the permission is well symmetrical with root capability
on operating system.
In PostgreSQL, database users with superuser privilege are allowed
various kind of operating, such as ignoring DAC policy, ignoring
ownership of database objects, installing shared libraries and so on.
The db_database:{superuser} enables to control these capabilities.
Sounds like our DBA role. Basically, its just a different name. I agree
that the superuser is a common concept in OS's, but note that its use
is often discouraged. I'm note sure introducing it for databases is a
great idea. But, as I said before, we would just ignore it as
primarily its there to satisfy postgresql.
Is this just a permission
to override SQL DAC, or does it also give administrative abilities like
setting audit configurations, or "all the above." I think you said
before that it would not allow MAC override, correct?
SELinux does not allow anyone to override MAC.
The unconfined domain is allowed anything in the result of access controls.
I am referring to things like:
mlsconstrain { db_tuple } { use select }
(( l1 dom l2 ) or
(( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
( t1 == mlsdbread ) or
( t2 == mlstrustedobject ));
where t1 == mlsdbread seems to imply an object is trusted to read
strictly dominating objects. Unless I am missing the meaning here, I
would call this a MAC override. I realize there is no concept of a TE
override, but MLS is part of MAC, no? And, this violates B&L rules.
This is something we would control with a Security Administrator
"role". Or, is this mlsdbread something that is impossible to give to a
domain in a DBMS policy?
RUBIX currently has four privileged "roles":
Database Administrator: DAC override
Security Administrator: MAC override, to some degree. With SELinux much
of this can be done with discrete rules.
Audit Administrator: administer audit trail and criteria
Database Operator: do the normal day-today administrative DBMS tasks,
like backup.
I am curious, if the intended use of the db_database superuser
permission would be an encapsulation of our all of our roles, excluding
the Security Administrator.
My preference is to adopt common design *as far as possible*.
If you need finer-grained privileges, please propose it as a characteristic
part for Trusted RUBIX, as if we did on db_catalog class.
Anyway, I cannot believe the pgsql-hackers accepts its design changes due
to the RUBIX's design.
Thanks,
|
