From: kaigai@ak.jp.nec.com (KaiGai Kohei) Date: Tue, 21 Apr 2009 08:27:27 +0900 Subject: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL In-Reply-To: <1240258044.19211.767.camel@gorn.columbia.tresys.com> References: <49D1DA85.1030902@ak.jp.nec.com> <49D4743C.2010000@ak.jp.nec.com> <49D4CB6E.1090900@manicmethod.com> <1238684951.32379.311.camel@gorn.columbia.tresys.com> <49D563A9.1000607@ak.jp.nec.com> <49D965CA.4030908@ak.jp.nec.com> <1240258044.19211.767.camel@gorn.columbia.tresys.com> Message-ID: <49ED04DF.8050306@ak.jp.nec.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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