diff for duplicates of <20240806-work-procfs-v1-0-fb04e1d09f0c@kernel.org> diff --git a/a/1.txt b/N1/1.txt index c74cfe5..0cc7d1e 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,121 +1,72 @@ -(Preface because I've been panick-approached by people at conference - when we discussed this before: overmounting any global procfs files - such as /proc/status remains unaffected and is an existing and - supported use-case.) - -It is currently possible to mount on top of various ephemeral entities -in procfs. This specifically includes magic links. To recap, magic links -are links of the form /proc/<pid>/fd/<nr>. They serve as references to -a target file and during path lookup they cause a jump to the target -path. Such magic links disappear if the corresponding file descriptor is -closed. - -Currently it is possible to overmount such magic links: - -int fd = open("/mnt/foo", O_RDONLY); -sprintf(path, "/proc/%d/fd/%d", getpid(), fd); -int fd2 = openat(AT_FDCWD, path, O_PATH | O_NOFOLLOW); -mount("/mnt/bar", path, "", MS_BIND, 0); - -Arguably, this is nonsensical and is mostly interesting for an attacker -that wants to somehow trick a process into e.g., reopening something -that they didn't intend to reopen or to hide a malicious file -descriptor. - -But also it risks leaking mounts for long-running processes. When -overmounting a magic link like above, the mount will not be detached -when the file descriptor is closed. Only the target mountpoint will -disappear. Which has the consequence of making it impossible to unmount -that mount afterwards. So the mount will stick around until the process -exits and the /proc/<pid>/ directory is cleaned up during -proc_flush_pid() when the dentries are pruned and invalidated. - -That in turn means it's possible for a program to accidentally leak -mounts and it's also possible to make a task leak mounts without it's -knowledge if the attacker just keeps overmounting things under -/proc/<pid>/fd/<nr>. - -I think it's wrong to try and fix this by us starting to play games with -close() or somewhere else to undo these mounts when the file descriptor -is closed. The fact that we allow overmounting of such magic links is -simply a bug and one that we need to fix. - -Similar things can be said about entries under fdinfo/ and map_files/ so -those are restricted as well. - -I have a further more aggressive patch that gets out the big hammer and -makes everything under /proc/<pid>/*, as well as immediate symlinks such -as /proc/self, /proc/thread-self, /proc/mounts, /proc/net that point -into /proc/<pid>/ not overmountable. Imho, all of this should be blocked -if we can get away with it. It's only useful to hide exploits such as in [1]. - -And again, overmounting of any global procfs files remains unaffected -and is an existing and supported use-case. - -Link: https://righteousit.com/2024/07/24/hiding-linux-processes-with-bind-mounts [1] - -// Note that repro uses the traditional way of just mounting over -// /proc/<pid>/fd/<nr>. This could also all be achieved just based on -// file descriptors using move_mount(). So /proc/<pid>/fd/<nr> isn't the -// only entry vector here. It's also possible to e.g., mount directly -// onto /proc/<pid>/map_files/* without going over /proc/<pid>/fd/<nr>. -int main(int argc, char *argv[]) -{ - char path[PATH_MAX]; - - creat("/mnt/foo", 0777); - creat("/mnt/bar", 0777); - - /* - * For illustration use a bunch of file descriptors in the upper - * range that are unused. - */ - for (int i = 10000; i >= 256; i--) { - printf("I'm: /proc/%d/\n", getpid()); - - int fd2 = open("/mnt/foo", O_RDONLY); - if (fd2 < 0) { - printf("%m - Failed to open\n"); - _exit(1); - } - - int newfd = dup2(fd2, i); - if (newfd < 0) { - printf("%m - Failed to dup\n"); - _exit(1); - } - close(fd2); - - sprintf(path, "/proc/%d/fd/%d", getpid(), newfd); - int fd = openat(AT_FDCWD, path, O_PATH | O_NOFOLLOW); - if (fd < 0) { - printf("%m - Failed to open\n"); - _exit(3); - } - - sprintf(path, "/proc/%d/fd/%d", getpid(), fd); - printf("Mounting on top of %s\n", path); - if (mount("/mnt/bar", path, "", MS_BIND, 0)) { - printf("%m - Failed to mount\n"); - _exit(4); - } - - close(newfd); - close(fd2); - } - - /* - * Give some time to look at things. The mounts now linger until - * the process exits. - */ - sleep(10000); - _exit(0); -} - -Co-developed-by: Aleksa Sarai <cyphar@cyphar.com> -Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> -Signed-off-by: Christian Brauner <brauner@kernel.org> ---- ---- -base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b -change-id: 20240731-work-procfs-e82dd889b773 +From: Christian Brauner <brauner@kernel.org> + +Hi Christian, all, + +> (Preface because I've been panick-approached by people at conference +> when we discussed this before: overmounting any global procfs files +> such as /proc/status remains unaffected and is an existing and +> supported use-case.) + +> It is currently possible to mount on top of various ephemeral entities +> in procfs. This specifically includes magic links. To recap, magic links +> are links of the form /proc/<pid>/fd/<nr>. They serve as references to +> a target file and during path lookup they cause a jump to the target +> path. Such magic links disappear if the corresponding file descriptor is +> closed. + +> Currently it is possible to overmount such magic links: + +> int fd = open("/mnt/foo", O_RDONLY); +> sprintf(path, "/proc/%d/fd/%d", getpid(), fd); +> int fd2 = openat(AT_FDCWD, path, O_PATH | O_NOFOLLOW); +> mount("/mnt/bar", path, "", MS_BIND, 0); + +> Arguably, this is nonsensical and is mostly interesting for an attacker +> that wants to somehow trick a process into e.g., reopening something +> that they didn't intend to reopen or to hide a malicious file +> descriptor. + +> But also it risks leaking mounts for long-running processes. When +> overmounting a magic link like above, the mount will not be detached +> when the file descriptor is closed. Only the target mountpoint will +> disappear. Which has the consequence of making it impossible to unmount +> that mount afterwards. So the mount will stick around until the process +> exits and the /proc/<pid>/ directory is cleaned up during +> proc_flush_pid() when the dentries are pruned and invalidated. + +> That in turn means it's possible for a program to accidentally leak +> mounts and it's also possible to make a task leak mounts without it's +> knowledge if the attacker just keeps overmounting things under +> /proc/<pid>/fd/<nr>. + +> I think it's wrong to try and fix this by us starting to play games with +> close() or somewhere else to undo these mounts when the file descriptor +> is closed. The fact that we allow overmounting of such magic links is +> simply a bug and one that we need to fix. + +> Similar things can be said about entries under fdinfo/ and map_files/ so +> those are restricted as well. + +> I have a further more aggressive patch that gets out the big hammer and +> makes everything under /proc/<pid>/*, as well as immediate symlinks such +> as /proc/self, /proc/thread-self, /proc/mounts, /proc/net that point +> into /proc/<pid>/ not overmountable. Imho, all of this should be blocked +> if we can get away with it. It's only useful to hide exploits such as in [1]. + +> And again, overmounting of any global procfs files remains unaffected +> and is an existing and supported use-case. + +> Link: https://righteousit.com/2024/07/24/hiding-linux-processes-with-bind-mounts [1] + +this is fixing a security issue, right? Wouldn't it be worth to backport these +commits to active stable/LTS kernels. I guess it was considered as a new feature +that's why it was not backported (looking at 6.11, 6.6 and 6.1). + +Kind regards, +Petr + +... + +> Co-developed-by: Aleksa Sarai <cyphar@cyphar.com> +> Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> +> Signed-off-by: Christian Brauner <brauner@kernel.org> diff --git a/a/content_digest b/N1/content_digest index 627e39e..176d9e7 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,134 +1,89 @@ - "From\0Christian Brauner <brauner@kernel.org>\0" + "From\0Petr Vorel <pvorel@suse.cz>\0" "Subject\0[PATCH RFC 0/6] proc: restrict overmounting of ephemeral entities\0" - "Date\0Tue, 06 Aug 2024 18:02:26 +0200\0" - "To\0Linus Torvalds <torvalds@linux-foundation.org>" + "Date\0Tue, 30 Sep 2025 10:53:18 +0200\0" + "To\0brauner@kernel.org" + Linus Torvalds <torvalds@linux-foundation.org> " linux-fsdevel@vger.kernel.org\0" - "Cc\0Alexander Viro <viro@zeniv.linux.org.uk>" - Jan Kara <jack@suse.cz> - Aleksa Sarai <cyphar@cyphar.com> - " Christian Brauner <brauner@kernel.org>\0" + "Cc\0cyphar@cyphar.com" + jack@suse.cz + viro@zeniv.linux.org.uk + Greg Kroah-Hartman <gregkh@linuxfoundation.org> + Sasha Levin <sashal@kernel.org> + Kees Cook <kees@kernel.org> + " Josef Bacik <josef@toxicpanda.com>\0" "\00:1\0" "b\0" - "(Preface because I've been panick-approached by people at conference\n" - " when we discussed this before: overmounting any global procfs files\n" - " such as /proc/status remains unaffected and is an existing and\n" - " supported use-case.)\n" - "\n" - "It is currently possible to mount on top of various ephemeral entities\n" - "in procfs. This specifically includes magic links. To recap, magic links\n" - "are links of the form /proc/<pid>/fd/<nr>. They serve as references to\n" - "a target file and during path lookup they cause a jump to the target\n" - "path. Such magic links disappear if the corresponding file descriptor is\n" - "closed.\n" - "\n" - "Currently it is possible to overmount such magic links:\n" - "\n" - "int fd = open(\"/mnt/foo\", O_RDONLY);\n" - "sprintf(path, \"/proc/%d/fd/%d\", getpid(), fd);\n" - "int fd2 = openat(AT_FDCWD, path, O_PATH | O_NOFOLLOW);\n" - "mount(\"/mnt/bar\", path, \"\", MS_BIND, 0);\n" - "\n" - "Arguably, this is nonsensical and is mostly interesting for an attacker\n" - "that wants to somehow trick a process into e.g., reopening something\n" - "that they didn't intend to reopen or to hide a malicious file\n" - "descriptor.\n" - "\n" - "But also it risks leaking mounts for long-running processes. When\n" - "overmounting a magic link like above, the mount will not be detached\n" - "when the file descriptor is closed. Only the target mountpoint will\n" - "disappear. Which has the consequence of making it impossible to unmount\n" - "that mount afterwards. So the mount will stick around until the process\n" - "exits and the /proc/<pid>/ directory is cleaned up during\n" - "proc_flush_pid() when the dentries are pruned and invalidated.\n" - "\n" - "That in turn means it's possible for a program to accidentally leak\n" - "mounts and it's also possible to make a task leak mounts without it's\n" - "knowledge if the attacker just keeps overmounting things under\n" - "/proc/<pid>/fd/<nr>.\n" - "\n" - "I think it's wrong to try and fix this by us starting to play games with\n" - "close() or somewhere else to undo these mounts when the file descriptor\n" - "is closed. The fact that we allow overmounting of such magic links is\n" - "simply a bug and one that we need to fix.\n" - "\n" - "Similar things can be said about entries under fdinfo/ and map_files/ so\n" - "those are restricted as well.\n" - "\n" - "I have a further more aggressive patch that gets out the big hammer and\n" - "makes everything under /proc/<pid>/*, as well as immediate symlinks such\n" - "as /proc/self, /proc/thread-self, /proc/mounts, /proc/net that point\n" - "into /proc/<pid>/ not overmountable. Imho, all of this should be blocked\n" - "if we can get away with it. It's only useful to hide exploits such as in [1].\n" - "\n" - "And again, overmounting of any global procfs files remains unaffected\n" - "and is an existing and supported use-case.\n" - "\n" - "Link: https://righteousit.com/2024/07/24/hiding-linux-processes-with-bind-mounts [1]\n" - "\n" - "// Note that repro uses the traditional way of just mounting over\n" - "// /proc/<pid>/fd/<nr>. This could also all be achieved just based on\n" - "// file descriptors using move_mount(). So /proc/<pid>/fd/<nr> isn't the\n" - "// only entry vector here. It's also possible to e.g., mount directly\n" - "// onto /proc/<pid>/map_files/* without going over /proc/<pid>/fd/<nr>.\n" - "int main(int argc, char *argv[])\n" - "{\n" - " char path[PATH_MAX];\n" - "\n" - " creat(\"/mnt/foo\", 0777);\n" - " creat(\"/mnt/bar\", 0777);\n" - "\n" - " /*\n" - " * For illustration use a bunch of file descriptors in the upper\n" - " * range that are unused.\n" - " */\n" - " for (int i = 10000; i >= 256; i--) {\n" - " printf(\"I'm: /proc/%d/\\n\", getpid());\n" - "\n" - " int fd2 = open(\"/mnt/foo\", O_RDONLY);\n" - " if (fd2 < 0) {\n" - " printf(\"%m - Failed to open\\n\");\n" - " _exit(1);\n" - " }\n" - "\n" - " int newfd = dup2(fd2, i);\n" - " if (newfd < 0) {\n" - " printf(\"%m - Failed to dup\\n\");\n" - " _exit(1);\n" - " }\n" - " close(fd2);\n" - "\n" - " sprintf(path, \"/proc/%d/fd/%d\", getpid(), newfd);\n" - " int fd = openat(AT_FDCWD, path, O_PATH | O_NOFOLLOW);\n" - " if (fd < 0) {\n" - " printf(\"%m - Failed to open\\n\");\n" - " _exit(3);\n" - " }\n" - "\n" - " sprintf(path, \"/proc/%d/fd/%d\", getpid(), fd);\n" - " printf(\"Mounting on top of %s\\n\", path);\n" - " if (mount(\"/mnt/bar\", path, \"\", MS_BIND, 0)) {\n" - " printf(\"%m - Failed to mount\\n\");\n" - " _exit(4);\n" - " }\n" - "\n" - " close(newfd);\n" - " close(fd2);\n" - " }\n" - "\n" - " /*\n" - " * Give some time to look at things. The mounts now linger until\n" - " * the process exits.\n" - " */\n" - " sleep(10000);\n" - " _exit(0);\n" - "}\n" - "\n" - "Co-developed-by: Aleksa Sarai <cyphar@cyphar.com>\n" - "Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>\n" - "Signed-off-by: Christian Brauner <brauner@kernel.org>\n" - "---\n" - "---\n" - "base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b\n" - change-id: 20240731-work-procfs-e82dd889b773 + "From: Christian Brauner <brauner@kernel.org>\n" + "\n" + "Hi Christian, all,\n" + "\n" + "> (Preface because I've been panick-approached by people at conference\n" + "> when we discussed this before: overmounting any global procfs files\n" + "> such as /proc/status remains unaffected and is an existing and\n" + "> supported use-case.)\n" + "\n" + "> It is currently possible to mount on top of various ephemeral entities\n" + "> in procfs. This specifically includes magic links. To recap, magic links\n" + "> are links of the form /proc/<pid>/fd/<nr>. They serve as references to\n" + "> a target file and during path lookup they cause a jump to the target\n" + "> path. Such magic links disappear if the corresponding file descriptor is\n" + "> closed.\n" + "\n" + "> Currently it is possible to overmount such magic links:\n" + "\n" + "> int fd = open(\"/mnt/foo\", O_RDONLY);\n" + "> sprintf(path, \"/proc/%d/fd/%d\", getpid(), fd);\n" + "> int fd2 = openat(AT_FDCWD, path, O_PATH | O_NOFOLLOW);\n" + "> mount(\"/mnt/bar\", path, \"\", MS_BIND, 0);\n" + "\n" + "> Arguably, this is nonsensical and is mostly interesting for an attacker\n" + "> that wants to somehow trick a process into e.g., reopening something\n" + "> that they didn't intend to reopen or to hide a malicious file\n" + "> descriptor.\n" + "\n" + "> But also it risks leaking mounts for long-running processes. When\n" + "> overmounting a magic link like above, the mount will not be detached\n" + "> when the file descriptor is closed. Only the target mountpoint will\n" + "> disappear. Which has the consequence of making it impossible to unmount\n" + "> that mount afterwards. So the mount will stick around until the process\n" + "> exits and the /proc/<pid>/ directory is cleaned up during\n" + "> proc_flush_pid() when the dentries are pruned and invalidated.\n" + "\n" + "> That in turn means it's possible for a program to accidentally leak\n" + "> mounts and it's also possible to make a task leak mounts without it's\n" + "> knowledge if the attacker just keeps overmounting things under\n" + "> /proc/<pid>/fd/<nr>.\n" + "\n" + "> I think it's wrong to try and fix this by us starting to play games with\n" + "> close() or somewhere else to undo these mounts when the file descriptor\n" + "> is closed. The fact that we allow overmounting of such magic links is\n" + "> simply a bug and one that we need to fix.\n" + "\n" + "> Similar things can be said about entries under fdinfo/ and map_files/ so\n" + "> those are restricted as well.\n" + "\n" + "> I have a further more aggressive patch that gets out the big hammer and\n" + "> makes everything under /proc/<pid>/*, as well as immediate symlinks such\n" + "> as /proc/self, /proc/thread-self, /proc/mounts, /proc/net that point\n" + "> into /proc/<pid>/ not overmountable. Imho, all of this should be blocked\n" + "> if we can get away with it. It's only useful to hide exploits such as in [1].\n" + "\n" + "> And again, overmounting of any global procfs files remains unaffected\n" + "> and is an existing and supported use-case.\n" + "\n" + "> Link: https://righteousit.com/2024/07/24/hiding-linux-processes-with-bind-mounts [1]\n" + "\n" + "this is fixing a security issue, right? Wouldn't it be worth to backport these\n" + "commits to active stable/LTS kernels. I guess it was considered as a new feature\n" + "that's why it was not backported (looking at 6.11, 6.6 and 6.1).\n" + "\n" + "Kind regards,\n" + "Petr\n" + "\n" + "...\n" + "\n" + "> Co-developed-by: Aleksa Sarai <cyphar@cyphar.com>\n" + "> Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>\n" + > Signed-off-by: Christian Brauner <brauner@kernel.org> -108fb59b7dfd7eee8bcbd9471f8662fa4d3393805b9cbb0b12c1d65d74fb6b15 +429211146818a0af7bab0ef31d97be82e45cff2adc984ed7407a0d03c0f71ee2
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.