Re: The status of SE-PostgreSQL

[Andy Warner <warner@rubix.com>]

[-- Attachment #1: Type: text/plain, Size: 4034 bytes --]

Just a thought from working with the DBMS functionality within the
SELinux policy. Has there been any thought or talks about adding support
for catalog or schema objects? When I integrated the SELinux policy into
our DBMS I found them lacking and ended up using the dir object class,
as that closely mimicked our use of catalogs and schemata.

Andy

KaiGai Kohei wrote:
> Here is a bad news.
>
> I've had a discussion in pgsql-hackers list for a long time, but
> we cannot get a conclusion that SE-PostgreSQL should be merged
> in the PostgreSQL v8.4 which is the next major release, and it
> was postponed to the v8.5 development cycle due to lack of time
> for enough reviewing the feature.
>
> If it can be released on schedule, the v8.4 is released on the
> second quarter of 2009, and the v8.5 will be relased on a year
> later (but it tend to delay a few months).
> So, it is necessary to apply SE-PostgreSQL patches or install
> it from RPM package distributed via Fedora project. :(
>
> Under the discussion, I got a few suggestions in its security
> design, and it seems to me fair enough. Some of them needs to
> change definitions in the default policy.
>
> See the following items,
>
> * new permission: db_database:{superuser}
>
> They required a new permission to control database superuser
> privileges similar to "root" capability in operating system.
> The concept of superuser is common for some of major DBMSs,
> not only PostgreSQL. In addition, it seems to me well symmetric
> with operating system.
>
> The db_database:{superuser} controls whether the client can
> perform as database superuser on the given database, or not.
>
> * undesired permission: db_database:{set_param get_param}
>
> They wondered the necessity of these checks, because SQL spec
> does not require checks in set/get database parameters.
> I didn't think it is necessary the security design of SELinux
> should be symmetric with SQL, but I also thought these might
> be unnecessary due to another reason.
> In PostgreSQL, the scope of database parameters are session
> local and initialized on the connection startup, so we cannot
> use it as a pass to communicate between different two or more
> domains.
>
> * undesired permission: db_table/db_column/db_tuple:{use}
>
> I originally proposed the {use} permission to set up write-only
> tables, but it might be a misdesign.
> (Sorry, a bit long description.)
>
> At the initial design, SE-PostgreSQL applied {select} permission
> for all the refered tables, columns and tuples. But, it also means
> {select} permission is necessary for conditional DELETE or UPDATE
> even if its content is not exposed to the client.
> So, I proposed the privilege into two different permission: {select}
> and {use}. The {select} allows the client to refer the object and
> its content can be returned to him. The {use} also allows the client
> to refer the object but its content has to be consumed internally.
>
>   Example)
>     SELECT a, b FROM t WHERE c = 5;
>   In this case, we need {select} on column t.a and t.b, but {use}
>   is required on column t.c because its content is consumed by
>   SE-PostgreSQL itself and not returned to the client.
>
>   Example)
>     UPDATE t SET x = 20 WHERE y = 'aaa';
>   In this case, we need {update} on column t.x, and {use} on t.y,
>   but {select} is not necessary.
>
> However, we can break it rapidly with a clever condition clause.
> For example, we can get a result from the first trial:
>   DELETE FROM account WHERE userid = 100 and creditno like '1%';
>
> If this query removes a tuple, it means the first character of
> credit card number is '1'. If not so, he can try it 9 times.
> Then, he can get the information without {select} permission,
> with enough small number of trials.
>
> They concluded the "{use}" permission cannot work correctly, and
> danger to expect it does not allow to leak contexnt to the outside.
> I can agree this opinion.
>
>
> The attached patch add/remove these permissions.
> Any comments please.
>
> Thanks,
>   

[-- Attachment #2: Type: text/html, Size: 4240 bytes --]