Re: [v9.1] sepgsql - userspace access vector cache

On 2011-07-18 22:21, Kohei KaiGai wrote:
> The Scientific Linux 6 is not suitable, because its libselinux version
> is a bit older
> than this patch expects (libselinux-2.0.99 or later).
> My recommendation is Fedora 15, instead.
Installing right now, thanks for the heads up!

>> /etc/selinux/targeted/contexts/sepgsql_contexts: line 33 has invalid object
>> type db_blobs
> It is not an error, but just a notification to inform users that
> sepgsql_contexts
> file contains invalid lines. It is harmless, so we can ignore them.
> I don't think sepgsql.sgml should mention about this noise, because it purely
> come from the problem in libselinux and refpolicy; these are external packages
> from viewpoint of PostgreSQL.
This is in contradiction with the current phrase in the documentation
that's right after the sepgsql.sql loading: "If the installation process
completes without error, you can now start the server normally". IMHO if
there are warnings that can be ignored, it would limit confusion for
sepgsql users if the documentation would say it at this point, e.g. "If
the installation process completes without error, you can now start the
server normally. Warnings from errors in sepgsql_contexts, a file
external to PostgreSQL, are harmless and can be ignored."

> The point of this patch is replacement of existing mechanism<...>
> So, it is not necessary to define a new policy for testing.
Thanks for elaborating on this.
> The security label is something like user-id or ownership/object-acl in the
> default database access controls. It checks a relationship between user-id
> and ownership/object-acl of the target object. If this relationship allowed
> particular actions like 'select', 'update' or others, it shall be allowed when
> user requires these actions.
> In similar way, 'db_table:select' is a type of action; 'select' on table object,
> not an identifier of user or objects.
> SELinux defines a set of allowed actions (such as 'db_table:select') between
> a particular pair of security labels (such as 'staff_t' and 'sepgsql_table_t').
> The pg_seclabel holds only security label of object being referenced.
> So, you should see /selinux/class/db_*/perms to see list of permissions
> defined in the security policy (but limited number of them are in use, now).
> The system's default security policy (selinux-policy package) defines all the
> necessary labeles, and access control rules between them.
> So, we never need to modify security policy to run regression test.
>
> The sepgsql_trusted_proc_exec_t means that functions labeled with this label
> is a trusted procedure. It switches security label of the user during
> execution of
> this function. It is a similar mechanism like SetExec or security
> definer function.
>
> The sepgsql_ro_table_t means 'read-only' tables that disallow any
> writer operations
> except for administrative domains.
> You can define your own policy, however, I intend to run regression test
> without any modification of the default security policy.

Thank you for this clarification. I have some ideas of things that if
they were in the documentation they'd helped me. Instead of seeking
agreement on each item, I propose that I gather documentation additions
in a patch later after the review, and leave it up to you guys whether
to include them or not.

regards,
Yeb
--

Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data