(2009/12/12 15:42), "Ing . Marcos Lui's Orti'z Valmaseda" wrote: > KaiGai Kohei escribio': >> Stephen Frost wrote: >> >>> Josh, >>> >>> * Joshua Brindle (met...@manicmethod.com) wrote: >>> >>>> Stephen Frost wrote: >>>> >>>>> I do think that, technically, there's no reason we couldn't allow for >>>>> multiple "only-more-restrictive" models to be enabled and built in a >>>>> single binary for systems which support it. As such, I would make those >>>>> just "#if defined()" rather than "#elif". Let it be decided at runtime >>>>> which are actually used, otherwise it becomes a much bigger problem for >>>>> packagers too. >>>>> >>>> It isn't just a case of using #if and it magically working. You'd need a >>>> system to manage multiple labels on each object that can be addressed by >>>> different systems. So instead of having an object mapped only to >>>> "system_u:object_r:mydb_t:s15" you'd also have to have it mapped to, >>>> eg., "^" for Smack. >>>> >>> I'm not sure I see that being a problem.. We're going to have >>> references in our object managers which make sense to us (eg: table >>> OIDs) and then a way of mapping those to some label (or possibly a set >>> of labels, as you describe). We might want to reconsider the catalog >>> structure a bit if we want to support more than one at a time, but I >>> don't see it as a huge problem to support more than one label existing >>> for a given object. >>> >> >> If we allow multiple security labels on a database object, we have to >> expand the structure of system catalog whenever a new security feature >> will come in. I think it against to the purpose of the framework. >> >> Even if we store them external relations to reference the object by OID, >> we have to provide multiple interface to import/export a security label >> for each enhanced securities. For example, it requires much complex patch >> to the pg_dump. >> >> My preference is all the enhanced securities shares a common facility >> to manage security label, a common statement support and a common >> backup/restore support. >> >> Thanks, >> > I'm worried with the performance implications that have this patch on > the core of the system. > If you are aggregating more security layers, There is not a database > degradation? I don't know how you attack these issues. > Regards.
If you don't enable any enhanced security providers, the cost to make access control decision is much the same with existing permission checks, because it just applies same checks. If you enable an enhanced security providers (such as SELinux), here is a trade-off between additional restriction and maximum performance. In my past measurement, SE-PostgreSQL with full functionalities had 2-4% of performance trade-off in pgbench test. (Note that it also enables row-level checks in my local branch.) See the page.16 of this slides: http://sepgsql.googlecode.com/files/JLS2009-KaiGai-LAPP_SELinux.pdf We assume the user of SE-PgSQL gives security the first priority, so it will be enough acceptable penalty. Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
