Thread: [PATCH] Add <> 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
Attachment
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.
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 want > restorecon 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 believesepgsql_object_relabel is called by the 'SECURITY LABEL' statement which I'm using to set the label of db objectsto 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 restoreconto 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 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 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:
> 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 atest. 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