From: kaigai@kaigai.gr.jp (KaiGai Kohei) Date: Sun, 05 Apr 2009 09:52:39 +0900 Subject: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL In-Reply-To: <49D651A7.1000703@manicmethod.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> <49D651A7.1000703@manicmethod.com> Message-ID: <49D800D7.7060609@kaigai.gr.jp> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Joshua Brindle wrote: >> Again, I would like to get the reworks merged in this timing. >> (In addition, it also makes RUBIX happy on Fedora 11 or later.) >> > > Fedora 11 is already frozen, new object classes shouldn't be working their way > in to that, so we have a release cycle to adjust the permissions to match the > implementation, both on the upstream sepostgres side and the RUBIX side before > pushing those in to refpolicy. Hmm... It would seem that I need to provide a development purpose security policy package in the meanwhile. The next development cycle in PostgreSQL will be open soon: http://wiki.postgresql.org/wiki/CommitFest_2009-First I'll propose the newer design for the commit fest, but also continue to maintain the current design on Fedora as far as the security policy keeps existing object classes and permissions. I believe the current design should be switched to the newer one at some point in the future. In my hope, it should be done on Fedora 12. > Once some implementation starts and the security model settles it may be a > different story, I just don't think it is appropriate to merge them at this > point. (In particular I want to see if the new proposed object classes and perms > will really work for RUBIX, and I want to see how much of the patch the upstream > postgres project will take for the next release). I also would like Andy to report whether the RUBIX with newer design and security policy performs well, or not. The development purpose security policy which contains newer object classes and permissions will be available soon. > As it stands we are going to have 3 selinux aware databases floating around > using slightly different object classes and permissions, which is not ideal. Agreed. > Having all those in upstream refpolicy means it is harder to change them and the > unused permissions are going to sit there causing confusion (even worse, they'll > be unused by 2 of the 3 systems but still in use by the previous version of > sepostgres). I think the current design should be deprecated in the lifespan of distribution if the upstream refpolicy once gets newer design. In finally, I believe only 2 of the system can share the design. Thanks, -- KaiGai Kohei