On Thu, 2009-04-02 at 10:27 -0400, Joshua Brindle wrote:
> KaiGai Kohei wrote:
> > Chris,
> >
> > What is your opinion about this reworks?
> > If its scale is too large to commit at once, I can separate it
> > into several pieces.
> >
>
> I don't think it is a good idea to merge the object class changes at this point.
> The object classes and permissions are likely to change with sepostgresql going
> forward, as that community determines what they like and don't like
> access-control wise.
>
> Additionally there is another object manager (RUBIX) that is now going to be
> reliant on these object classes so it would be nice for them to work out some of
> their implementation just to be sure these are sufficient and finally merging
> these object class changes is going to break the sepostgres that is in fedora
> right now.
Agreed. I don't want to merge any object class changes until they have
settled down. I'd prefer that the patches to the object manager be on a
path for upstream acceptance in both databases, if not already committed
to their trees, before moving forward on the object class changes in the
policy.
> I'm not sure how you plan to reconcile the sepostgres in Fedora vs. the work
> with upstream postgresql with the policies available in Fedora (and upstream
> refpolicy) but I don't think we can just start breaking things now, upstream
> refpolicy shouldn't be treated as a playground.
Permissions shouldn't be deleted, as it causes compatibility issues.
The permissions that are deprecated should be marked as such in
access_vectors, so that at some point in the future we can reclaim them,
if needed.
> > KaiGai Kohei wrote:
> >> As we have discussed for the recent week, I have a plan to rework
> >> some of security policy for SE-PostgreSQL.
> >>
> >> The attached patch adds the significan changes, as follows.
> >> Could you give me any suggestion, approval or opposition?
> >>
> >> New object classes and permissions
> >> ----------------------------------
> >> * db_catalog class
> >> It shows the top level namespace in the database, and has a capability
> >> to store a set of schemas. Some of implementation does not support
> >> catalogs. In this case, we simply ignore this class and any schemas
> >> are placed under the db_database directly.
> >>
> >> It defines the following four permissions and inherited ones:
> >> { search add_object remove_object associate }
> >>
> >> Client should have db_catalog:{search} on the catalog when he refers
> >> any schemas under the catalog, and he should also have
> >> db_catalog:{add_object} and db_catalog:{remove_object} on the catalog
> >> when he tries to add or remove a shema within the catalog.
> >> These permissions are an analogy of dir object class.
> >>
> >> The db_catalog:{associate}, which I've not introduced yet but noticed
> >> its necessity, is also checked when we create or relabel a schema
> >> within the catalog, and the schema should have db_catalog:{associate}
> >> on the catalog. It is an analogy of filesystem:{associate}.
> >> It prevents a schema is labeled unexpectedly.
> >>
> >> * db_schema class
> >> It shows the second level namespace in the database, but it may be
> >> the top level one in some of implementation (like PostgreSQL).
> >> It has a capability to store a set of database objects (tables,
> >> procedures and so on).
> >>
> >> It defines the following four permissions and inherited ones:
> >> { search add_object remove_object associate }
> >> Their meanings are similar to ones in db_catalog class except for
> >> the schema to be replaced by database objects.
> >>
> >> Its security context can be computed with TYPE_TRANSITION between
> >> the client as a subject and the database (or catalog, if availabel)
> >> as a target.
> >>
> >> * db_sequence class
> >> It shows the sequential number generator objects. We can also use
> >> them as a communication channel between two domains, so it is
> >> necessary to apply security policy.
> >>
> >> It inherits common database and defines the following two permissions:
> >> { get_value set_value }
> >> Client should have db_sequence:{get_value} when he fetch a value from
> >> the sequence generator, and db_sequence:{set_value} when he set a
> >> discretionary value. When he fetch a value from the sequence object,
> >> it implicitly increments internal counter, but it is covered by the
> >> get_value permission.
> >>
> >> Its security context can be computed with TYPE_TRANSITION between
> >> the client as a subject and the schema as a target.
> >>
> >> Change definition of object classes
> >> -----------------------------------
> >> * db_database class
> >> The db_database:{get_param set_param} is removed because these two
> >> permissions are nonsense.
> >> The db_database:{superuser} is newly added. It is checked when
> >> client perform as database superuser. Stephen suggested it can
> >> be separated to more finer grained privileges. It makes sense,
> >> but this kind of separation which focuses on PostgreSQL makes
> >> hard to port the concept for other database management systems.
> >>
> >> * db_table/db_column/db_tuple:{use} permission
> >> The db_xxx:{use} permission is integrated into db_xxx:{select}
> >> permission, because it can hide the risk to infer invisible
> >> information easily with well considered WHERE clauses.
> >>
> >> user_sepgsql_xxxx_t types
> >> -------------------------
> >> * Currently, sepgsql_proc_t is assigned to the procedures created
> >> by unprivileged and unprefixed clients, like httpd_t.
> >> But I would like to handle it as a procedure created or relabeled
> >> by database administrator.
> >> Basically, we consider user defined procedures are untrusted, so
> >> it should be checked before it becomes available for all the clients.
> >> So, we don't allow to install them as system internal entities, and
> >> don't allow unconfined domains to execute them directly.
> >>
> >> My preference is the user_sepgsql_xxxx_t is also assigned to
> >> procedures created by unprivileged and unprfixed client.
> >>
> >> A schema for temporary obejcts
> >> ------------------------------
> >> * The sepgsql_schema_t is the default type for schema objects, and
> >> rest of database objects within the schema is labeled with the chain
> >> of TYPE_TRANSITION rules.
> >> We have a characteristic scheme named as "pg_temp_*". Any database
> >> objects within the schema are cleared after the session closed,
> >> so its contents are always session local. We would like to assign
> >> special types on the temporary schema and delivered database objects
> >> withing the schema. In addition, users can create and use these
> >> database objects independently from the sepgsql_enable_users_ddl.
> >>
> >> Booelean behavior: sepgsql_enable_users_ddl
> >> -------------------------------------------
> >> * Because the current design does not care about actions on schema
> >> objects, we need to assign separated label (sepgsql_sysobj_t) on
> >> system informations and apply checks as row-level controls.
> >> But db_schema object class enables to control user's DDLs in
> >> the schema level checks mainly, so now sepgsql_enable_user_ddl
> >> focuses on db_schema class permissions and {create drop setattr}
> >> for any other database objects.
> >> The attached patch allows users to modify tuples with sepgsql_sysobj_t
> >> but not allows columns/tables. It means user can define database
> >> objects with proper way (like CREATE TABLE), but prevents to
> >> manipulate system information by hand.
> >> In addition, this boolean controls only user_sepgsql_xxxx_t.
> >> The unprefixed types are always not allowed to modify its definition
> >> by unprivileges users.
> >>
> >> db_table:{lock} for reader actions
> >> ----------------------------------
> >> * db_table:{lock} is also necessary for reader side actions due to the
> >> implementation reason.
> >> In PostgreSQL, FK constraints are implemented as trigger functions.
> >> It is invoked for each INSERT/UPDATE/DELETE on constrainted tuples,
> >> and run a secondary query to check whether the action satisfies
> >> FK constraints or not.
> >> This query is described as:
> >> SELECT 1 FROM t WHERE k = "$1" FOR SHARE;
> >>
> >> The "FOR SHARE" clause means explicit table lock and requires
> >> db_table:{lock} permission. If we don't allow unpriv clients to
> >> lock read-only tables, it disables to set up FK constraint which
> >> refers read-only tables.
> >>
> >> Miscellaneous changes
> >> ---------------------
> >> * The security context of a new database is decided via type_transition
> >> on the server process's context. It enables to avoid conflicts when
> >> we have multiple DBMSs in a system.
> >> * It allows postgresql_t domain to write out messages to system audit.
> >> * sepgsql_proc_t is aliased to sepgsql_proc_exec_t.
> >> * db_procedure:{install} is revoked from sepgsql_trusted_proc_exec_t,
> >> because we don't need to run trusted procedure implicitly.
> >> * Most of postgresql_role() are shared with postgresql_unpriv_client(),
> >> except for "role $1 types sepgsql_trusted_proc_t;"
> >> * /etc/selinux/$POLICYTYPE/contexts/db_contexts for selabel_lookup(3)
> >>
> >> Thanks,
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> refpolicy mailing list
> >> refpolicy at oss.tresys.com
> >> http://oss.tresys.com/mailman/listinfo/refpolicy
> >
> >
>
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
Christopher J. PeBenito wrote:
> On Thu, 2009-04-02 at 10:27 -0400, Joshua Brindle wrote:
>> KaiGai Kohei wrote:
>>> Chris,
>>>
>>> What is your opinion about this reworks?
>>> If its scale is too large to commit at once, I can separate it
>>> into several pieces.
>>>
>> I don't think it is a good idea to merge the object class changes at this point.
>> The object classes and permissions are likely to change with sepostgresql going
>> forward, as that community determines what they like and don't like
>> access-control wise.
>>
>> Additionally there is another object manager (RUBIX) that is now going to be
>> reliant on these object classes so it would be nice for them to work out some of
>> their implementation just to be sure these are sufficient and finally merging
>> these object class changes is going to break the sepostgres that is in fedora
>> right now.
>
> Agreed. I don't want to merge any object class changes until they have
> settled down. I'd prefer that the patches to the object manager be on a
> path for upstream acceptance in both databases, if not already committed
> to their trees, before moving forward on the object class changes in the
> policy.
As I noted in the previous message, it give me a deadlock. :(
I don't think it is a realistic assumption that pgsql-hackers are
well motivated to modify or replace the default security policy to
review and test the proposed features. I guess it gives us negative
effect to upstream the SE-PostgreSQL feature in the v8.5 release.
At least, these new object classes don't have any strange behavior.
The vanilla PostgreSQL also has similar permissions, so it convinces
me they can accept these permissions, more than nothing for them.
Again, I would like to get the reworks merged in this timing.
(In addition, it also makes RUBIX happy on Fedora 11 or later.)
>> I'm not sure how you plan to reconcile the sepostgres in Fedora vs. the work
>> with upstream postgresql with the policies available in Fedora (and upstream
>> refpolicy) but I don't think we can just start breaking things now, upstream
>> refpolicy shouldn't be treated as a playground.
>
> Permissions shouldn't be deleted, as it causes compatibility issues.
> The permissions that are deprecated should be marked as such in
> access_vectors, so that at some point in the future we can reclaim them,
> if needed.
Something like ... ?
class db_table
inherits database
{
use # deprecated
select
update
:
Do you intend it to be handled as a hint for the script to generate
the <class>_all_perms?
Thanks,
>>> KaiGai Kohei wrote:
>>>> As we have discussed for the recent week, I have a plan to rework
>>>> some of security policy for SE-PostgreSQL.
>>>>
>>>> The attached patch adds the significan changes, as follows.
>>>> Could you give me any suggestion, approval or opposition?
>>>>
>>>> New object classes and permissions
>>>> ----------------------------------
>>>> * db_catalog class
>>>> It shows the top level namespace in the database, and has a capability
>>>> to store a set of schemas. Some of implementation does not support
>>>> catalogs. In this case, we simply ignore this class and any schemas
>>>> are placed under the db_database directly.
>>>>
>>>> It defines the following four permissions and inherited ones:
>>>> { search add_object remove_object associate }
>>>>
>>>> Client should have db_catalog:{search} on the catalog when he refers
>>>> any schemas under the catalog, and he should also have
>>>> db_catalog:{add_object} and db_catalog:{remove_object} on the catalog
>>>> when he tries to add or remove a shema within the catalog.
>>>> These permissions are an analogy of dir object class.
>>>>
>>>> The db_catalog:{associate}, which I've not introduced yet but noticed
>>>> its necessity, is also checked when we create or relabel a schema
>>>> within the catalog, and the schema should have db_catalog:{associate}
>>>> on the catalog. It is an analogy of filesystem:{associate}.
>>>> It prevents a schema is labeled unexpectedly.
>>>>
>>>> * db_schema class
>>>> It shows the second level namespace in the database, but it may be
>>>> the top level one in some of implementation (like PostgreSQL).
>>>> It has a capability to store a set of database objects (tables,
>>>> procedures and so on).
>>>>
>>>> It defines the following four permissions and inherited ones:
>>>> { search add_object remove_object associate }
>>>> Their meanings are similar to ones in db_catalog class except for
>>>> the schema to be replaced by database objects.
>>>>
>>>> Its security context can be computed with TYPE_TRANSITION between
>>>> the client as a subject and the database (or catalog, if availabel)
>>>> as a target.
>>>>
>>>> * db_sequence class
>>>> It shows the sequential number generator objects. We can also use
>>>> them as a communication channel between two domains, so it is
>>>> necessary to apply security policy.
>>>>
>>>> It inherits common database and defines the following two permissions:
>>>> { get_value set_value }
>>>> Client should have db_sequence:{get_value} when he fetch a value from
>>>> the sequence generator, and db_sequence:{set_value} when he set a
>>>> discretionary value. When he fetch a value from the sequence object,
>>>> it implicitly increments internal counter, but it is covered by the
>>>> get_value permission.
>>>>
>>>> Its security context can be computed with TYPE_TRANSITION between
>>>> the client as a subject and the schema as a target.
>>>>
>>>> Change definition of object classes
>>>> -----------------------------------
>>>> * db_database class
>>>> The db_database:{get_param set_param} is removed because these two
>>>> permissions are nonsense.
>>>> The db_database:{superuser} is newly added. It is checked when
>>>> client perform as database superuser. Stephen suggested it can
>>>> be separated to more finer grained privileges. It makes sense,
>>>> but this kind of separation which focuses on PostgreSQL makes
>>>> hard to port the concept for other database management systems.
>>>>
>>>> * db_table/db_column/db_tuple:{use} permission
>>>> The db_xxx:{use} permission is integrated into db_xxx:{select}
>>>> permission, because it can hide the risk to infer invisible
>>>> information easily with well considered WHERE clauses.
>>>>
>>>> user_sepgsql_xxxx_t types
>>>> -------------------------
>>>> * Currently, sepgsql_proc_t is assigned to the procedures created
>>>> by unprivileged and unprefixed clients, like httpd_t.
>>>> But I would like to handle it as a procedure created or relabeled
>>>> by database administrator.
>>>> Basically, we consider user defined procedures are untrusted, so
>>>> it should be checked before it becomes available for all the clients.
>>>> So, we don't allow to install them as system internal entities, and
>>>> don't allow unconfined domains to execute them directly.
>>>>
>>>> My preference is the user_sepgsql_xxxx_t is also assigned to
>>>> procedures created by unprivileged and unprfixed client.
>>>>
>>>> A schema for temporary obejcts
>>>> ------------------------------
>>>> * The sepgsql_schema_t is the default type for schema objects, and
>>>> rest of database objects within the schema is labeled with the chain
>>>> of TYPE_TRANSITION rules.
>>>> We have a characteristic scheme named as "pg_temp_*". Any database
>>>> objects within the schema are cleared after the session closed,
>>>> so its contents are always session local. We would like to assign
>>>> special types on the temporary schema and delivered database objects
>>>> withing the schema. In addition, users can create and use these
>>>> database objects independently from the sepgsql_enable_users_ddl.
>>>>
>>>> Booelean behavior: sepgsql_enable_users_ddl
>>>> -------------------------------------------
>>>> * Because the current design does not care about actions on schema
>>>> objects, we need to assign separated label (sepgsql_sysobj_t) on
>>>> system informations and apply checks as row-level controls.
>>>> But db_schema object class enables to control user's DDLs in
>>>> the schema level checks mainly, so now sepgsql_enable_user_ddl
>>>> focuses on db_schema class permissions and {create drop setattr}
>>>> for any other database objects.
>>>> The attached patch allows users to modify tuples with sepgsql_sysobj_t
>>>> but not allows columns/tables. It means user can define database
>>>> objects with proper way (like CREATE TABLE), but prevents to
>>>> manipulate system information by hand.
>>>> In addition, this boolean controls only user_sepgsql_xxxx_t.
>>>> The unprefixed types are always not allowed to modify its definition
>>>> by unprivileges users.
>>>>
>>>> db_table:{lock} for reader actions
>>>> ----------------------------------
>>>> * db_table:{lock} is also necessary for reader side actions due to the
>>>> implementation reason.
>>>> In PostgreSQL, FK constraints are implemented as trigger functions.
>>>> It is invoked for each INSERT/UPDATE/DELETE on constrainted tuples,
>>>> and run a secondary query to check whether the action satisfies
>>>> FK constraints or not.
>>>> This query is described as:
>>>> SELECT 1 FROM t WHERE k = "$1" FOR SHARE;
>>>>
>>>> The "FOR SHARE" clause means explicit table lock and requires
>>>> db_table:{lock} permission. If we don't allow unpriv clients to
>>>> lock read-only tables, it disables to set up FK constraint which
>>>> refers read-only tables.
>>>>
>>>> Miscellaneous changes
>>>> ---------------------
>>>> * The security context of a new database is decided via type_transition
>>>> on the server process's context. It enables to avoid conflicts when
>>>> we have multiple DBMSs in a system.
>>>> * It allows postgresql_t domain to write out messages to system audit.
>>>> * sepgsql_proc_t is aliased to sepgsql_proc_exec_t.
>>>> * db_procedure:{install} is revoked from sepgsql_trusted_proc_exec_t,
>>>> because we don't need to run trusted procedure implicitly.
>>>> * Most of postgresql_role() are shared with postgresql_unpriv_client(),
>>>> except for "role $1 types sepgsql_trusted_proc_t;"
>>>> * /etc/selinux/$POLICYTYPE/contexts/db_contexts for selabel_lookup(3)
>>>>
>>>> Thanks,
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> refpolicy mailing list
>>>> refpolicy at oss.tresys.com
>>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>>
--
OSS Platform Development Division, NEC
KaiGai Kohei <[email protected]>
The attached patch provides some of reworks and bugfuxes
except for new object classes and permissions.
- rework: Add a comment of "not currently in use" for deprecated
permissions, but its definitions are not removed.
- bugfix: MCS policy did not constrain the following permissions.
db_database:{getattr}
db_table:{getattr lock}
db_column:{getattr}
db_procedure:{drop getattr setattr}
db_blob:{getattr import export}
- rework: All the newly created database objects by unprivileged
clients are prefixed with "user_", and these are controled via
sepgsql_enable_users_ddl.
The current policy allows httpd_t to created a function labeled
as sepgsql_proc_t which is also allowed to be installed as a
system internal entity (db_procedure:{install}).
It is a potentially risk for trojan horse.
- rework: postgresql_role() shares most part of postgresql_unpriv_client().
- bugfix: some of permissions in db_procedure class are allowed
on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
It should allow them on sepgsql_trusted_proc_exec_t.
I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
such kind of confusion, as Chris suggested before.
- rework: we should not allow db_procedure:{install} on the
sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
procedure implicitly.
- rework: db_table:{lock} is moved to reader side, because it makes
impossible to refer read-only table with foreign-key constraint.
(FK checks internally acquire explicit locks.)
- bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
but it is required whrn the largeobject is refered.
- bugfix: MLS policy didn't constrain the db_procedure class.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <[email protected]>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-sepgsql-rework.3.patch
Type: text/x-patch
Size: 14309 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090406/e8464137/attachment.bin
Chris,
what is your opinion for the reworks and bugfixes?
KaiGai Kohei wrote:
> The attached patch provides some of reworks and bugfuxes
> except for new object classes and permissions.
>
> - rework: Add a comment of "not currently in use" for deprecated
> permissions, but its definitions are not removed.
>
> - bugfix: MCS policy did not constrain the following permissions.
> db_database:{getattr}
> db_table:{getattr lock}
> db_column:{getattr}
> db_procedure:{drop getattr setattr}
> db_blob:{getattr import export}
>
> - rework: All the newly created database objects by unprivileged
> clients are prefixed with "user_", and these are controled via
> sepgsql_enable_users_ddl.
> The current policy allows httpd_t to created a function labeled
> as sepgsql_proc_t which is also allowed to be installed as a
> system internal entity (db_procedure:{install}).
> It is a potentially risk for trojan horse.
>
> - rework: postgresql_role() shares most part of postgresql_unpriv_client().
>
> - bugfix: some of permissions in db_procedure class are allowed
> on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
> It should allow them on sepgsql_trusted_proc_exec_t.
> I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
> such kind of confusion, as Chris suggested before.
>
> - rework: we should not allow db_procedure:{install} on the
> sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
> procedure implicitly.
>
> - rework: db_table:{lock} is moved to reader side, because it makes
> impossible to refer read-only table with foreign-key constraint.
> (FK checks internally acquire explicit locks.)
>
> - bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
> but it is required whrn the largeobject is refered.
>
> - bugfix: MLS policy didn't constrain the db_procedure class.
>
> Thanks,
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
--
OSS Platform Development Division, NEC
KaiGai Kohei <[email protected]>
On Mon, 2009-04-06 at 11:15 +0900, KaiGai Kohei wrote:
> The attached patch provides some of reworks and bugfuxes
> except for new object classes and permissions.
>
> - rework: Add a comment of "not currently in use" for deprecated
> permissions, but its definitions are not removed.
"deprecated" should be sufficient.
> - bugfix: MCS policy did not constrain the following permissions.
> db_database:{getattr}
> db_table:{getattr lock}
> db_column:{getattr}
> db_procedure:{drop getattr setattr}
> db_blob:{getattr import export}
Looks ok to me.
> - rework: All the newly created database objects by unprivileged
> clients are prefixed with "user_", and these are controled via
> sepgsql_enable_users_ddl.
I don't think we should be mixing user content with other unpriv
clients.
> The current policy allows httpd_t to created a function labeled
> as sepgsql_proc_t which is also allowed to be installed as a
> system internal entity (db_procedure:{install}).
> It is a potentially risk for trojan horse.
>
> - rework: postgresql_role() shares most part of postgresql_unpriv_client().
See above comment.
> - bugfix: some of permissions in db_procedure class are allowed
> on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
> It should allow them on sepgsql_trusted_proc_exec_t.
> I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
> such kind of confusion, as Chris suggested before.
>
> - rework: we should not allow db_procedure:{install} on the
> sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
> procedure implicitly.
>
> - rework: db_table:{lock} is moved to reader side, because it makes
> impossible to refer read-only table with foreign-key constraint.
> (FK checks internally acquire explicit locks.)
>
> - bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
> but it is required whrn the largeobject is refered.
>
> - bugfix: MLS policy didn't constrain the db_procedure class.
Seems ok.
It would be helpful to break up the patch into a set to make it easier
to review in the future.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
Christopher J. PeBenito wrote:
> On Mon, 2009-04-06 at 11:15 +0900, KaiGai Kohei wrote:
>> The attached patch provides some of reworks and bugfuxes
>> except for new object classes and permissions.
>>
>> - rework: Add a comment of "not currently in use" for deprecated
>> permissions, but its definitions are not removed.
>
> "deprecated" should be sufficient.
OK
>> - rework: All the newly created database objects by unprivileged
>> clients are prefixed with "user_", and these are controled via
>> sepgsql_enable_users_ddl.
>
> I don't think we should be mixing user content with other unpriv
> clients.
I would like to discriminate between a procedure declared by unpriv
client and by administrative client, because the policy allows the
unprefixed "sepgsql_proc_exec_t" to be installed as a system internal
component, but it is undesirable to install unpriv-user defined
procedures as is.
If the "user_" prefix is unpreferable, how do you think other prefixes
something like "anon_", "unpriv_" and so on?
>> The current policy allows httpd_t to created a function labeled
>> as sepgsql_proc_t which is also allowed to be installed as a
>> system internal entity (db_procedure:{install}).
>> It is a potentially risk for trojan horse.
>>
>> - rework: postgresql_role() shares most part of postgresql_unpriv_client().
>
> See above comment.
>
>> - bugfix: some of permissions in db_procedure class are allowed
>> on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
>> It should allow them on sepgsql_trusted_proc_exec_t.
>> I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
>> such kind of confusion, as Chris suggested before.
>>
>> - rework: we should not allow db_procedure:{install} on the
>> sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
>> procedure implicitly.
>>
>> - rework: db_table:{lock} is moved to reader side, because it makes
>> impossible to refer read-only table with foreign-key constraint.
>> (FK checks internally acquire explicit locks.)
>>
>> - bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
>> but it is required whrn the largeobject is refered.
>>
>> - bugfix: MLS policy didn't constrain the db_procedure class.
>
> Seems ok.
>
> It would be helpful to break up the patch into a set to make it easier
> to review in the future.
OK,
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <[email protected]>
Chris, the attached patch is the part you already OK'ed.
- rework: Add a comment of "deprecated" for deprecated permissions.
- bugfix: MCS policy did not constrain the following permissions.
db_database:{getattr}
db_table:{getattr lock}
db_column:{getattr}
db_procedure:{drop getattr setattr}
db_blob:{getattr import export}
- rework: db_table:{lock} is moved to reader side, because it makes
impossible to refer read-only table with foreign-key constraint.
(FK checks internally acquire explicit locks.)
- bugfix: some of permissions in db_procedure class are allowed
on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
It should allow them on sepgsql_trusted_proc_exec_t.
I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
such kind of confusion, as Chris suggested before.
- rework: we should not allow db_procedure:{install} on the
sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
procedure implicitly.
- bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
but it is required whrn the largeobject is refered.
- bugfix: MLS policy didn't constrain the db_procedure class.
I'll send the rest of patches after we determine what prefix is preferable
for unprivileged domains.
Thanks,
Christopher J. PeBenito wrote:
> On Mon, 2009-04-06 at 11:15 +0900, KaiGai Kohei wrote:
>> The attached patch provides some of reworks and bugfuxes
>> except for new object classes and permissions.
>>
>> - rework: Add a comment of "not currently in use" for deprecated
>> permissions, but its definitions are not removed.
>
> "deprecated" should be sufficient.
>
>> - bugfix: MCS policy did not constrain the following permissions.
>> db_database:{getattr}
>> db_table:{getattr lock}
>> db_column:{getattr}
>> db_procedure:{drop getattr setattr}
>> db_blob:{getattr import export}
>
> Looks ok to me.
>
>> - rework: All the newly created database objects by unprivileged
>> clients are prefixed with "user_", and these are controled via
>> sepgsql_enable_users_ddl.
>
> I don't think we should be mixing user content with other unpriv
> clients.
>
>> The current policy allows httpd_t to created a function labeled
>> as sepgsql_proc_t which is also allowed to be installed as a
>> system internal entity (db_procedure:{install}).
>> It is a potentially risk for trojan horse.
>>
>> - rework: postgresql_role() shares most part of postgresql_unpriv_client().
>
> See above comment.
>
>> - bugfix: some of permissions in db_procedure class are allowed
>> on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
>> It should allow them on sepgsql_trusted_proc_exec_t.
>> I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
>> such kind of confusion, as Chris suggested before.
>>
>> - rework: we should not allow db_procedure:{install} on the
>> sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
>> procedure implicitly.
>>
>> - rework: db_table:{lock} is moved to reader side, because it makes
>> impossible to refer read-only table with foreign-key constraint.
>> (FK checks internally acquire explicit locks.)
>>
>> - bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
>> but it is required whrn the largeobject is refered.
>>
>> - bugfix: MLS policy didn't constrain the db_procedure class.
>
> Seems ok.
>
> It would be helpful to break up the patch into a set to make it easier
> to review in the future.
>
--
OSS Platform Development Division, NEC
KaiGai Kohei <[email protected]>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-sepgsql-bugfixes.4.patch
Type: text/x-patch
Size: 10216 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090421/88754dc6/attachment-0001.bin
On Tue, 2009-04-21 at 08:27 +0900, KaiGai Kohei wrote:
> Christopher J. PeBenito wrote:
> > On Mon, 2009-04-06 at 11:15 +0900, KaiGai Kohei wrote:
> >> The attached patch provides some of reworks and bugfuxes
> >> except for new object classes and permissions.
> >>
> >> - rework: All the newly created database objects by unprivileged
> >> clients are prefixed with "user_", and these are controled via
> >> sepgsql_enable_users_ddl.
> >
> > I don't think we should be mixing user content with other unpriv
> > clients.
>
> I would like to discriminate between a procedure declared by unpriv
> client and by administrative client, because the policy allows the
> unprefixed "sepgsql_proc_exec_t" to be installed as a system internal
> component, but it is undesirable to install unpriv-user defined
> procedures as is.
>
> If the "user_" prefix is unpreferable, how do you think other prefixes
> something like "anon_", "unpriv_" and so on?
I think we should go with unpriv_ for now.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
On Tue, 2009-04-21 at 11:51 +0900, KaiGai Kohei wrote:
> Chris, the attached patch is the part you already OK'ed.
>
> - rework: Add a comment of "deprecated" for deprecated permissions.
> - bugfix: MCS policy did not constrain the following permissions.
> db_database:{getattr}
> db_table:{getattr lock}
> db_column:{getattr}
> db_procedure:{drop getattr setattr}
> db_blob:{getattr import export}
> - rework: db_table:{lock} is moved to reader side, because it makes
> impossible to refer read-only table with foreign-key constraint.
> (FK checks internally acquire explicit locks.)
> - bugfix: some of permissions in db_procedure class are allowed
> on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
> It should allow them on sepgsql_trusted_proc_exec_t.
> I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
> such kind of confusion, as Chris suggested before.
> - rework: we should not allow db_procedure:{install} on the
> sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
> procedure implicitly.
> - bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
> but it is required whrn the largeobject is refered.
> - bugfix: MLS policy didn't constrain the db_procedure class.
>
> I'll send the rest of patches after we determine what prefix is preferable
> for unprivileged domains.
Merged.
> Christopher J. PeBenito wrote:
> > On Mon, 2009-04-06 at 11:15 +0900, KaiGai Kohei wrote:
> >> The attached patch provides some of reworks and bugfuxes
> >> except for new object classes and permissions.
> >>
> >> - rework: Add a comment of "not currently in use" for deprecated
> >> permissions, but its definitions are not removed.
> >
> > "deprecated" should be sufficient.
> >
> >> - bugfix: MCS policy did not constrain the following permissions.
> >> db_database:{getattr}
> >> db_table:{getattr lock}
> >> db_column:{getattr}
> >> db_procedure:{drop getattr setattr}
> >> db_blob:{getattr import export}
> >
> > Looks ok to me.
> >
> >> - rework: All the newly created database objects by unprivileged
> >> clients are prefixed with "user_", and these are controled via
> >> sepgsql_enable_users_ddl.
> >
> > I don't think we should be mixing user content with other unpriv
> > clients.
> >
> >> The current policy allows httpd_t to created a function labeled
> >> as sepgsql_proc_t which is also allowed to be installed as a
> >> system internal entity (db_procedure:{install}).
> >> It is a potentially risk for trojan horse.
> >>
> >> - rework: postgresql_role() shares most part of postgresql_unpriv_client().
> >
> > See above comment.
> >
> >> - bugfix: some of permissions in db_procedure class are allowed
> >> on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
> >> It should allow them on sepgsql_trusted_proc_exec_t.
> >> I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
> >> such kind of confusion, as Chris suggested before.
> >>
> >> - rework: we should not allow db_procedure:{install} on the
> >> sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
> >> procedure implicitly.
> >>
> >> - rework: db_table:{lock} is moved to reader side, because it makes
> >> impossible to refer read-only table with foreign-key constraint.
> >> (FK checks internally acquire explicit locks.)
> >>
> >> - bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
> >> but it is required whrn the largeobject is refered.
> >>
> >> - bugfix: MLS policy didn't constrain the db_procedure class.
> >
> > Seems ok.
> >
> > It would be helpful to break up the patch into a set to make it easier
> > to review in the future.
> >
>
>
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
>>>> - rework: All the newly created database objects by unprivileged
>>>> clients are prefixed with "user_", and these are controled via
>>>> sepgsql_enable_users_ddl.
>>> I don't think we should be mixing user content with other unpriv
>>> clients.
>> I would like to discriminate between a procedure declared by unpriv
>> client and by administrative client, because the policy allows the
>> unprefixed "sepgsql_proc_exec_t" to be installed as a system internal
>> component, but it is undesirable to install unpriv-user defined
>> procedures as is.
>>
>> If the "user_" prefix is unpreferable, how do you think other prefixes
>> something like "anon_", "unpriv_" and so on?
>
> I think we should go with unpriv_ for now.
OK, the attached patch adds the following types for unprivileged clients.
- unpriv_sepgsql_table_t
- unpriv_sepgsql_sysobj_t
- unpriv_sepgsql_proc_exec_t
- unpriv_sepgsql_blob_t
These types are the default for unprivileged and unprefixed domains,
such as httpd_t and others.
In addition, TYPE_TRANSITION rules are moved to outside of tunable
of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
tunable because UBAC domains (user_t and so on) were allowed to
create sepgsql_table_t, and its default was pointed to this type
when sepgsql_enable_users_ddl is disabled.
However, it has different meanings now, so the TYPE_TRANSITION rules
should be unconditional.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <[email protected]>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-sepgsql-1-unpriv-types.patch
Type: text/x-patch
Size: 4557 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090508/9306855a/attachment.bin
The attached patch fixes incorrect behavior in sepgsql_enable_users_ddl.
The current policy allows users/unprivs to run ALTER TABLE statement
unconditionally, because db_table/db_column:{setattr} is allowed outside
of the boolean. It should be moved to conditional section.
In addition, they are also allowed to db_procedure:{create drop setattr}
for xxxx_sepgsql_proc_exec_t, but it means we allows them to create, drop
or alter definition of the functions unconditionally. So, it also should
be moved to conditional section.
The postgresql.te allows sepgsql_client_type to modify sepgsql_table_t
and sepgsql_sysobj_t when sepgsql_enable_users_ddl is enabled, but
it should not be allowed.
Thanks,
KaiGai Kohei wrote:
>>>>> - rework: All the newly created database objects by unprivileged
>>>>> clients are prefixed with "user_", and these are controled via
>>>>> sepgsql_enable_users_ddl.
>>>> I don't think we should be mixing user content with other unpriv
>>>> clients.
>>> I would like to discriminate between a procedure declared by unpriv
>>> client and by administrative client, because the policy allows the
>>> unprefixed "sepgsql_proc_exec_t" to be installed as a system internal
>>> component, but it is undesirable to install unpriv-user defined
>>> procedures as is.
>>>
>>> If the "user_" prefix is unpreferable, how do you think other prefixes
>>> something like "anon_", "unpriv_" and so on?
>> I think we should go with unpriv_ for now.
>
> OK, the attached patch adds the following types for unprivileged clients.
> - unpriv_sepgsql_table_t
> - unpriv_sepgsql_sysobj_t
> - unpriv_sepgsql_proc_exec_t
> - unpriv_sepgsql_blob_t
>
> These types are the default for unprivileged and unprefixed domains,
> such as httpd_t and others.
>
> In addition, TYPE_TRANSITION rules are moved to outside of tunable
> of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
> tunable because UBAC domains (user_t and so on) were allowed to
> create sepgsql_table_t, and its default was pointed to this type
> when sepgsql_enable_users_ddl is disabled.
> However, it has different meanings now, so the TYPE_TRANSITION rules
> should be unconditional.
>
> Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <[email protected]>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-sepgsql-2-correct-sepgsql_enable_users_ddl.patch
Type: text/x-patch
Size: 3331 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090508/440c820d/attachment.bin
The attached patch allows unprivileged clients to export from or import
to the largeobject owned by themselves.
The current security policy does not allow them to import/export any
largeobjects without any clear reason.
NOTE: Export of the largeobject means that it dumps whole of the
largeobject into a local file, so SE-PostgreSQL checks both of
db_blob:{read export} on the largeobject and file:{write} on the
local file. Import is a reversal behavior.
Thanks,
KaiGai Kohei wrote:
>>>>> - rework: All the newly created database objects by unprivileged
>>>>> clients are prefixed with "user_", and these are controled via
>>>>> sepgsql_enable_users_ddl.
>>>> I don't think we should be mixing user content with other unpriv
>>>> clients.
>>> I would like to discriminate between a procedure declared by unpriv
>>> client and by administrative client, because the policy allows the
>>> unprefixed "sepgsql_proc_exec_t" to be installed as a system internal
>>> component, but it is undesirable to install unpriv-user defined
>>> procedures as is.
>>>
>>> If the "user_" prefix is unpreferable, how do you think other prefixes
>>> something like "anon_", "unpriv_" and so on?
>> I think we should go with unpriv_ for now.
>
> OK, the attached patch adds the following types for unprivileged clients.
> - unpriv_sepgsql_table_t
> - unpriv_sepgsql_sysobj_t
> - unpriv_sepgsql_proc_exec_t
> - unpriv_sepgsql_blob_t
>
> These types are the default for unprivileged and unprefixed domains,
> such as httpd_t and others.
>
> In addition, TYPE_TRANSITION rules are moved to outside of tunable
> of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
> tunable because UBAC domains (user_t and so on) were allowed to
> create sepgsql_table_t, and its default was pointed to this type
> when sepgsql_enable_users_ddl is disabled.
> However, it has different meanings now, so the TYPE_TRANSITION rules
> should be unconditional.
>
> Thanks,
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
--
OSS Platform Development Division, NEC
KaiGai Kohei <[email protected]>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-sepgsql-3-db_blob-import-export.patch
Type: text/x-patch
Size: 1082 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090508/a3d74af0/attachment.bin
On Fri, 2009-05-08 at 12:56 +0900, KaiGai Kohei wrote:
> >>>> - rework: All the newly created database objects by unprivileged
> >>>> clients are prefixed with "user_", and these are controled via
> >>>> sepgsql_enable_users_ddl.
> >>> I don't think we should be mixing user content with other unpriv
> >>> clients.
> >> I would like to discriminate between a procedure declared by unpriv
> >> client and by administrative client, because the policy allows the
> >> unprefixed "sepgsql_proc_exec_t" to be installed as a system
> internal
> >> component, but it is undesirable to install unpriv-user defined
> >> procedures as is.
> >>
> >> If the "user_" prefix is unpreferable, how do you think other
> prefixes
> >> something like "anon_", "unpriv_" and so on?
> >
> > I think we should go with unpriv_ for now.
>
> OK, the attached patch adds the following types for unprivileged
> clients.
> - unpriv_sepgsql_table_t
> - unpriv_sepgsql_sysobj_t
> - unpriv_sepgsql_proc_exec_t
> - unpriv_sepgsql_blob_t
>
> These types are the default for unprivileged and unprefixed domains,
> such as httpd_t and others.
>
> In addition, TYPE_TRANSITION rules are moved to outside of tunable
> of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
> tunable because UBAC domains (user_t and so on) were allowed to
> create sepgsql_table_t, and its default was pointed to this type
> when sepgsql_enable_users_ddl is disabled.
> However, it has different meanings now, so the TYPE_TRANSITION rules
> should be unconditional.
Merged.
>
> Index: policy/modules/services/postgresql.if
> ===================================================================
> --- policy/modules/services/postgresql.if (revision 2982)
> +++ policy/modules/services/postgresql.if (working copy)
> @@ -47,18 +47,17 @@
>
> tunable_policy(`sepgsql_enable_users_ddl',`
> allow $2 user_sepgsql_table_t:db_table { create
> drop };
> - type_transition $2 sepgsql_database_type:db_table
> user_sepgsql_table_t;
> -
> allow $2 user_sepgsql_table_t:db_column { create
> drop };
> -
> allow $2 user_sepgsql_sysobj_t:db_tuple { update
> insert delete };
> - type_transition $2 sepgsql_sysobj_table_type:db_tuple
> user_sepgsql_sysobj_t;
> ')
>
> allow $2 user_sepgsql_table_t:db_table { getattr setattr use
> select update insert delete lock };
> allow $2 user_sepgsql_table_t:db_column { getattr setattr use
> select update insert };
> allow $2 user_sepgsql_table_t:db_tuple { use select update
> insert delete };
> + type_transition $2 sepgsql_database_type:db_table
> user_sepgsql_table_t;
> +
> allow $2 user_sepgsql_sysobj_t:db_tuple { use select };
> + type_transition $2 sepgsql_sysobj_table_type:db_tuple
> user_sepgsql_sysobj_t;
>
> allow $2 user_sepgsql_proc_exec_t:db_procedure { create drop
> getattr setattr execute };
> type_transition $2 sepgsql_database_type:db_procedure
> user_sepgsql_proc_exec_t;
> @@ -313,24 +312,55 @@
> #
> interface(`postgresql_unpriv_client',`
> gen_require(`
> + class db_database all_db_database_perms;
> class db_table all_db_table_perms;
> class db_procedure all_db_procedure_perms;
> + class db_column all_db_column_perms;
> + class db_tuple all_db_tuple_perms;
> class db_blob all_db_blob_perms;
>
> attribute sepgsql_client_type;
> + attribute sepgsql_database_type,
> sepgsql_sysobj_table_type;
>
> - type sepgsql_db_t, sepgsql_table_t,
> sepgsql_proc_exec_t, sepgsql_blob_t;
> type sepgsql_trusted_proc_t,
> sepgsql_trusted_proc_exec_t;
> + type unpriv_sepgsql_blob_t,
> unpriv_sepgsql_proc_exec_t;
> + type unpriv_sepgsql_sysobj_t, unpriv_sepgsql_table_t;
> ')
>
> + ########################################
> + #
> + # Declarations
> + #
> +
> typeattribute $1 sepgsql_client_type;
>
> - type_transition $1 sepgsql_db_t:db_table sepgsql_table_t;
> - type_transition $1 sepgsql_db_t:db_procedure
> sepgsql_proc_exec_t;
> - type_transition $1 sepgsql_db_t:db_blob sepgsql_blob_t;
> + ########################################
> + #
> + # Client local policy
> + #
>
> type_transition $1 sepgsql_trusted_proc_exec_t:process
> sepgsql_trusted_proc_t;
> allow $1 sepgsql_trusted_proc_t:process transition;
> +
> + tunable_policy(`sepgsql_enable_users_ddl',`
> + allow $1 unpriv_sepgsql_table_t:db_table { create drop
> setattr };
> + allow $1 unpriv_sepgsql_table_t:db_column { create
> drop setattr };
> + allow $1 unpriv_sepgsql_sysobj_t:db_tuple { update
> insert delete };
> + ')
> +
> + allow $1 unpriv_sepgsql_table_t:db_table { getattr use select
> update insert delete lock };
> + allow $1 unpriv_sepgsql_table_t:db_column { getattr use select
> update insert };
> + allow $1 unpriv_sepgsql_table_t:db_tuple { use select update
> insert delete };
> + type_transition $1 sepgsql_database_type:db_table
> unpriv_sepgsql_table_t;
> +
> + allow $1 unpriv_sepgsql_sysobj_t:db_tuple { use select };
> + type_transition $1 sepgsql_sysobj_table_type:db_tuple
> unpriv_sepgsql_sysobj_t;
> +
> + allow $1 unpriv_sepgsql_proc_exec_t:db_procedure { create drop
> getattr setattr execute };
> + type_transition $1 sepgsql_database_type:db_procedure
> unpriv_sepgsql_proc_exec_t;
> +
> + allow $1 unpriv_sepgsql_blob_t:db_blob { create drop getattr
> setattr read write };
> + type_transition $1 sepgsql_database_type:db_blob
> unpriv_sepgsql_blob_t;
> ')
>
> ########################################
> Index: policy/modules/services/postgresql.te
> ===================================================================
> --- policy/modules/services/postgresql.te (revision 2982)
> +++ policy/modules/services/postgresql.te (working copy)
> @@ -97,6 +97,20 @@
> postgresql_unconfined(sepgsql_trusted_proc_t)
> role system_r types sepgsql_trusted_proc_t;
>
> +# Types for unprivileged client
> +type unpriv_sepgsql_blob_t;
> +postgresql_blob_object(unpriv_sepgsql_blob_t)
> +
> +type unpriv_sepgsql_proc_exec_t;
> +postgresql_procedure_object(unpriv_sepgsql_proc_exec_t)
> +
> +type unpriv_sepgsql_sysobj_t;
> +postgresql_system_table_object(unpriv_sepgsql_sysobj_t)
> +
> +type unpriv_sepgsql_table_t;
> +postgresql_table_object(unpriv_sepgsql_table_t)
> +
> +# Types for UBAC
> type user_sepgsql_blob_t;
> typealias user_sepgsql_blob_t alias { staff_sepgsql_blob_t
> sysadm_sepgsql_blob_t };
> typealias user_sepgsql_blob_t alias { auditadm_sepgsql_blob_t
> secadm_sepgsql_blob_t };
>
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
On Fri, 2009-05-08 at 13:05 +0900, KaiGai Kohei wrote:
> The attached patch fixes incorrect behavior in
> sepgsql_enable_users_ddl.
>
> The current policy allows users/unprivs to run ALTER TABLE statement
> unconditionally, because db_table/db_column:{setattr} is allowed
> outside
> of the boolean. It should be moved to conditional section.
>
> In addition, they are also allowed to db_procedure:{create drop
> setattr}
> for xxxx_sepgsql_proc_exec_t, but it means we allows them to create,
> drop
> or alter definition of the functions unconditionally. So, it also
> should
> be moved to conditional section.
>
> The postgresql.te allows sepgsql_client_type to modify sepgsql_table_t
> and sepgsql_sysobj_t when sepgsql_enable_users_ddl is enabled, but
> it should not be allowed.
Merged. I fixed the user section which removed the unconditional
getattr instead of the unconditional setattr.
> KaiGai Kohei wrote:
> >>>>> - rework: All the newly created database objects by unprivileged
> >>>>> clients are prefixed with "user_", and these are controled via
> >>>>> sepgsql_enable_users_ddl.
> >>>> I don't think we should be mixing user content with other unpriv
> >>>> clients.
> >>> I would like to discriminate between a procedure declared by
> unpriv
> >>> client and by administrative client, because the policy allows the
> >>> unprefixed "sepgsql_proc_exec_t" to be installed as a system
> internal
> >>> component, but it is undesirable to install unpriv-user defined
> >>> procedures as is.
> >>>
> >>> If the "user_" prefix is unpreferable, how do you think other
> prefixes
> >>> something like "anon_", "unpriv_" and so on?
> >> I think we should go with unpriv_ for now.
> >
> > OK, the attached patch adds the following types for unprivileged
> clients.
> > - unpriv_sepgsql_table_t
> > - unpriv_sepgsql_sysobj_t
> > - unpriv_sepgsql_proc_exec_t
> > - unpriv_sepgsql_blob_t
> >
> > These types are the default for unprivileged and unprefixed domains,
> > such as httpd_t and others.
> >
> > In addition, TYPE_TRANSITION rules are moved to outside of tunable
> > of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
> > tunable because UBAC domains (user_t and so on) were allowed to
> > create sepgsql_table_t, and its default was pointed to this type
> > when sepgsql_enable_users_ddl is disabled.
> > However, it has different meanings now, so the TYPE_TRANSITION rules
> > should be unconditional.
> >
> > Thanks,
> --
> OSS Platform Development Division, NEC
> KaiGai Kohei <[email protected]>
>
>
>
>
>
>
>
> differences
> between files
> attachment
> (refpolicy-sepgsql-2-correct-sepgsql_enable_users_ddl.patch)
>
> --- policy/modules/services/postgresql.if 2009-05-08
> 12:32:51.000000000 +0900
> +++ policy/modules/services/postgresql.if.2 2009-05-08
> 11:58:46.000000000 +0900
> @@ -46,20 +46,21 @@
> #
>
> tunable_policy(`sepgsql_enable_users_ddl',`
> - allow $2 user_sepgsql_table_t:db_table { create
> drop };
> - allow $2 user_sepgsql_table_t:db_column { create
> drop };
> + allow $2 user_sepgsql_table_t:db_table { create drop
> setattr };
> + allow $2 user_sepgsql_table_t:db_column { create drop
> setattr };
> allow $2 user_sepgsql_sysobj_t:db_tuple { update
> insert delete };
> + allow $2 user_sepgsql_proc_exec_t:db_procedure
> { create drop setattr };
> ')
>
> - allow $2 user_sepgsql_table_t:db_table { getattr setattr use
> select update insert delete lock };
> - allow $2 user_sepgsql_table_t:db_column { getattr setattr use
> select update insert };
> + allow $2 user_sepgsql_table_t:db_table { setattr use select
> update insert delete lock };
> + allow $2 user_sepgsql_table_t:db_column { setattr use select
> update insert };
> allow $2 user_sepgsql_table_t:db_tuple { use select update
> insert delete };
> type_transition $2 sepgsql_database_type:db_table
> user_sepgsql_table_t;
>
> allow $2 user_sepgsql_sysobj_t:db_tuple { use select };
> type_transition $2 sepgsql_sysobj_table_type:db_tuple
> user_sepgsql_sysobj_t;
>
> - allow $2 user_sepgsql_proc_exec_t:db_procedure { create drop
> getattr setattr execute };
> + allow $2 user_sepgsql_proc_exec_t:db_procedure { getattr
> execute };
> type_transition $2 sepgsql_database_type:db_procedure
> user_sepgsql_proc_exec_t;
>
> allow $2 user_sepgsql_blob_t:db_blob { create drop getattr
> setattr read write };
> @@ -346,6 +347,7 @@
> allow $1 unpriv_sepgsql_table_t:db_table { create drop
> setattr };
> allow $1 unpriv_sepgsql_table_t:db_column { create
> drop setattr };
> allow $1 unpriv_sepgsql_sysobj_t:db_tuple { update
> insert delete };
> + allow $1 unpriv_sepgsql_proc_exec_t:db_procedure
> { create drop setattr };
> ')
>
> allow $1 unpriv_sepgsql_table_t:db_table { getattr use select
> update insert delete lock };
> @@ -356,7 +358,7 @@
> allow $1 unpriv_sepgsql_sysobj_t:db_tuple { use select };
> type_transition $1 sepgsql_sysobj_table_type:db_tuple
> unpriv_sepgsql_sysobj_t;
>
> - allow $1 unpriv_sepgsql_proc_exec_t:db_procedure { create drop
> getattr setattr execute };
> + allow $1 unpriv_sepgsql_proc_exec_t:db_procedure { getattr
> execute };
> type_transition $1 sepgsql_database_type:db_procedure
> unpriv_sepgsql_proc_exec_t;
>
> allow $1 unpriv_sepgsql_blob_t:db_blob { create drop getattr
> setattr read write };
> --- policy/modules/services/postgresql.te 2009-05-08
> 12:38:30.000000000 +0900
> +++ policy/modules/services/postgresql.te.2 2009-05-08
> 12:39:10.000000000 +0900
> @@ -338,12 +338,6 @@
> # Therefore, the following rule is applied for any domains which can
> connect SE-PostgreSQL.
> dontaudit { postgresql_t sepgsql_client_type
> sepgsql_unconfined_type } { sepgsql_table_type
> -sepgsql_sysobj_table_type }:db_tuple { use select update insert
> delete };
>
> -tunable_policy(`sepgsql_enable_users_ddl',`
> - allow sepgsql_client_type sepgsql_table_t:db_table { create
> drop setattr };
> - allow sepgsql_client_type sepgsql_table_t:db_column { create
> drop setattr };
> - allow sepgsql_client_type sepgsql_sysobj_t:db_tuple { update
> insert delete };
> -')
> -
> ########################################
> #
> # Unconfined access to this module
>
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
On Fri, 2009-05-08 at 13:12 +0900, KaiGai Kohei wrote:
> The attached patch allows unprivileged clients to export from or
> import
> to the largeobject owned by themselves.
>
> The current security policy does not allow them to import/export any
> largeobjects without any clear reason.
>
> NOTE: Export of the largeobject means that it dumps whole of the
> largeobject into a local file, so SE-PostgreSQL checks both of
> db_blob:{read export} on the largeobject and file:{write} on the
> local file. Import is a reversal behavior.
Merged.
> KaiGai Kohei wrote:
> >>>>> - rework: All the newly created database objects by unprivileged
> >>>>> clients are prefixed with "user_", and these are controled via
> >>>>> sepgsql_enable_users_ddl.
> >>>> I don't think we should be mixing user content with other unpriv
> >>>> clients.
> >>> I would like to discriminate between a procedure declared by
> unpriv
> >>> client and by administrative client, because the policy allows the
> >>> unprefixed "sepgsql_proc_exec_t" to be installed as a system
> internal
> >>> component, but it is undesirable to install unpriv-user defined
> >>> procedures as is.
> >>>
> >>> If the "user_" prefix is unpreferable, how do you think other
> prefixes
> >>> something like "anon_", "unpriv_" and so on?
> >> I think we should go with unpriv_ for now.
> >
> > OK, the attached patch adds the following types for unprivileged
> clients.
> > - unpriv_sepgsql_table_t
> > - unpriv_sepgsql_sysobj_t
> > - unpriv_sepgsql_proc_exec_t
> > - unpriv_sepgsql_blob_t
> >
> > These types are the default for unprivileged and unprefixed domains,
> > such as httpd_t and others.
> >
> > In addition, TYPE_TRANSITION rules are moved to outside of tunable
> > of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
> > tunable because UBAC domains (user_t and so on) were allowed to
> > create sepgsql_table_t, and its default was pointed to this type
> > when sepgsql_enable_users_ddl is disabled.
> > However, it has different meanings now, so the TYPE_TRANSITION rules
> > should be unconditional.
> >
>
>
>
>
>
>
> differences
> between files
> attachment
> (refpolicy-sepgsql-3-db_blob-import-export.patch)
>
> --- policy/modules/services/postgresql.if.2 2009-05-08 11:58:46.000000000 +0900
> +++ policy/modules/services/postgresql.if.3 2009-05-08 11:59:28.000000000 +0900
> @@ -63,7 +63,7 @@
> allow $2 user_sepgsql_proc_exec_t:db_procedure { getattr execute };
> type_transition $2 sepgsql_database_type:db_procedure user_sepgsql_proc_exec_t;
>
> - allow $2 user_sepgsql_blob_t:db_blob { create drop getattr setattr read write };
> + allow $2 user_sepgsql_blob_t:db_blob { create drop getattr setattr read write import export };
> type_transition $2 sepgsql_database_type:db_blob user_sepgsql_blob_t;
>
> allow $2 sepgsql_trusted_proc_t:process transition;
> @@ -361,7 +361,7 @@
> allow $1 unpriv_sepgsql_proc_exec_t:db_procedure { getattr execute };
> type_transition $1 sepgsql_database_type:db_procedure unpriv_sepgsql_proc_exec_t;
>
> - allow $1 unpriv_sepgsql_blob_t:db_blob { create drop getattr setattr read write };
> + allow $1 unpriv_sepgsql_blob_t:db_blob { create drop getattr setattr read write import export };
> type_transition $1 sepgsql_database_type:db_blob unpriv_sepgsql_blob_t;
> ')
>
>
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150