sepgsql logging - Mailing list pgsql-hackers

From Dave Page
Subject sepgsql logging
Date
Msg-id CA+OCxowsQoLEYc=jN7OtNvOdX0Jg5L7nMYt++=k0X78HGq-sXg@mail.gmail.com
Whole thread Raw
Responses Re: sepgsql logging  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Hi

I've been trying to figure out selinux with sepgsql (which is proving quite difficult as there is an almost total lack of documentation/blogs etc. on the topic) and ran into an issue. Whilst my system had selinux in enforcing mode, I mistakenly had sepgsql in permissive mode. I created a table and restricted access to one column to regular users using the label system_u:object_r:sepgsql_secret_table_t:s0. Because sepgsql was in permissive mode, my test user could still access the restricted column.

Postgres logged this:

2021-03-31 17:12:29.713 BST [3917] LOG:  SELinux: allowed { select } scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:sepgsql_secret_table_t:s0 tclass=db_column name="column private of table t1"

That's very confusing, because the norm in selinux is to log denials as if the system were in enforcing mode, but then allow the action to proceed anyway, when in permissive mode. For example, log entries such as this are created when my restricted user tries to run an executable from /tmp after running "setsebool -P user_exec_content off":

type=AVC msg=audit(1617278924.917:484): avc:  denied  { execute } for  pid=53036 comm="bash" name="ls" dev="dm-0" ino=319727 scontext=user_u:user_r:user_t:s0 tcontext=user_u:object_r:user_tmp_t:s0 tclass=file permissive=1

The point being to let the admin know what would fail if the system were switched to enforcing mode. Whilst that wasn't the point of what I was trying to do, such a message would have indicated to me that I was in permissive mode without realising.

It seems to me that sepgsql should also log the denial, but flag that permissive mode is on.

Any reason not to do that?

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Replication slot stats misgivings
Next
From: Bharath Rupireddy
Date:
Subject: Re: Add client connection check during the execution of the query