On Tue, Jun 14, 2022 at 8:52 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > On Tue, Jun 7, 2022 at 5:08 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > On Tue, Jun 7, 2022 at 8:28 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > > > On Fri, Jun 3, 2022 at 12:45 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > > On Thu, Jun 2, 2022 at 10:49 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > > > > > On Wed, Jun 1, 2022 at 3:32 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > > > > On Tue, May 31, 2022 at 7:53 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > > > > > On Tue, May 31, 2022 at 1:05 PM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > > > > ... > > > > > > > > From a quick skim of the SCTP RFCs, the ASCONF chunk is sent from a > > > > > > remote endpoint to update the SCTP parameters so in this case I > > > > > > believe the subject should be the remote peer (the association/sock's > > > > > > peer_secid) and the object should be the local association/socket. > > > > > > It's important to note that any access control checks using the remote > > > > > > peer label should be gated by the selinux_peerlbl_enabled() function, > > > > > > see selinux_socket_sock_rcv_skb() for an example. > > > > > > > > > > I don't like the idea of using peer_secid as the subject for > > > > > socket::connect, which normally has a task sid as the subject. > > > > > > > > While I have concerns about reusing the socket:connect permission for > > > > the ASCONF updates, it isn't because of the peer_secid. The > > > > peer_secid represents the security label of the remote peer and it is > > > > the subject label for ASCONF operations. > > > > > > It does make sense to use it as a subject label, but not for the > > > connect permission, where the convention is that the subject context > > > is a process context. While we don't have any hard rule against mixing > > > different "kinds" of contexts in the subject/target of a given > > > permission, it makes both figuring out AVC denials and reasoning about > > > policy harder and I want to avoid it wherever possible. > > > > The network peer label is a process label, it is intended to represent > > the security attributes of the remote process. > > Hm, indeed, I misunderstood the semantics behind it. Let's disregard > that argument then. > > Still, I'd say the situation "a remote process wants to potentially > redirect communication to a different address" is different enough > from "local process intends to initiate a connection to a given > endpoint" that it warrants a special permission. I had really hoped to have a patch on the list by now, but in the process of fixing the original SCTP issue I found another related to how SCTP traffic is labeled. Fixing that problem exposed a bad assumption in the selinux-testsuite SCTP tests which I'm currently working on fixing. I'm hopeful that it shouldn't be *too* much longer before the patches hit the list, so let's just hold off on this thread until we have some proper patches to discuss. -- paul-moore.com
