[PATCH] Add <<none>> support to sepgsql_restorecon
In SELinux file context files you can specify <<none>> for a file
meaning you don't want restorecon to relabel it. <<none>> is
especially useful in an SELinux MLS environment when objects are
created at a specific security level and you don't want restorecon to
relabel them to the wrong security level.
Ted
Attachments:
sepgsql_context_none.patchapplication/octet-stream; name=sepgsql_context_none.patchDownload
From 5aeef0d7343c9354b66e4501864027fe1e6930f8 Mon Sep 17 00:00:00 2001
From: "Ted X. Toth" <txtoth@gmail.com>
Date: Mon, 21 Nov 2022 12:32:46 -0800
Subject: [PATCH] Support '<<none>>' in SELinux sepgsql context file similar to
how it can be used in file context files to stop sepgsql_restorecon from relabeling database objects.
---
contrib/sepgsql/label.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/contrib/sepgsql/label.c b/contrib/sepgsql/label.c
index 440d9f0d50..8906828e76 100644
--- a/contrib/sepgsql/label.c
+++ b/contrib/sepgsql/label.c
@@ -818,9 +818,11 @@ exec_object_restorecon(struct selabel_handle *sehnd, Oid catalogId)
* Check SELinux permission to relabel the fetched object,
* then do the actual relabeling.
*/
- sepgsql_object_relabel(&object, context);
+ if (strcmp(context, "<<none>>")) {
+ sepgsql_object_relabel(&object, context);
- SetSecurityLabel(&object, SEPGSQL_LABEL_TAG, context);
+ SetSecurityLabel(&object, SEPGSQL_LABEL_TAG, context);
+ }
}
PG_FINALLY();
{
--
2.31.1
On 11/21/22 15:57, Ted Toth wrote:
In SELinux file context files you can specify <<none>> for a file
meaning you don't want restorecon to relabel it. <<none>> is
especially useful in an SELinux MLS environment when objects are
created at a specific security level and you don't want restorecon to
relabel them to the wrong security level.
+1
Please add to the next commitfest here:
https://commitfest.postgresql.org/41/
Thanks,
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
On 11/21/22 17:35, Joe Conway wrote:
On 11/21/22 15:57, Ted Toth wrote:
In SELinux file context files you can specify <<none>> for a file
meaning you don't want restorecon to relabel it. <<none>> is
especially useful in an SELinux MLS environment when objects are
created at a specific security level and you don't want restorecon to
relabel them to the wrong security level.+1
Please add to the next commitfest here:
https://commitfest.postgresql.org/41/
Comments:
1. It seems like the check for a "<<none>>" context should go into
sepgsql_object_relabel() directly rather than exec_object_restorecon().
The former gets registered as a hook in _PG_init(), so the with the
current location we would fail to skip the relabel when that gets called.
2. Please provide one or more test case (likely in label.sql)
3. An example, or at least a note, mentioning "<<none>>" context and the
implications would be appropriate.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
On Sun, Jan 15, 2023 at 1:11 PM Joe Conway <mail@joeconway.com> wrote:
On 11/21/22 17:35, Joe Conway wrote:
On 11/21/22 15:57, Ted Toth wrote:
In SELinux file context files you can specify <<none>> for a file
meaning you don't want restorecon to relabel it. <<none>> is
especially useful in an SELinux MLS environment when objects are
created at a specific security level and you don't want restorecon to
relabel them to the wrong security level.+1
Please add to the next commitfest here:
https://commitfest.postgresql.org/41/Comments:
1. It seems like the check for a "<<none>>" context should go into
sepgsql_object_relabel() directly rather than exec_object_restorecon().
The former gets registered as a hook in _PG_init(), so the with the
current location we would fail to skip the relabel when that gets called.
The intent is not to stop all relabeling only to stop sepgsql_restorecon
from doing a bulk relabel. I believe sepgsql_object_relabel is called by
the 'SECURITY LABEL' statement which I'm using to set the label of db
objects to a specific context which I would not want altered later by a
restorecon.
Show quoted text
2. Please provide one or more test case (likely in label.sql)
3. An example, or at least a note, mentioning "<<none>>" context and the
implications would be appropriate.--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
On 1/16/23 09:55, Ted Toth wrote:
On Sun, Jan 15, 2023 at 1:11 PM Joe Conway <mail@joeconway.com
<mailto:mail@joeconway.com>> wrote:On 11/21/22 17:35, Joe Conway wrote:
On 11/21/22 15:57, Ted Toth wrote:
In SELinux file context files you can specify <<none>> for a file
meaning you don't want restorecon to relabel it. <<none>> is
especially useful in an SELinux MLS environment when objects are
created at a specific security level and you don't wantrestorecon to
relabel them to the wrong security level.
+1
Please add to the next commitfest here:
https://commitfest.postgresql.org/41/<https://commitfest.postgresql.org/41/>
Comments:
1. It seems like the check for a "<<none>>" context should go into
sepgsql_object_relabel() directly rather than exec_object_restorecon().
The former gets registered as a hook in _PG_init(), so the with the
current location we would fail to skip the relabel when that gets
called.The intent is not to stop all relabeling only to stop sepgsql_restorecon
from doing a bulk relabel. I believe sepgsql_object_relabel is called by
the 'SECURITY LABEL' statement which I'm using to set the label of db
objects to a specific context which I would not want altered later by a
restorecon.
Ok, sounds reasonable. Maybe just add a comment to that effect.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
The intent of this patch is not to stop all relabeling only to stop sepgsql_restorecon from doing a bulk relabel. I believe sepgsql_object_relabel is called by the 'SECURITY LABEL' statement which I'm using to set the label of db objects to a specific context which I would not want altered later by a restorecon. This is particularly important in a MLS (multi-level security) environment where for example if a row were labeled at the 'secret' level I would not restorecon to relabel it possibly causing a downgrade.
The new status of this patch is: Ready for Committer
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation: not tested
This needs regression test support for the feature and some minimal documentation that shows how to make use of it.
The new status of this patch is: Waiting on Author
On Wed, 18 Jan 2023 at 23:57, Joe Conway <mail@joeconway.com> wrote:
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation: not testedThis needs regression test support for the feature and some minimal documentation that shows how to make use of it.
The new status of this patch is: Waiting on Author
By mistake instead of setting the patch to "Moved to Next CF", I had
selected "Returned with Feedback". Sorry about that.
I have recreated the entry for this patch in the 03/23 commitfest:
https://commitfest.postgresql.org/42/4158/
Regards,
Vignesh
Ok, sounds reasonable. Maybe just add a comment to that effect.
This needs regression test support for the feature and some minimal documentation that shows how to make use of it.
Hm. It sounds like this patch is uncontroversial but is missing
documentation and tests? Has this been addressed? Do you think you'll
get a chance to resolve those issues this month in time for this
release?
--
Gregory Stark
As Commitfest Manager
Not this month unfortunately other work has taken precedence. I'll need to
look at what it's going to take to create a test. Hopefully I can piggyback
on an existing test.
Ted
On Mon, Mar 20, 2023 at 3:05 PM Gregory Stark (as CFM) <stark.cfm@gmail.com>
wrote:
Show quoted text
Ok, sounds reasonable. Maybe just add a comment to that effect.
This needs regression test support for the feature and some minimal
documentation that shows how to make use of it.
Hm. It sounds like this patch is uncontroversial but is missing
documentation and tests? Has this been addressed? Do you think you'll
get a chance to resolve those issues this month in time for this
release?--
Gregory Stark
As Commitfest Manager
On 20 Mar 2023, at 21:17, Ted Toth <txtoth@gmail.com> wrote:
Not this month unfortunately other work has taken precedence. I'll need to look at what it's going to take to create a test. Hopefully I can piggyback on an existing test.
This patch has been marked Waiting on Author since January, I'm marking it
Returned with Feedback. Please feel free to resubmit when there is time and
interest to resume work on this.
--
Daniel Gustafsson