Netdev List
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: netdev@vger.kernel.org
Cc: dsahern@gmail.com, Stephen Hemminger <stephen@networkplumber.org>
Subject: [PATCH iproute2] SECURITY: add threat model
Date: Wed,  5 Aug 2026 08:48:07 -0700	[thread overview]
Message-ID: <20260805154807.48866-1-stephen@networkplumber.org> (raw)

Add some new paragraphs to the SECURITY file describing the
threat model. This may help reduce bogus security vulnerability
reports generated by AI.

This text is AI generated mostly for AI consumption.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 SECURITY.md | 73 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 73 insertions(+)

diff --git a/SECURITY.md b/SECURITY.md
index d5a7775f..7e771275 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -12,6 +12,79 @@ and are best handled via
 For other issues please report bugs to netdev@vger.kernel.org
 and include an example script.
 
+Please read the threat model below first. A report should say which
+version or commit was used, and which privilege boundary is crossed:
+who the attacker is, and what they gain that they did not already have.
+Reports that do not identify a boundary will be handled as ordinary bugs
+on the mailing list.
+
+## Threat model
+
+The iproute2 utilities (ip, tc, ss, bridge, devlink, rdma, dcb and the
+rest) are ordinary command line programs. They run with the credentials
+of the invoking user, and they should not be installed setuid or setgid.
+
+Privileged operations are not performed by these programs. They are
+performed by the kernel, which does its own capability check
+(CAP_NET_ADMIN and friends) on the netlink socket. There is no privilege
+boundary inside any iproute2 binary. Anything a user can make iproute2 do
+through command line arguments, environment variables, or its own
+configuration files, that user could already do with a program they wrote
+themselves.
+
+The boundary that does exist is data arriving from the kernel: netlink
+replies and dumps, and procfs and sysfs content. That data may be
+truncated, of unexpected type or length, or contain names chosen by
+unprivileged users in another namespace.
+
+### In scope
+
+- Out of bounds access, memory corruption, or unbounded allocation while
+  parsing netlink, procfs or sysfs data.
+- Unsafe file handling (symlink following, TOCTOU) on paths that a less
+  privileged user can influence, for example under the netns run
+  directory.
+
+### Serious, but not usually a vulnerability
+
+These are fixed with priority, and are reported to netdev like any other
+bug. A CVE is unlikely because no privilege boundary is crossed.
+
+- A command that misreports state, or that silently applies something
+  other than what was requested. An operator may believe a route, rule or
+  filter is installed when it is not. The case where the result is more
+  permissive than requested gets the most attention.
+- "ip netns exec", "ip vrf exec" and similar failing to establish the
+  intended environment before exec, so the child runs somewhere other
+  than where the operator expected. The caller was already privileged, so
+  this is a containment failure rather than an escalation.
+- Monitor commands (ip monitor, tc monitor, bridge monitor, ss) aborting
+  or looping on unexpected, truncated or unknown netlink messages. These
+  are long lived and consume events generated elsewhere on the system, so
+  losing one is a monitoring gap.
+
+### Not in scope
+
+- Anything reached only through the command line. Crashes, overflows,
+  assertion failures and format string issues reached through argv are
+  bugs to be fixed, not vulnerabilities, because the caller already has
+  the privileges of the process.
+- Anything requiring root or CAP_NET_ADMIN to trigger. That is a trusted
+  caller.
+- Anything requiring write access to /etc/iproute2, to the binaries, or
+  to the library path. That is root already.
+- Memory not freed before exit. These are short lived processes.
+- sudo or doas rules that grant ip, tc or bridge. Granting those is
+  equivalent to granting root by design: "ip netns exec" and "tc exec"
+  run arbitrary commands, and the -batch option reads a file of them.
+- File capabilities applied to iproute2 binaries. This creates a
+  privilege boundary that does not otherwise exist and is not supported.
+- Terminal escape sequences in names originating from the kernel. Output
+  is not sanitized for terminals. Use -json if the consumer is not a
+  human.
+- Static analysis or language model output with no reproducer and no
+  identified attacker.
+
 ## Supported Versions
 
 There are no official "Long Term Support" versions for iproute2.
-- 
2.53.0


             reply	other threads:[~2026-08-05 15:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-05 15:48 Stephen Hemminger [this message]
2026-08-07  3:00 ` [PATCH iproute2] SECURITY: add threat model patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260805154807.48866-1-stephen@networkplumber.org \
    --to=stephen@networkplumber.org \
    --cc=dsahern@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox