Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)

Peter, thanks for your comments.

> Let's review:
>
> *) System-wide consistency in access controls could be nice to have in
> some cases. But is it really achievable? In the typical three-tier web
> application scenario, do you really have system-wide consistency? Can
> you configure your application server using SELinux? I'm no expert on
> these things, but I wonder, would it even work in a useful way, over the
> network, with all the different threads, processes, and sessions going
> on? Or how about a desktop, pgAdmin with several database connections,
> can those be isolated from each other or whatever the security setup may
> be?

It's a good question. Yes, it is possible no need to say. :)

We can configure Apache to kick its contents handler with a proper security
context. The contents handler is a sort of Apache module to handle various
kind of web contents like *.html, *.php, *.cgi and so on.
The existing module (mod_selinux) eanbles to invoke CGI program with a proper
security context based on HTTP authentication. In addition, the upcoming
Linux kernel got a feature to assign built-in scripts its security context.

SELinux applied its access controls based on the assigned security context
for various kind of objects like files, sockets, IPCs, tables, columns and
so on.

I can provide a demonstration, pelase wait for a while to set up.

- For overing networks,
The current SELinux provides the Labeled Networking feature. It enables to
deliver a peer's security context to other peer side. We can fetch delivered
one with getpeercon() API. SE-PostgreSQL also uses this API to obtain the
security context of client process.
(*) Note that SE-PostgreSQL does not depend on Database authentication.

- For different threads,
The upcoming Linux kernel got a feature to assign individual security context
for a thread with a constraint to prevent information boundary violation.
http://marc.info/?l=selinux&m=121992782231903

- For sessions,
We can set a proper security context using session variable before invoking
web applications, in same way as I noted above.
However, I've not provide an implementation yet.

> And is SELinux really the desirable interface for a system-wide access
> control facility? Why not port chmod or POSIX ACLs to PostgreSQL, or
> port SQL roles back to the operating system, or something else that
> captures what more people are actually using in practice.

Yes, SELinux is one of the suitable facilities.

It enables to describe its security policy using abstracted attributes
called as "security context", independent from a sort of subsystems.
For example, the POSIX ACL is an accomplished access control stuff, but
it is specific for filesystem. We have no way to apply it on network
access controls.

In addition, it enables to reduce privilege escalation risk as Greg Smith
mentioned.

> *) Mandatory access control could be a useful feature for some users.
> But must we resort to SELinux as the configuration language and
> implementation backend? Why couldn't we implement a MAC system in SQL
> using the existing language?
>
> Also, what I read is that role-based access control (RBAC) systems are
> equally capable of providing the sort of stronger security that MAC
> users are typically looking for. (In some ways, it appears to be the
> newer thing.) PostgreSQL already has a pretty good role system, so we
> could perhaps look into enhancing that to meet the necessary functional
> criteria that may exist.

I want you to understand the proposd design *NEVER* denies mandatory access
controls based on other security engine. The PGACE hooks enables to swap
the access control subsystem by the configure option.

I also agree that PostgreSQL already has a pretty good role and access
control mechanism. However, it is hard to describe mandatory access control
policy in common forms between OS and RDBMS.

I don't think dual-checks are matter. The operating system applies its DAC
policy known as filesystem permission and MAC policy provided by SELinux
(or other facilities).

> *) Row-level security, column-level security and so on should in my mind
> first exist as a native SQL-level feature. It would be hard to explain
> that PostgreSQL does not have column-level GRANT privileges but that you
> can achieve the same if you go through SELinux. After all, the
> SE-PostgreSQL patch only hooks in to several places to throw "permission
> denied errors" when appropriate, so native SQL features should be able
> to achieve the same. (Well, there are interesting SELinux-vs-AppArmor
> type differences here, that may be worth considering separately.)

I cannot understand the reason why these native/newer access control
facilities should have same access control guranualities.
These are provided by different subsystems, so they have different
guranualities and results. What is the matter?

The relationship of them is designed by reference to DAC and MAC on operating
system. As I noted above, it checks user's request twice based on different
security policy.

In addition, SELinux defines 20 kind of permissions for regular files,
being finer than filesystem permissions. It is not a curious behavior.

> The way I see this, the approach to be taken to achieve some kind of
> government-grade security system would be:
>
> 1. Implement row-level security, column-level privileges, and all other
> necessary permission bits as SQL features.
>
> 2. Enhance the role system to meet whatever the evaluation criteria may be.
>
> 3a. Add access control extension hooks.
>
> 3b. Implement SELinux on top of these hooks.
>
> You have already done 3a and 3b, but I think 1 and 2 should be done first.

It seems to me there is no dependencies.
We can make progress them in parallel.

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