Re: 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 <kaigai(at)ak(dot)jp(dot)nec(dot)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 <kaigai(at)kaigai(dot)gr(dot)jp>