From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from jazzdrum.ncsc.mil (zombie.ncsc.mil [144.51.88.131]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with SMTP id l28EYGf2004199 for ; Thu, 8 Mar 2007 09:34:16 -0500 Received: from nz-out-0506.google.com (jazzdrum.ncsc.mil [144.51.5.7]) by jazzdrum.ncsc.mil (8.12.10/8.12.10) with ESMTP id l28EYFHa004660 for ; Thu, 8 Mar 2007 14:34:15 GMT Received: by nz-out-0506.google.com with SMTP id z3so325990nzf for ; Thu, 08 Mar 2007 06:34:13 -0800 (PST) Message-ID: <45F01EDB.6050507@kaigai.gr.jp> Date: Thu, 08 Mar 2007 23:34:03 +0900 From: KaiGai Kohei MIME-Version: 1.0 To: Stephen Smalley CC: Joshua Brindle , casey@schaufler-ca.com, russell@coker.com.au, selinux@tycho.nsa.gov, "Christopher J. PeBenito" Subject: Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release References: <989281.84407.qm@web36612.mail.mud.yahoo.com> <45EEE1C1.4070804@tresys.com> <45F00BA8.6090107@kaigai.gr.jp> <1173360342.10467.25.camel@moss-spartans.epoch.ncsc.mil> In-Reply-To: <1173360342.10467.25.camel@moss-spartans.epoch.ncsc.mil> Content-Type: text/plain; charset=ISO-2022-JP Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov Stephen Smalley wrote: > On Thu, 2007-03-08 at 22:12 +0900, KaiGai Kohei wrote: >> Joshua Brindle wrote: >>> Casey Schaufler wrote: >>>> --- KaiGai Kohei wrote: >>>> >>>> >>>> >>>>> I think unique identification for all tuples are >>>>> difficult, because we can >>>>> create a table without Oid (object id) or primary >>>>> key to identify a tuple >>>>> from outside of the table... >>>>> >>>>> BTW, the string representations of security contexts >>>>> are stored in a separate >>>>> table named as 'pg_selinux', defined with Oid (which >>>>> have 4-byte length). >>>>> In SE-PostgreSQL, any tuples have Oid of pg_selinux >>>>> as a security context. >>>>> Thus, storage consumption is limited. >>>>> >>>> How does this method compare to the schemes >>>> used in the Oracle evaluated MLS DBMS? >>>> >>>> >>> IIRC Oracle basically has polyinstanciated tables (using views) to >>> implement MLS, which gives far less granularity and doesn't allow for >>> labeled rows or columns. KaiGai's work leverages all the security models >>> SELinux can use to allow for flexible policies. The technical decision >>> to use another table to store the oid of the context seems appropriate, >>> since that is how rdbms's operate in general. >> I think the biggest difference is whether RDBMS utilizes the security >> functionalities of operating system, or not. >> >> For example, SE-PostgreSQL obtains the security context of the client via >> getpeercon(), and makes a decision with the security policy. >> It enables to ensure a process with lower clearance cannot access secret >> data, even if it is stored in database. > > You also should be leveraging the OS in protecting SE-PostgreSQL from > interference by the client and ensuring that it is unbypassable for > accessing the database. Are you just using the stock postgresql domain > in the refpolicy at present? Any analysis of that domain and whether it > meets your needs adequately? (side bar: it seems to have a lot of > capabilities presently) The security policy included in sepostgresql rpm package uses stock postgresql_t domin in the refpolicy, almost as is. I have not analyzed them yet. Indeed, we should pay more attention for accessing the database files directly. Thanks, -- KaiGai Kohei -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.