Feature suggestion: Database-Security-Modules (DSM)
От | Jan Kechel |
---|---|
Тема | Feature suggestion: Database-Security-Modules (DSM) |
Дата | |
Msg-id | 58DA161E.2010809@kechel.de обсуждение исходный текст |
Список | 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-----
В списке pgsql-hackers по дате отправления: