Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)

Simon Riggs wrote:
> 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.

I don't deny that SELinux has not been our majority yet.
However, I also think other configuratin options have similar issues
less or more. We cannot test all the combinations of the options, so
it should not be a reason.

> 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).

We can assign a proper label for common tables, which allows everyone
to access it. I guess it can be implement wih MCS policy so well.
Any customer has its individual category (c0 to c499) and their data
is also labeled as same category, but the common table is kept
uncategorized.

> 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 reason why SE-PostgreSQL feature is implemented on the PGACE security
framework is to provide end-users options.
We can switch preferable security feature or turn it off at this level.

If necessary, we can implement another option on the PGACE. The rowacl is
proof of the concept. It seems to me you consider a pluggable interface
to operating system enables to apply other security server, but, they can
have different security model, different security attribute and so on.

I think it is an appropriate decision to switch security features at the
hook level which does not provide any security model, more than integration
of different security design.

>>> 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.

This choice should be contained in the security model which can be choosen
at the PGACE hook level. At least, I cannot imagine SELinux without mandatory
feature. However, I don't deny other security model which allows mandatory or
discretionary.

>> 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.

We cannot represent a security context in TIMESTAMP or FLOAT datatype. :-)

From the viewpoint of user interfaces, I belive TEXT is an appropriate
datatype. It enables to provide an interface to manage security context
as they handle it on operating system.

>> 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?

It utilize the fortune that Oid has 32bit length.
It enables us to indicate a tuple within pg_security without any
additional enhancement.

>>> 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.

In this case, I recommend you to utilize TE rules, not MLS rules.
The default security policy provides postgresql_log_t type which prevent
to manupulate it from others.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>