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 67e83bde12fbb027d3f483826bc005c2f304ed40..b04201148c00a2be8dc716fe44af0220fe2de755 100644 (file)
--- 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");
 }