In the following mails, I'm resending two patches which I already submittted in
February. They were put on hold so that the developers of the postgresql policy
could comment on it, but there haven't been any answers since.
I'd really like to see these patches included, as it's impossible for normal
users to use the postgres client programs (e.g. psql) without them. Our
postgresql policy is supposed to protect postgresql servers running on the host,
not rendering the client programs inaccessible.
Regards,
Luis Ressel
Currently, all postgresql commands in are labeled as postgresql_exec_t.
This means they can only be executed by db admins. However, the "normal"
commands, such as createdb or psql, should also be executable by users.
(The users in question still need to be granted postgresql_role(), so
this is no security problem.)
---
policy/modules/services/postgresql.fc | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/policy/modules/services/postgresql.fc b/policy/modules/services/postgresql.fc
index 687a4a9..78a7464 100644
--- a/policy/modules/services/postgresql.fc
+++ b/policy/modules/services/postgresql.fc
@@ -15,7 +15,17 @@
/usr/lib/pgsql/test/regress(/.*)? gen_context(system_u:object_r:postgresql_db_t,s0)
/usr/lib/pgsql/test/regress/pg_regress -- gen_context(system_u:object_r:postgresql_exec_t,s0)
-/usr/lib/postgresql/bin/.* -- gen_context(system_u:object_r:postgresql_exec_t,s0)
+
+/usr/lib/postgresql(-.*)?/bin/pg_archivecleanup -- gen_context(system_u:object_r:postgresql_exec_t,s0)
+/usr/lib/postgresql(-.*)?/bin/pg_basebackup -- gen_context(system_u:object_r:postgresql_exec_t,s0)
+/usr/lib/postgresql(-.*)?/bin/pg_controldata -- gen_context(system_u:object_r:postgresql_exec_t,s0)
+/usr/lib/postgresql(-.*)?/bin/pg_ctl -- gen_context(system_u:object_r:postgresql_exec_t,s0)
+/usr/lib/postgresql(-.*)?/bin/pg_resetxlog -- gen_context(system_u:object_r:postgresql_exec_t,s0)
+/usr/lib/postgresql(-.*)?/bin/pg_standby -- gen_context(system_u:object_r:postgresql_exec_t,s0)
+/usr/lib/postgresql(-.*)?/bin/pg_upgrade -- gen_context(system_u:object_r:postgresql_exec_t,s0)
+/usr/lib/postgresql(-.*)?/bin/pg_xlogdump -- gen_context(system_u:object_r:postgresql_exec_t,s0)
+/usr/lib/postgresql(-.*)?/bin/postgres -- gen_context(system_u:object_r:postgresql_exec_t,s0)
+/usr/lib/postgresql(-.*)?/bin/postmaster -l gen_context(system_u:object_r:postgresql_exec_t,s0)
ifdef(`distro_debian', `
/usr/lib/postgresql/.*/bin/.* -- gen_context(system_u:object_r:postgresql_exec_t,s0)
--
2.0.4
I'm sure this is the right thing to do; however, the Debian developers
might want to have a say in this, so I made a separate patch.
---
policy/modules/services/postgresql.fc | 24 ++++++++++--------------
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/policy/modules/services/postgresql.fc b/policy/modules/services/postgresql.fc
index 78a7464..d3bc4bb 100644
--- a/policy/modules/services/postgresql.fc
+++ b/policy/modules/services/postgresql.fc
@@ -16,20 +16,16 @@
/usr/lib/pgsql/test/regress(/.*)? gen_context(system_u:object_r:postgresql_db_t,s0)
/usr/lib/pgsql/test/regress/pg_regress -- gen_context(system_u:object_r:postgresql_exec_t,s0)
-/usr/lib/postgresql(-.*)?/bin/pg_archivecleanup -- gen_context(system_u:object_r:postgresql_exec_t,s0)
-/usr/lib/postgresql(-.*)?/bin/pg_basebackup -- gen_context(system_u:object_r:postgresql_exec_t,s0)
-/usr/lib/postgresql(-.*)?/bin/pg_controldata -- gen_context(system_u:object_r:postgresql_exec_t,s0)
-/usr/lib/postgresql(-.*)?/bin/pg_ctl -- gen_context(system_u:object_r:postgresql_exec_t,s0)
-/usr/lib/postgresql(-.*)?/bin/pg_resetxlog -- gen_context(system_u:object_r:postgresql_exec_t,s0)
-/usr/lib/postgresql(-.*)?/bin/pg_standby -- gen_context(system_u:object_r:postgresql_exec_t,s0)
-/usr/lib/postgresql(-.*)?/bin/pg_upgrade -- gen_context(system_u:object_r:postgresql_exec_t,s0)
-/usr/lib/postgresql(-.*)?/bin/pg_xlogdump -- gen_context(system_u:object_r:postgresql_exec_t,s0)
-/usr/lib/postgresql(-.*)?/bin/postgres -- gen_context(system_u:object_r:postgresql_exec_t,s0)
-/usr/lib/postgresql(-.*)?/bin/postmaster -l gen_context(system_u:object_r:postgresql_exec_t,s0)
-
-ifdef(`distro_debian', `
-/usr/lib/postgresql/.*/bin/.* -- gen_context(system_u:object_r:postgresql_exec_t,s0)
-')
+/usr/lib/postgresql(-.*)?/(.*/)?bin/pg_archivecleanup -- gen_context(system_u:object_r:postgresql_exec_t,s0)
+/usr/lib/postgresql(-.*)?/(.*/)?bin/pg_basebackup -- gen_context(system_u:object_r:postgresql_exec_t,s0)
+/usr/lib/postgresql(-.*)?/(.*/)?bin/pg_controldata -- gen_context(system_u:object_r:postgresql_exec_t,s0)
+/usr/lib/postgresql(-.*)?/(.*/)?bin/pg_ctl -- gen_context(system_u:object_r:postgresql_exec_t,s0)
+/usr/lib/postgresql(-.*)?/(.*/)?bin/pg_resetxlog -- gen_context(system_u:object_r:postgresql_exec_t,s0)
+/usr/lib/postgresql(-.*)?/(.*/)?bin/pg_standby -- gen_context(system_u:object_r:postgresql_exec_t,s0)
+/usr/lib/postgresql(-.*)?/(.*/)?bin/pg_upgrade -- gen_context(system_u:object_r:postgresql_exec_t,s0)
+/usr/lib/postgresql(-.*)?/(.*/)?bin/pg_xlogdump -- gen_context(system_u:object_r:postgresql_exec_t,s0)
+/usr/lib/postgresql(-.*)?/(.*/)?bin/postgres -- gen_context(system_u:object_r:postgresql_exec_t,s0)
+/usr/lib/postgresql(-.*)?/(.*/)?bin/postmaster -l gen_context(system_u:object_r:postgresql_exec_t,s0)
ifdef(`distro_redhat', `
/usr/share/jonas/pgsql(/.*)? gen_context(system_u:object_r:postgresql_db_t,s0)
--
2.0.4
Looks good to me. I don't have a PostgreSQL test machine now so I can't verify it. But I think it's best to apply this and I'll fix Debian later if things break.
As an aside what's a good design for PostgreSQL testing? Is there anyone who would like to setup a Debian VM for me for the purpose of testing this? I'm going to run a set of Debian VMs to test the most common daemons to avoid regression.
Thanks to the person who offered to setup Nagios for me some weeks ago, I'll take you up on that soon.
On 12 August 2014 10:35:58 PM AEST, Luis Ressel <[email protected]> wrote:
>I'm sure this is the right thing to do; however, the Debian developers
>might want to have a say in this, so I made a separate patch.
>---
> policy/modules/services/postgresql.fc | 24 ++++++++++--------------
> 1 file changed, 10 insertions(+), 14 deletions(-)
>
>diff --git a/policy/modules/services/postgresql.fc
>b/policy/modules/services/postgresql.fc
>index 78a7464..d3bc4bb 100644
>--- a/policy/modules/services/postgresql.fc
>+++ b/policy/modules/services/postgresql.fc
>@@ -16,20 +16,16 @@
>/usr/lib/pgsql/test/regress(/.*)? gen_context(system_u:object_r:postgresql_db_t,s0)
>/usr/lib/pgsql/test/regress/pg_regress --
>gen_context(system_u:object_r:postgresql_exec_t,s0)
>
>-/usr/lib/postgresql(-.*)?/bin/pg_archivecleanup -- gen_context(system_u:object_r:postgresql_exec_t,s0)
>-/usr/lib/postgresql(-.*)?/bin/pg_basebackup -- gen_context(system_u:object_r:postgresql_exec_t,s0)
>-/usr/lib/postgresql(-.*)?/bin/pg_controldata -- gen_context(system_u:object_r:postgresql_exec_t,s0)
>-/usr/lib/postgresql(-.*)?/bin/pg_ctl -- gen_context(system_u:object_r:postgresql_exec_t,s0)
>-/usr/lib/postgresql(-.*)?/bin/pg_resetxlog -- gen_context(system_u:object_r:postgresql_exec_t,s0)
>-/usr/lib/postgresql(-.*)?/bin/pg_standby -- gen_context(system_u:object_r:postgresql_exec_t,s0)
>-/usr/lib/postgresql(-.*)?/bin/pg_upgrade -- gen_context(system_u:object_r:postgresql_exec_t,s0)
>-/usr/lib/postgresql(-.*)?/bin/pg_xlogdump -- gen_context(system_u:object_r:postgresql_exec_t,s0)
>-/usr/lib/postgresql(-.*)?/bin/postgres -- gen_context(system_u:object_r:postgresql_exec_t,s0)
>-/usr/lib/postgresql(-.*)?/bin/postmaster -l gen_context(system_u:object_r:postgresql_exec_t,s0)
>-
>-ifdef(`distro_debian', `
>-/usr/lib/postgresql/.*/bin/.* -- gen_context(system_u:object_r:postgresql_exec_t,s0)
>-')
>+/usr/lib/postgresql(-.*)?/(.*/)?bin/pg_archivecleanup -- gen_context(system_u:object_r:postgresql_exec_t,s0)
>+/usr/lib/postgresql(-.*)?/(.*/)?bin/pg_basebackup -- gen_context(system_u:object_r:postgresql_exec_t,s0)
>+/usr/lib/postgresql(-.*)?/(.*/)?bin/pg_controldata -- gen_context(system_u:object_r:postgresql_exec_t,s0)
>+/usr/lib/postgresql(-.*)?/(.*/)?bin/pg_ctl -- gen_context(system_u:object_r:postgresql_exec_t,s0)
>+/usr/lib/postgresql(-.*)?/(.*/)?bin/pg_resetxlog -- gen_context(system_u:object_r:postgresql_exec_t,s0)
>+/usr/lib/postgresql(-.*)?/(.*/)?bin/pg_standby -- gen_context(system_u:object_r:postgresql_exec_t,s0)
>+/usr/lib/postgresql(-.*)?/(.*/)?bin/pg_upgrade -- gen_context(system_u:object_r:postgresql_exec_t,s0)
>+/usr/lib/postgresql(-.*)?/(.*/)?bin/pg_xlogdump -- gen_context(system_u:object_r:postgresql_exec_t,s0)
>+/usr/lib/postgresql(-.*)?/(.*/)?bin/postgres -- gen_context(system_u:object_r:postgresql_exec_t,s0)
>+/usr/lib/postgresql(-.*)?/(.*/)?bin/postmaster -l gen_context(system_u:object_r:postgresql_exec_t,s0)
>
> ifdef(`distro_redhat', `
>/usr/share/jonas/pgsql(/.*)? gen_context(system_u:object_r:postgresql_db_t,s0)
--
Sent from my Samsung Galaxy Note 2 with K-9 Mail.
On 8/12/2014 8:35 AM, Luis Ressel wrote:
> In the following mails, I'm resending two patches which I already submittted in
> February. They were put on hold so that the developers of the postgresql policy
> could comment on it, but there haven't been any answers since.
>
> I'd really like to see these patches included, as it's impossible for normal
> users to use the postgres client programs (e.g. psql) without them. Our
> postgresql policy is supposed to protect postgresql servers running on the host,
> not rendering the client programs inaccessible.
I don't see any problems with this, but will still give KaiGai a final
chance to comment.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On 8/12/2014 8:35 AM, Luis Ressel wrote:
> In the following mails, I'm resending two patches which I already submittted in
> February. They were put on hold so that the developers of the postgresql policy
> could comment on it, but there haven't been any answers since.
>
> I'd really like to see these patches included, as it's impossible for normal
> users to use the postgres client programs (e.g. psql) without them. Our
> postgresql policy is supposed to protect postgresql servers running on the host,
> not rendering the client programs inaccessible.
This set is merged.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com