From: Michael Kerrisk <mtk.manpages@gmail.com>
Date: Fri, 16 Oct 2020 09:02:08 +0000 (+0200)
Subject: seccomp_user_notif.2: EXAMPLE: ensure path read() by the supervisor is null-terminated
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=315d5bf84cdc338205f2fdb002f7d69c3b35a97f;p=thirdparty%2Fman-pages.git

seccomp_user_notif.2: EXAMPLE: ensure path read() by the supervisor is null-terminated

From a conversation with Jann Horn:

    >> We should probably make sure here that the value we read is actually
    >> NUL-terminated?
    >
    > So, I was curious about that point also. But, (why) are we not
    > guaranteed that it will be NUL-terminated?

    Because it's random memory filled by another process, which we don't
    necessarily trust. While seccomp notifiers aren't usable for applying
    *extra* security restrictions, the supervisor will still often be more
    privileged than the supervised process.

Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
---

diff --git a/man2/seccomp_user_notif.2 b/man2/seccomp_user_notif.2
index 67e83bde12..b04201148c 100644
--- a/man2/seccomp_user_notif.2
+++ b/man2/seccomp_user_notif.2
@@ -1245,6 +1245,17 @@ getTargetPathname(struct seccomp_notif *req, int notifyFd,
         exit(EXIT_FAILURE);
     }
 
+    /* We have no guarantees about what was in the memory of the target
+       process. Therefore, we ensure that \(aqpath\(aq is null\-terminated.
+       Such precautions are particularly important in cases where (as is
+       common) the surpervisor is running at a higher privilege level
+       than the target. */
+
+    int zeroIdx = len \- 1;
+    if (s < zeroIdx)
+	zeroIdx = s;
+    path[zeroIdx] = \(aq\0\(aq;
+
     if (close(procMemFd) == \-1)
         errExit("close\-/proc/PID/mem");
 }