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.
> 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.
> 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,
--
KaiGai Kohei <kaigai@xxxxxxxxxxxx>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
