Re: Adding support for SE-Linux security - Mailing list pgsql-hackers
From | KaiGai Kohei |
---|---|
Subject | Re: Adding support for SE-Linux security |
Date | |
Msg-id | 4B21DDA5.80002@ak.jp.nec.com Whole thread Raw |
In response to | Re: Adding support for SE-Linux security (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: Adding support for SE-Linux security
(Robert Haas <robertmhaas@gmail.com>)
|
List | pgsql-hackers |
Robert Haas wrote: > On Thu, Dec 10, 2009 at 11:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> If you're not prepared to assume that we're going to do row level >> security, it's not apparent why we should be embarking on this course >> at all. And if you do assume that, I strongly believe that my effort >> estimate above is on the optimistic side. > > Row-level security is going to be a very difficult project, no > question about it. Yes, I also agree it is a reasonable decision to separate row-level from the initial proposition. > However, if we implement a general facility rather > than something SE-Linux specific, I think we will have a killer > feature. I realize it's not for everyone, but for those who need it, > it's kick-ass. > > But we have a while before we get to the point where we can even start > worrying about that pain. Stephen Frost's statements about the way > our access controls are scattered throughout our code are, I think, on > target. And cleaning that up seems to me to have value independently > of SE-PostgreSQL. I'm feeling (right now, anyway) like it would make > sense to pursue further the patch that KaiGai submitted for the last > CF and you rejected. It needed work, but I don't think it was > hopeless, or valueless. Here is a few issues to salvage the access control reworks patch. It tried to provide a set of common entry points both of the default PG security model and SELinux (and upcoming ones). However, the default PG model does not have same origin with label-based mandatory access controls, such as SELinux, from a historical angle. So, this reworks needed many of unobvious changes to the core routines. ("core routines" means code except for enhanced security features.) It tried to provide a set of comprehensive entry points to replace existing PG checks at once. However, the SE-PgSQL/Lite patch covers accesses on only database, schema, tables and columns. Is it necessary to be comprehensive from the beginning? It might be too aggressive changes at once. Frankly, I hesitate to salvage the patch once rejected, as is. If we implement a set of security hooks, It seems to me the following approach is reasonable: * It does not touch the existing PG default checks. The purpose of security hooks are to host "enhanced" security features. * It does not deploy hooks on which no security provider is now proposed. It is important to reduce unnecessary changeset. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
pgsql-hackers by date: