Re: [HACKERS] SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))
KaiGai Kohei wrote: Robert Haas wrote: 2009/10/27 KaiGai Kohei kai...@ak.jp.nec.com: - no statement support to specify security context. (It makes impossible to add support in pg_dump. Is it really OK?) I doubt that anything without pg_dump support would be even vaguely OK... In my previous experience, it enabled to reduce 300-400 lines of the patch. But here is no more sense than the 300-400 lines. In my honest, I like to include a feature to specify an explicit security context in the patch from the begining. (It also allows to attach test cases with more variations.) Can you explain why that's required for pg_dump support? I was thinking that there would be no explicit security labels on objects, and permissions would be checked based on other inherent properties of the object, like owner, name, schema etc. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))
Heikki Linnakangas wrote: KaiGai Kohei wrote: Robert Haas wrote: 2009/10/27 KaiGai Kohei kai...@ak.jp.nec.com: - no statement support to specify security context. (It makes impossible to add support in pg_dump. Is it really OK?) I doubt that anything without pg_dump support would be even vaguely OK... In my previous experience, it enabled to reduce 300-400 lines of the patch. But here is no more sense than the 300-400 lines. In my honest, I like to include a feature to specify an explicit security context in the patch from the begining. (It also allows to attach test cases with more variations.) Can you explain why that's required for pg_dump support? I was thinking that there would be no explicit security labels on objects, and permissions would be checked based on other inherent properties of the object, like owner, name, schema etc. In SELinux model, security context is the only property which can be used to decision making based on the security policy. It never uses any other properties, like owner, name, ... There are two cases when we create a new object. 1) create a new object without any explicit security context. If we don't have statement support, it is the only case. In this case, SELinux computes a default security context to be assigned on the new object. It depends on the client's security context. Then, it checks create permission on a pair of the client's security context and the default security context. If not allowed, an error will be raised. 2) create a new object with an explicit security context. In this case, the given explicit security context will be assigned. SELinux checks create permission on a pair of the client's security context and the given explicit security context. If not allowed, an error will be raised. Please note that SELinux assigns a security context on the managed object in either cases. If we don't have any statement support, there are no way to specify an explicit security context on the new object in creation. It also means we cannot recover the security context of objects correctly. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))
KaiGai Kohei wrote: Heikki Linnakangas wrote: KaiGai Kohei wrote: Robert Haas wrote: 2009/10/27 KaiGai Kohei kai...@ak.jp.nec.com: - no statement support to specify security context. (It makes impossible to add support in pg_dump. Is it really OK?) I doubt that anything without pg_dump support would be even vaguely OK... In my previous experience, it enabled to reduce 300-400 lines of the patch. But here is no more sense than the 300-400 lines. In my honest, I like to include a feature to specify an explicit security context in the patch from the begining. (It also allows to attach test cases with more variations.) Can you explain why that's required for pg_dump support? I was thinking that there would be no explicit security labels on objects, and permissions would be checked based on other inherent properties of the object, like owner, name, schema etc. In SELinux model, security context is the only property which can be used to decision making based on the security policy. It never uses any other properties, like owner, name, ... The security context doesn't necessary need to be given explicitly. Things like network ports, files in filesystems that don't support security labels are assigned a security context based on some external policy. Hmm, I guess the whole feature becomes completely pointless if all objects always have their default labels, and can't be changed. So I guess we need that. I think this discussion started when I wondered why we can't put the SE-pgsql check for creating an object (e.g table) into pg_namespace_aclcheck() without changing the signature. The reason you gave is that we need the security context of the new table being created to decide if creating such a table is allowed. But assuming that the new table inherits the security context of the schema it's created in, pg_namespace_aclcheck() *does* have all the necessary information: it knows the namespace which determines the new object's security context. As long as we don't provide syntax to define the security context in the CREATE command, we're fine, even if there's an ALTER command to change the security context of the object after the creation. I'm not sure how much of a difference that detail makes in the big scheme of things, I'm just trying to find ways to make the patch minimally invasive.. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))
Heikki Linnakangas wrote: KaiGai Kohei wrote: Heikki Linnakangas wrote: KaiGai Kohei wrote: Robert Haas wrote: 2009/10/27 KaiGai Kohei kai...@ak.jp.nec.com: - no statement support to specify security context. (It makes impossible to add support in pg_dump. Is it really OK?) I doubt that anything without pg_dump support would be even vaguely OK... In my previous experience, it enabled to reduce 300-400 lines of the patch. But here is no more sense than the 300-400 lines. In my honest, I like to include a feature to specify an explicit security context in the patch from the begining. (It also allows to attach test cases with more variations.) Can you explain why that's required for pg_dump support? I was thinking that there would be no explicit security labels on objects, and permissions would be checked based on other inherent properties of the object, like owner, name, schema etc. In SELinux model, security context is the only property which can be used to decision making based on the security policy. It never uses any other properties, like owner, name, ... The security context doesn't necessary need to be given explicitly. Things like network ports, files in filesystems that don't support security labels are assigned a security context based on some external policy. Hmm, I guess the whole feature becomes completely pointless if all objects always have their default labels, and can't be changed. So I guess we need that. I think this discussion started when I wondered why we can't put the SE-pgsql check for creating an object (e.g table) into pg_namespace_aclcheck() without changing the signature. The reason you gave is that we need the security context of the new table being created to decide if creating such a table is allowed. But assuming that the new table inherits the security context of the schema it's created in, pg_namespace_aclcheck() *does* have all the necessary information: it knows the namespace which determines the new object's security context. As long as we don't provide syntax to define the security context in the CREATE command, we're fine, even if there's an ALTER command to change the security context of the object after the creation. What I pointed out is just a part of matters if we try to deploy SE-PgSQL hooks within aclchk.c routines. For example, pg_namespace_aclcheck() with ACL_CREATE is not only invoked just before creation of a new table. It is also called when we create a new function, type, conversion and so on. For example, pg_namespace_aclcheck() does not take an argument to deliver the column definitions of new table. When columns are inherited from the parent table, we have to copy the security context of the parent column, but we can know the column's definition inside of the pg_namespace_aclcheck(). (It needs to be called after MergeAttributes(), but pg_namespace_aclcheck() is called before that.) For example, SE-PgSQL model distinguish setattr permission from drop. But pg_class_ownercheck() is used for both ALTER and DROP statement. So, we cannot know which permission should be applied inside from the pg_class_ownercheck(). For example, ... At the first commit fest, I was suggested to change definitions of the default PG access control routines to deliver needed information for both DAC and MAC, if pg_xxx_aclcheck() is not suitable for SELinux model. Then, I developed a junk in the result. :( I'm not sure how much of a difference that detail makes in the big scheme of things, I'm just trying to find ways to make the patch minimally invasive.. Basically, I don't think we should change something pg_xxx_aclcheck() and pg_xxx_ownercheck() routines, because it well implements the default PG model. If we try to call DAC and MAC from the common entry points, it requires us many of pain, as we could learn from our hard experience. What I would like to suggest is to put MAC hook on the strategic points. The hooks are just invocations of sepgsql_*() functions, so does not need much of reworks on the core routines. I believe this is the minimally invasive way. Linux kernel is one of the best practice. It deploys hooks to call MAC checks with needed information (such as inode, task_struct, ...) on the strategic points of the kernel. Basically, DAC and MAC works orthogonally, so it is quite natural design. Its specifications are documented in the source code clearly, so folks without special attentions for security also can know what information should be given and what result will be returned. What I would like to suggest is a similar approach. So, now I'm working to write a documentation from the viewpoint of developer, and coding SE-PgSQL routines with comments about its specifications. 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
Re: [HACKERS] SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))
KaiGai Kohei escribió: There are two cases when we create a new object. 1) create a new object without any explicit security context. If we don't have statement support, it is the only case. In this case, SELinux computes a default security context to be assigned on the new object. It depends on the client's security context. Then, it checks create permission on a pair of the client's security context and the default security context. If not allowed, an error will be raised. So, following this path, it is possible to write pg_dump support without a explicit security contexts: you have to make pg_dump write out the different tuples under different users. So you'd have more than one data object in the dump output for each table, one for every existing security context. This seems extremely difficult and intrusive however. It seems that having explicit security contexts in statements is necessary for this area to be reasonably simple. Now, let's assume that COPY data includes the security context for each tuple in the output. How is that data restored? Would you need to grant super-SEPostgres privileges to the user restoring the data? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))
Alvaro Herrera wrote: KaiGai Kohei escribió: There are two cases when we create a new object. 1) create a new object without any explicit security context. If we don't have statement support, it is the only case. In this case, SELinux computes a default security context to be assigned on the new object. It depends on the client's security context. Then, it checks create permission on a pair of the client's security context and the default security context. If not allowed, an error will be raised. So, following this path, it is possible to write pg_dump support without a explicit security contexts: you have to make pg_dump write out the different tuples under different users. So you'd have more than one data object in the dump output for each table, one for every existing security context. This seems extremely difficult and intrusive however. It seems that having explicit security contexts in statements is necessary for this area to be reasonably simple. Yes, it may be possible to restore the tables without statement, if we switch OS-user's privilege for each tables, but unreasonable and unrealistic. Now, let's assume that COPY data includes the security context for each tuple in the output. When we support row-level security, it will be necessary to backup and restore the security context for each tuples. What I'm talking about is how we specify the security context of the new tables. If we can have statement support, it will be specified as follows: CREATE TABLE t ( a int primary key, b text) SECURITY_CONTEXT = 'system_u:object_r:sepgsql_ro_table_t:unclassified'; How is that data restored? Would you need to grant super-SEPostgres privileges to the user restoring the data? We need to restore the backup by the user who has privileges to create database objects dumped at least. But no needs to have super-privilege. For example, if all the dumped table are labeled as either unclassified or classified but not secret, all the needed privilege is to create unclassified and classified tables, not secret table. However, I expect that unconfined domain does the backup/restore works expect for especially secure system. I don't think the default security policy (such as ones bundled with Fedora) should restrict DBA's privileges connected from the shell process. 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
Re: [HACKERS] SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))
KaiGai Kohei escribió: Alvaro Herrera wrote: Now, let's assume that COPY data includes the security context for each tuple in the output. When we support row-level security, it will be necessary to backup and restore the security context for each tuples. Oh, right, that part is being left out. Sorry. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))
Now I'm working on writing a documentation from the viewpoint of developers as follows (It is a work in progress): http://code.google.com/p/sepgsql/source/browse/trunk/sepgsql/src/backend/security/sepgsql/README Is there any differences between what I want to describe and what you want to know? If so, I'll add or modify the documentation. As I noted before, I decided to slim up my patch on the next commit fest to reduce the burden of reviewing. The following functionalities will be separated from the prior version. - no access controls on procedures. - so, the slim version only support checks on databases, schemas, tables and columns. - no statement support to specify security context. (It makes impossible to add support in pg_dump. Is it really OK?) - no userspace caches for access control decision - no system catalog changes to store its security context - I'll adopt an approach that Stephen Frost suggested before. It manages a pair of OID and security context in separated system catalog. Is there any comment? Or, more detailed introductions are necessary? Thanks, KaiGai Kohei wrote: KaiGai Kohei wrote: After the long trial-and-errors, we learned a few approaches which use common entry points for both of DAC and MAC were rocky-path more than what we initially imagined. So, we came back to the original design. It deploys MAC hooks on the strategic points of core routines. On the other hand, people complained about this approach without clear documentation, because most of people are not familiar to both of SELinux and PgSQL. Heikki suggested that a clear developer documentation should be provided to understand pgsql-hackers this new concept. (And, Peter has also suggested before a developer documentation will be a good source of user documentations.) I plan to submit SE-PgSQL/lite patch with developer documentations on the next commit-fest. I can understand what I want to develop and the purpose of codes. However, it may not match with what you want to know. So, I'd like to ask what should be included within the developer documentation at first prior to making a documentation. I plans the developer documentation should be put as a REAME file, not a SGML documentation or a certain wiki page. And I think it should contain the following items. * overview - general overview of SE-PgSQL - introduction of SELinux specific terms (such as security context) * internal architecture - the purpose of sub-components (such as management of security context, caches of access control decision and so on) - differences from similar permissions in DAC * object classes and permissions defined in SELinux model - list of them and when/where they should be checked. * specification of SE-PgSQL hooks (It should be put on the source code comments for easy maintenance.) - what this hook does, what arguments are required, what result will be returned. * code examples - a few examples to add MAC checks within 3rd party modules. Do you have any comments? What should be added to? or removed from? I guess it was too abstract to suggest anything. Anyway, I'll begin to describe the developer documentation base on the chapters. If necessary, we can fix it up later. In addition, I determined the initial patch only covers access controls on the four object classes (database, schema, table and column) to reduce burdens of reviewing. We also can add support for other object classes (such as procedure) later. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))
2009/10/27 KaiGai Kohei kai...@ak.jp.nec.com: - no statement support to specify security context. (It makes impossible to add support in pg_dump. Is it really OK?) I doubt that anything without pg_dump support would be even vaguely OK... ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))
Robert Haas wrote: 2009/10/27 KaiGai Kohei kai...@ak.jp.nec.com: - no statement support to specify security context. (It makes impossible to add support in pg_dump. Is it really OK?) I doubt that anything without pg_dump support would be even vaguely OK... In my previous experience, it enabled to reduce 300-400 lines of the patch. But here is no more sense than the 300-400 lines. In my honest, I like to include a feature to specify an explicit security context in the patch from the begining. (It also allows to attach test cases with more variations.) -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))
KaiGai Kohei wrote: After the long trial-and-errors, we learned a few approaches which use common entry points for both of DAC and MAC were rocky-path more than what we initially imagined. So, we came back to the original design. It deploys MAC hooks on the strategic points of core routines. On the other hand, people complained about this approach without clear documentation, because most of people are not familiar to both of SELinux and PgSQL. Heikki suggested that a clear developer documentation should be provided to understand pgsql-hackers this new concept. (And, Peter has also suggested before a developer documentation will be a good source of user documentations.) I plan to submit SE-PgSQL/lite patch with developer documentations on the next commit-fest. I can understand what I want to develop and the purpose of codes. However, it may not match with what you want to know. So, I'd like to ask what should be included within the developer documentation at first prior to making a documentation. I plans the developer documentation should be put as a REAME file, not a SGML documentation or a certain wiki page. And I think it should contain the following items. * overview - general overview of SE-PgSQL - introduction of SELinux specific terms (such as security context) * internal architecture - the purpose of sub-components (such as management of security context, caches of access control decision and so on) - differences from similar permissions in DAC * object classes and permissions defined in SELinux model - list of them and when/where they should be checked. * specification of SE-PgSQL hooks (It should be put on the source code comments for easy maintenance.) - what this hook does, what arguments are required, what result will be returned. * code examples - a few examples to add MAC checks within 3rd party modules. Do you have any comments? What should be added to? or removed from? I guess it was too abstract to suggest anything. Anyway, I'll begin to describe the developer documentation base on the chapters. If necessary, we can fix it up later. In addition, I determined the initial patch only covers access controls on the four object classes (database, schema, table and column) to reduce burdens of reviewing. We also can add support for other object classes (such as procedure) later. 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
