Feature suggestion: Database-Security-Modules (DSM)

From: Jan Kechel <jan(at)kechel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Feature suggestion: Database-Security-Modules (DSM)
Date: 2017-03-28 07:51:58
Message-ID: 58DA161E.2010809@kechel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Hi PostgreSQL Hackers,

I'm developing software using PostgreSQL for several years and want to
propose a feature to improve security of (badly written?) Web-Apps.

I call it 'Database Security Modules', derived from
Linux-Security-Modules (aka SELinux, AppArmor, Tomoyo).

Of course such a feature might already exist, or is in your opinion
not a task for PostgreSQL at all. In that case please simply inform me
about my mistake ;)

What it's about:

It's to prevent SQL-Injection and/or unpriviliged data-retrievel once
the webserver has been hacked and/or the Application-Server security
measures have ceased.

How it works:

Users or Roles get attached Access-Rules to form a DSM-List.
Each Access-Rule specifies a specific query-plan, that hereby is
granted to be executed.

Why it helps:

A simple SQL-Injection could append to query sth. like ' or 1 = 1;
select * from table_with_secret_columns' to retrieve data it should
not have access to.

But, this always (?? not sure, is this true? does it help at all?)
changes the query-plans. Now we have to queries, but each doesn't have
a valid Access-Rule as the first adds a 1=1 and thus probably changes
completely and the second one never had a Rule.

Both queries will be rejected and thus render the SQL-Injection useless.

Further ideas:

Later, this could be enhanced with additional information given to the
DSM, like 'current user id', and some Access-Rules could scope queries
based on this additional information (like only allowing a specific
Query-Plan with the parameter user_id equal to the given id).
Another addition could be rate-limiting.

Convenience:

DSMs should have different modes like 'off', 'training' (logging
query-plans to copy into DSM-Lists), 'warn' (logging but not failing
violations) and of course 'enforce'.

Please let me know what you think and if you'd be interested to see a
first basic patch implementing this.

best regards,

Jan Kechel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAwAGBQJY2hYdAAoJEDdxXoVRJZEA0qoQAITW+Q0EUGsFouvR5VckYR3S
xQfL8ecMZEqYeAGwYYBUhK00DF/Wqa8GDyBq8BGbicQjmx6WFpeZYTqx6LF/twar
EAewuEueOLWs29sOt6Mn+pCATUZIzTIbF+h7QvqTucFK3kjrCe1qwD06ErVPExQ+
9NPgNZBxaivlwtuQk5xi495XyI3BVdN3zzaS6zfgQC1jXv7+tpy07TLZDGs8ckOv
sziPhwEDiWD81qz8TsH+YromiKu9pT/dMiQyxagm5G/BSTJq4/QveI94EzQh5LLk
AZiSbWg+JOhaJKh5YSgOfBlLfyDZFFdOtgqXHSrX8aRG4KPkXmsNWWLk2XRswsIr
SIga9CFda8f0Ou78MBAOQRI0baK76O5ycy+aYLawLM2z1A/sozQS+pqaK+xAQtjZ
VnNa0t99b89rAgozRrySfktjPeqQliiU4LYy/7Fy918io8kdxAm5j2zaTXdjxTto
Fz+OOgg03PjbGHtH9yJOpE6afcIOOwk1SFfAfusJqZXnlhEsASVoQVsz5sCvpCk6
xJ8LeYeRaucdbTp7BxFNz9p7klJlpGz64J4hjFUD/EeQMCf8KmOmHLy+WN7aCps+
2SncRLONv6UhuSbxhKFqfLgxBevF3pBXuCZLqSTwjNUipSqW4ITT3MhXWmM7DaKH
DZTfp6b3ZNMaW8xjkt3j
=a5v8
-----END PGP SIGNATURE-----

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-03-28 08:10:15 Re: PATCH: Batch/pipelining support for libpq
Previous Message Pavel Stehule 2017-03-28 07:12:26 Re: Re: proposal - psql: possibility to specify sort for describe commands, when size is printed