On Thu, Nov 11, 2021 at 4:44 PM Paul Moore [off-list ref] wrote:

On Thu, Nov 11, 2021 at 7:59 AM Ondrej Mosnacek [off-list ref] wrote:

quoted

On Tue, Nov 9, 2021 at 4:00 PM Paul Moore [off-list ref] wrote:

quoted

On Tue, Nov 9, 2021 at 9:21 AM Jakub Kicinski [off-list ref] wrote:

quoted

On Thu,  4 Nov 2021 20:59:49 +0100 Ondrej Mosnacek wrote:

quoted

As agreed with Xin Long, I'm posting this fix up instead of him. I am
now fairly convinced that this is the right way to deal with the
immediate problem of client peeloff socket labeling. I'll work on
addressing the side problem regarding selinux_socket_post_create()
being called on the peeloff sockets separately.

IIUC Paul would like to see this part to come up in the same series.

Just to reaffirm the IIUC part - yes, your understanding is correct.

The more I'm reading these threads, the more I'm getting confused...
Do you insist on resending the whole original series with
modifications? Or actual revert patches + the new patches? Or is it
enough to revert/resend only the patches that need changes? Do you
also insist on the selinux_socket_post_create() thing to be fixed in
the same series? Note that the original patches are still in the
net.git tree and it doesn't seem like Dave will want to rebase them
away, so it seems explicit reverting is the only way to "respin" the
series...

DaveM is stubbornly rejecting the revert requests so for now I would
continue to base any patches on top of the netdev tree.  If that
changes we can reconcile any changes as necessary, that should not be
a major issue.

As far as what I would like to see from the patches, ignoring the
commit description vs cover letter discussion, I would like to see
patches that fix all of the known LSM/SELinux/SCTP problems as have
been discussed over the past couple of weeks.  Even beyond this
particular issue I generally disapprove of partial fixes to known
problems; I would rather see us sort out all of the issues in a single
patchset so that we can review everything in a sane manner.  In this
particular case things are a bit more complicated because of the
current state of the patches in the netdev tree, but as mentioned
above just treat the netdev tree as broken and base your patches on
that with all of the necessary "Fixes:" metadata and the like.

Hm, okay, that isn't what I was branch-predicting from your other
responses, but works for me.

quoted

Regardless of the answers, this thing has rabbithole'd too much and
I'm already past my free cycles to dedicate to this, so I think it
will take me (and Xin) some time to prepare the corrected and
re-documented patches. Moreover, I think I realized how to to deal
with the peer_secid-vs.-multiple-assocs-on-one-socket problem that Xin
mentions in patch 4/4, fixing which can't really be split out into a
separate patch and will need some test coverage, so I don't think I
can rush this up at this point...

It's not clear to me from your comments above if this is something you
are currently working on, planning to work on soon, or giving up on in
the near term.  Are we able to rely on you for a patchset to fix this
or are you unable to see this through at this time?

I'm still working on it, but I'll need to juggle it with other things
now and I might need to defer it completely at some point. I don't
think I'll have all the patches ready sooner than two weeks from now.
My point was to explain that I'm unable to provide a proper fix in the
short term and don't want to block the netdev maintainers in case they
were waiting for this to get resolved before e.g. sending a PR to
Linus.

--
Ondrej Mosnacek
Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.