Re: sepgsql logging - Mailing list pgsql-hackers
| From | Dave Page |
|---|---|
| Subject | Re: sepgsql logging |
| Date | |
| Msg-id | CA+OCxoyQ+h73mLDhTUaDTC_i48zQooZBKRxyKNxD5JW08cxCBw@mail.gmail.com Whole thread Raw |
| In response to | Re: sepgsql logging (Jacob Champion <pchampion@vmware.com>) |
| Responses |
Re: sepgsql logging
|
| List | pgsql-hackers |
Hi
On Tue, Jan 11, 2022 at 12:04 AM Jacob Champion <pchampion@vmware.com> wrote:
On Wed, Apr 14, 2021 at 8:42 AM Dave Page <dpage@pgadmin.org> wrote:
> Attached is a patch to clean this up. It will log denials as such
> regardless of whether or not either selinux or sepgsql is in
> permissive mode. When either is in permissive mode, it'll add "
> permissive=1" to the end of the log messages. e.g.
Dave,
Just to clarify -- it looks like this patch *only* adds the
"permissive=1" part, right? I don't see any changes around denied-vs-
allowed.
Right. denied-vs-allowed is shown at the beginning of the log line. From my earlier output:
2021-04-14 13:20:30.401 BST [23073] LOG: SELinux: allowed { select } scontext=user_u:user_r:user_t:s0 tcontext=unconfined_u:object_r:sepgsql_table_t:s0 tclass=db_column name="column salt of table tb_users" permissive=1
2021-04-14 13:20:30.401 BST [23073] LOG: SELinux: denied { select } scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:sepgsql_secret_table_t:s0 tclass=db_column name="column phash of table tb_users" permissive=1
I read the previous posts to mean that you were seeing "allowed" when
you should have been seeing "denied".
That's what I *thought* was happening originally, because I was mistakenly in permissive mode (if memory serves).
I don't see that behavior --
without this patch, I see the correct "denied" entries even when
running in permissive mode. (It's been a while since the patch was
posted, so I checked to make sure there hadn't been any relevant
changes in the meantime, and none jumped out at me.)
Right. The point is that if permissive mode is enabled, access will not be denied. Effectively if you see permissive=1, then "denied" really means "would be denied if enforcing mode was enabled".
The idea is that you can run a production system in permissive mode to see what would be denied without breaking things for users. You can use that info to build your policy, and then when you no longer see any unexpected denials in the logs, switch to enforcing mode.
That said, the patch looks good as-is and seems to be working for me on
a Rocky 8 VM. (You weren't kidding about the setup difficulty.) Having
permissive mode show up in the logs seems very useful.
As an aside, I don't see the "allowed" verbiage that sepgsql uses in
any of the SELinux documentation. I do see third-party references to
"granted", though, as in e.g.
avc: granted { execute } for ...
That's not something that I think this patch should touch, but it
seemed tangentially relevant for future convergence work.
Interesting. I never spotted that one. I'm not sure it matters much, except for consistency. It's not like the various tools for analyzing SELinux logs would be likely to work on a PostgreSQL log.
On Wed, 2021-04-14 at 09:49 -0400, Robert Haas wrote:
> Looks superficially reasonable on first glance, but I think we should
> try to get an opinion from someone who knows more about SELinux.
I am not that someone, but this looks straightforward, it's been
stalled for a while, and I think it should probably go in.
I'd like to see that. Thanks for the review.
pgsql-hackers by date: