Documentation/security/SCTP.rst

Source file repositories/reference/linux-study-clean/Documentation/security/SCTP.rst

File Facts

System: Linux kernel
Corpus path: Documentation/security/SCTP.rst
Extension: .rst
Size: 14730 bytes
Lines: 345
Domain: Support Tooling And Documentation
Bucket: Documentation
Inferred role: Support Tooling And Documentation: documentation
Status: atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.

Dependency Surface

No C-style include directives detected by the generator.

Detected Declarations

No top-level syscall, struct, function, initcall, or export declaration detected by the generator.

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0

====
SCTP
====

SCTP LSM Support
================

Security Hooks
--------------

For security module support, three SCTP specific hooks have been implemented::

    security_sctp_assoc_request()
    security_sctp_bind_connect()
    security_sctp_sk_clone()
    security_sctp_assoc_established()

The usage of these hooks are described below with the SELinux implementation
described in the `SCTP SELinux Support`_ chapter.


security_sctp_assoc_request()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Passes the ``@asoc`` and ``@chunk->skb`` of the association INIT packet to the
security module. Returns 0 on success, error on failure.
::

    @asoc - pointer to sctp association structure.
    @skb - pointer to skbuff of association packet.


security_sctp_bind_connect()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Passes one or more ipv4/ipv6 addresses to the security module for validation
based on the ``@optname`` that will result in either a bind or connect
service as shown in the permission check tables below.
Returns 0 on success, error on failure.
::

    @sk      - Pointer to sock structure.
    @optname - Name of the option to validate.
    @address - One or more ipv4 / ipv6 addresses.
    @addrlen - The total length of address(s). This is calculated on each
               ipv4 or ipv6 address using sizeof(struct sockaddr_in) or
               sizeof(struct sockaddr_in6).

  ------------------------------------------------------------------
  |                     BIND Type Checks                           |
  |       @optname             |         @address contains         |
  |----------------------------|-----------------------------------|
  | SCTP_SOCKOPT_BINDX_ADD     | One or more ipv4 / ipv6 addresses |
  | SCTP_PRIMARY_ADDR          | Single ipv4 or ipv6 address       |
  | SCTP_SET_PEER_PRIMARY_ADDR | Single ipv4 or ipv6 address       |
  ------------------------------------------------------------------

  ------------------------------------------------------------------
  |                   CONNECT Type Checks                          |
  |       @optname             |         @address contains         |
  |----------------------------|-----------------------------------|
  | SCTP_SOCKOPT_CONNECTX      | One or more ipv4 / ipv6 addresses |
  | SCTP_PARAM_ADD_IP          | One or more ipv4 / ipv6 addresses |
  | SCTP_SENDMSG_CONNECT       | Single ipv4 or ipv6 address       |
  | SCTP_PARAM_SET_PRIMARY     | Single ipv4 or ipv6 address       |
  ------------------------------------------------------------------

A summary of the ``@optname`` entries is as follows::

    SCTP_SOCKOPT_BINDX_ADD - Allows additional bind addresses to be

Annotation

Atlas domain: Support Tooling And Documentation / Documentation.
Implementation status: atlas-only.

Implementation Notes

This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.