On Tue, Jul 19, 2022 at 7:58 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > On Tue, Jul 19, 2022 at 12:31 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > Rework the SCTP tests slightly to remove two assumptions which are > > not always guaranteed to be true (below). This should have not any > > affect on the current test suite or released kernels, but it will > > help ensure that the test suite continues to work with upcoming > > kernel releases. > > > > * Do not rely on IP options attached to a socket. Depending on the > > kernel configuration, the on-the-wire packet labels may be > > generated on a per-packet basis as opposed to a per-socket basis. > > Could you expand a bit on why this would be a problem? It's not clear > to me how switching to per-packet would break the tests. (Maybe I'm > just not thinking about it hard enough, but ideally the commit message > would explain the problem to me so I don't have to :) NetLabel can either attach on-the-wire packet labels (IP options) directly to the packet or to the socket, in the latter case the network stack handles writing the on-the-wire labels to the packet when it is generated. Deciding on when to attach IP options (on-the-wire labels) to the socket versus the packet is an implementation detail and depends on the specific configuration of the system and the protocols involved. It is my opinion that going into the level of detail necessary to explain the differences would involve a discussion about how the Linux network stacks works, the design of the NetLabel subsystem, and how the different network protocols work. The important takeaway is that one can not safely rely on IP options attached to a socket as a means of determining the labeling behavior of a socket/connection/association/etc., this is why we have APIs such as getpeercon() and the LSM specific socket options. -- paul-moore.com
