Re: Updates of SE-PostgreSQL 8.4devel patches (r1197) - Mailing list pgsql-hackers

On Sat, 2008-11-08 at 14:21 +0900, KaiGai Kohei wrote:

> > Some users will be able to take advantage of the facilities without
> > implementing full MLS. Yet we want the full facilities for Government.
> > Many people currently run multiple customers in different schemas,
> > though this would let them just run a single set of tables so is much
> > better for running many small customers.
> 
> SELinux community also provides a MLS enabled policy, but it is not
> a default one now. SE-PostgreSQL has all the its access controls
> decision externally, so it is out of our coltrols.

I have a couple of concerns: 

1. if we make a direct link with SELinux then the code will be *much*
less used and tested. It will be a constant battle to maintain
SEPostgres in a bug-free state. I want to decouple the link so this code
goes into normal Postgres. Other comments below are made with that
thought in mind.

2. I see another use case here. For example, a customer runs a
Software-as-a-service company where the same service is offered to 500
customers. The same database schema is there for each customer, yet they
must never see each other's data. Today, that is implemented as 500
schemas, plus 1 schema with common data in it. ISTM we would be able to
implement this better using SEPostgreSQL, with/without using SELinux.
The need for common data is why in some cases we would want access
controls placed only on certain tables.

Fulfilling use case (2) will also meet my concerns in (1).

So I would prefer it if the solution was designed closely with SELinux,
but usable and useful in other cases also. The link to SELinux could be
done via a contrib plugin. A plugin is then optional. But the main
plugin we provide can be built directly with SELinux.

> > The security context on each row could be an optional column present
> > only if HEAP_HASSECURITYCONTEXT is set (0x0010 see htup.h), just like
> > OIDs. Use a specific datatype rather than TEXT. That datatype could be
> > an identifier to pg_security. Security people have big databases too, so
> > we need to compress the security context more and take out parse time of
> > string handling. Don't think we should use Oids, they're too big. Might
> > be easier to use a 2byte field and restrict access to 32,000 contexts,
> > which is easily enough. TEXT also makes me nervous, just in case there
> > is some collation/encoding weirdness that allows contexts to be
> > subverted. Fixed integers are hard to compromise in that respect.
> 
> An issue is who can decide the existance or needs of security system
> attribute. If the table owner can disable it, we cannot say it as
> a mandatory access control feature, so the security attribute has to
> be always appeared when the security feature is enabled.
> 
> Here is an answer for the expected question.
> When we refer the "security_context" system column of tuples without
> HEAP_HAS_SECURITY, it returns an alternative label called as "unlabeled_t",
> because it has no labels.

Not really an issue. Just use a parameter. security_controls = mandatory
or change the meaning of the existing one. Similar to default_with_oids,
just that we have a setting where it isn't optional.

> The reason why we adopt TEXT type is SELinux requires userspace
> object manager makes queries via text represented security context,
> and it also can be used for other security feature to show client
> its security attribute in human readable format.

AFAICS, neither of those things means the datatype has to be TEXT.

> For your information, in-kernel SELinux can handle 2^32 - 1 of security
> context internally in theoretical maximum, so using Oid as a security
> identifier is a fair decision to avoid an implementation to handle overflow
> cases.

OK, so we need 4 bytes. I can live with that - at least its not ~10
bytes/row. Does it need to be an Oid, or just the size of an Oid?

> > The section on LOAD doesn't sound very convincing. Loading a module
> > could immediately subvert security. We could probably tighten up on that
> > for general use as well. ISTM we need something like a new catalog table
> > for loadable modules, so we can give them specific security contexts and
> > potentially store some kind of verification information about them.
> > Having a single "can load modules" isn't enough with Postgres, since it
> > would effectively prevent us from loading *any* modules in a secure
> > database. Which kinda removes much of the benefit of using Postgres.
> 
> SE-PostgreSQL applies access controls for individual loadable modules.
> When a function implemented within an external modules tries to be loaded,
> it checks security context between the database and the file of loadable
> modules. (No need to say, in-kernel SELinux assigns its security context
> for files in common format, so we can compare them each other.)
> 
> Perhaps, the description I wrote can easily make misunderstanding.
> If you can read it says widespread load modules permission, I'll revise
> its representation.
> 
>   http://wiki.postgresql.org/wiki/SEPostgreSQL#Loading_shared_library_module
> 

> > How does Discretionary Access control work with regard to server logs?
> > You said there was no superuser access, but I don't see any controls for
> > the logs. Do we need log_max_security_context?
> 
> It writes out server logs to filesystem, so its access controls should
> be applied in-kernel SELinux. SE-PostgreSQL does not care system call
> invocation, because it should be a task in kernel features.
> It works as a reference monitor for SQL queries.

Yes, the file will be protected. My thought was that we might wish to
control the levels of message placed in the file. Otherwise you would
require top level access to view the log. It doesn't seem likely that
they would want to give Top Secret level access to DBAs. Nor should any
level of DBAs be able to inspect who is running which SQL by simple
manipulation of parameters such as log_min_duration_statement.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support