Re: [PATCH] SE-PgSQL/tiny rev.2193

Robert Haas wrote:
> 2009/7/20 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> Robert Haas wrote:
>>> - row-level security
>>> - complex DDL permissions
>> Is the complex DDL permissions mean something like db_xxx:{create},
>> db_xxx:{relabelfrom relabelto} and others?
>> If so, I can agree to implement these checks at the later patch.
>>
>> However, please note that the initial patch cannot achieve actual
>> security in this case, because it means anyone can change security
>> label of objects.
>
> I'm not qualified to answer this question, and that's exactly why we
> need more documentation of what this patch tries to do and why (i.e. a
> spec).

Agreed,

> What I was specifically referring to is things like
> db_column:{drop}, which are much more specific than anything
> PostgreSQL currently offers to control DDL. I think we should make an
> attempt to get objects labelled in a reasonable way (I did not like
> the approach your latest patch took of just assigning everything a
> default label), which might include relabelling also, but certainly
> doesn't include things like distinguishing between different kinds of
> DDL operations. I'm not really up on SELinux terminology (this is
> another thing that needs to be covered in the documentation, and
> isn't) but maybe something like db_table:{owner}.

It also should be described in the documentation again...

The current design reflects a fundamental principle in SELinux.
It requires how objects are labeled and what permission should
be checked on the creation/deletion time.

It seems to me you misunderstand the default security context is
uniform for all the clients, but it's incorrect.
The default security context depends on client's security context
and parent object's security context (if exists).
For example, when a user with "classified" security context creates
a table under the regular schema, the new table will be also labeled
as "classified" to prevent accesses from "unclassified" users.

All the object classes that we can create or delete (such as files,
sockets, ipc objects, x-windows, ...) have their permissions to be
checked on creation or deletion time. These permissions are defined
on the relationship between user's security context and object's
security context. If only database objects ignore the design, it
breaks consistency in the security policy.

Again, the fact I needed to introduce such a fundamental design in
SELinux shows the current documents are poor for native English
users and database experts but not for security.

>>> I also agree with Peter's contention that a spec would be useful. If
>>> you could read a clear description of what the patch was going to do,
>>> then you could separate the problem of figuring out whether that was
>>> the right thing from the question of whether the patch actually did
>>> it.
>> I can also agree with the suggestion.
>> The specifications (from viewpoint of the developer) will introduces
>> the fundamental principles to be implemented, and it will figure out
>> what implementation is better.
>>
>> As I noted before, I've been flexible about how SE-PgSQL is implemented
>> as far as it can perform SELinux's security model correctly.
>>
>> Please for a several days. I'll describe it.
>
> I really, really think you need to find someone to help you with the
> documentation. As I've said before, your English is a lot better than
> my Japanese, but the current documentation is just hard to read. More
> than that, writing good documentation is HARD, and there are not a ton
> of people who can do it well. It seems to me that the documentation
> for this project could require as much work as the actual code.

Agreed,
If possible, I would like to know what is the easy-understandable
documentation from the viewpoint of non-security-experts also.

> What I want for documentation of this feature is something like the
> "Database Roles and Privileges" chapter of the current documentation.
> You can read this chapter from beginning to end and have a pretty good
> idea how to manage permissions in PostgreSQL. SE-Linux is complex
> enough that you might have to refer to other sources of information
> for certain topics (e.g. policy writing), because a full overview of
> those topics might exceed the scope of our documentation. But it
> should still be possible to start knowing nothing, read the chapter,
> and have a pretty good idea how all the pieces fit together, at least
> as far as PostgreSQL is concerned.

Indeed, I've learned before it is a good composition of documentations
to compare similar two different features (one is well-known, the other
is new) to introduce a new concept.

Here is one idea. I'll upload the draft of the documentation on the
wikipage shorter than the current one.
Is somebody available to check it from the viewpoint of native English
user or database users?

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>