From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> To: Greg KH <greg@kroah.com> Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>, "Eric W. Biederman" <ebiederm@xmission.com>, Linus Torvalds <torvalds@linux-foundation.org>, Kees Cook <keescook@chromium.org>, Andrew Morton <akpm@linux-foundation.org>, Alexei Starovoitov <ast@kernel.org>, David Miller <davem@davemloft.net>, Al Viro <viro@zeniv.linux.org.uk>, bpf <bpf@vger.kernel.org>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Jakub Kicinski <kuba@kernel.org>, Masahiro Yamada <yamada.masahiro@socionext.com>, Gary Lin <GLin@suse.com>, Bruno Meneguele <bmeneg@redhat.com>, linux-security-module <linux-security-module@vger.kernel.org>, Casey Schaufler <casey@schaufler-ca.com> Subject: Re: [RFC][PATCH] net/bpfilter: Remove this broken and apparently unmantained Date: Thu, 25 Jun 2020 20:03:26 +0900 Message-ID: <778297d2-512a-8361-cf05-42d9379e6977@i-love.sakura.ne.jp> (raw) In-Reply-To: <20200625095725.GA3303921@kroah.com> On 2020/06/25 18:57, Greg KH wrote: > On Thu, Jun 25, 2020 at 03:38:14PM +0900, Tetsuo Handa wrote: >> My questions are: >> >> (1) "Signed and in-tree kernel module" assertion is pointless. >> In future, some of in-tree kernel modules might start using fork_usermode_blob() >> instead of call_usermodehelper(), with instructions containing what your initial >> use case does not use. There is no guarantee that such thing can't happen. > > I hope that this would happen for some tools, what's wrong with that? > That means we can ship those programs from within the kernel source tree > instead of trying to rely on keeping a specific user/kernel api stable > for forever. > > That would be a good thing, right? Some in-tree users might start embedding byte array containing userspace programs like /bin/sh when building kernels. How can we prove that such thing won't happen? I consider that the byte array can contain arbitrary instructions (regardless of some tools used for building the byte array). > >> Assuming that there will be multiple blobs, we need a way to identify these blobs. >> How does fork_usermode_blob() provide information for identification? > > If the kernel itself was running these blobs, why would LSM care about > it? These are coming from "within the building!" don't you trust the > kernel already? > > I don't understand the issue here. The byte array came from the kernel, but due to possibility of "root can poke into kernel or any process memory.", that byte array can become as untrusted as byte array coming from userspace. There is no concept like "the kernel itself _is_ running these blobs". Only a fact "the byte array _was_ copied from the kernel address space (rather than from some file on the filesystem)" exists. We need a mechanism (ideally, without counting on LSMs) for avoid peeking/poking etc. into/from the byte array which was copied from the kernel address space to user address space. >> call_usermodehelper() can teach LSM modules via pre-existing file's pathname and >> inode's security label at security_bprm_creds_for_exec()/security_bprm_check() etc. >> But since fork_usermode_blob() accepts only "byte array" and "length of byte array" >> arguments, I'm not sure whether LSM modules can obtain information needed for >> inspection. How does fork_usermode_blob() tell that information? > > It would seem that the "security context" for those would be the same as > anything created before userspace launches today, right? You handle > that ok, and this should be just the same. I don't think so. Today when call_usermodehelper() is called, LSMs switch their security context (at least TOMOYO does it) for further syscalls from the usermode process started by the kernel context. But when fork_usermode_blob() is called, how LSMs can switch their security context for further syscalls from the usermode process started by the kernel context? > > But again, as these programs are coming from "within the kernel", why > would you want to disallow them? If you don't want to allow them, don't > build them into your kernel? :) I'm talking about not only "disallow unauthorized execve() request" but also "disallow unauthorized syscalls after execve() request". Coming from the kernel is not important. >> Thus, LSM modules (including pathname based security) want to control how that byte >> array can behave. And how does fork_usermode_blob() tell necessary information? > > Think of these blobs just as any other kernel module would be today. No, I can't. How can we guarantee that the byte array came from kernel remains intact despite the possibility of "root can poke into kernel or any process memory" ? > Right now I, as a kernel module, can read/write to any file in the > system, and do all sorts of other fun things. You can't mediate that > today from a LSM, and this is just one other example of this. Some functions (e.g. kernel_sock_shutdown()) bypass permission checks by LSMs comes from a sort of trustness that the byte array kept inside kernel address space remains secure/intact. > > The "only" change is that now this code is running in userspace context, > which for an overall security/system issue, should be better than > running it in kernel context, right? As soon as exposing that byte array outside of kernel address space, processes running such byte array are considered insecure/tampered. We can't prove that the byte array exposed to outside of kernel address space does only limited set of instructions, and we have to perform permission checks by LSMs. And LSMs need to receive the intent (or "security context" argument) from fork_usermode_blob() for restricting further syscalls by the usermode process started via fork_usermode_blob(). > > Perhaps we just add new LSM hooks for every place that we call this new > function to run a blob? That will give you the needed "the kernel is > about to run a blob that we think is a userspace USB IR filter driver", > or whatever the blob does. Yes, that would be the intent (or "security context" argument) fork_usermode_blob() is missing. Though I don't know how such stringuish argument can be represented for individual LSM modules...
next prev parent reply index Thread overview: 193+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <20200329005528.xeKtdz2A0%akpm@linux-foundation.org> [not found] ` <13fb3ab7-9ab1-b25f-52f2-40a6ca5655e1@i-love.sakura.ne.jp> [not found] ` <202006051903.C44988B@keescook> 2020-06-06 19:20 ` Eric W. Biederman 2020-06-06 20:19 ` Alexei Starovoitov 2020-06-06 22:33 ` Linus Torvalds 2020-06-07 1:49 ` Alexei Starovoitov 2020-06-07 2:19 ` Linus Torvalds 2020-06-07 16:09 ` Eric W. Biederman 2020-06-08 16:20 ` Alexei Starovoitov 2020-06-08 16:40 ` Greg KH 2020-06-08 18:35 ` Kees Cook 2020-06-09 1:26 ` Alexei Starovoitov 2020-06-09 15:37 ` Kees Cook 2020-06-09 19:51 ` Eric W. Biederman 2020-06-07 2:31 ` Tetsuo Handa 2020-06-08 16:23 ` Alexei Starovoitov 2020-06-08 23:22 ` Tetsuo Handa 2020-06-09 1:28 ` Alexei Starovoitov 2020-06-09 5:29 ` Tetsuo Handa 2020-06-09 22:32 ` Alexei Starovoitov 2020-06-09 23:30 ` Tetsuo Handa 2020-06-10 0:05 ` Alexei Starovoitov 2020-06-10 3:08 ` Tetsuo Handa 2020-06-10 3:32 ` Alexei Starovoitov 2020-06-10 7:30 ` Tetsuo Handa 2020-06-10 16:24 ` Casey Schaufler 2020-06-09 20:02 ` Eric W. Biederman 2020-06-09 23:56 ` Alexei Starovoitov 2020-06-10 21:12 ` Eric W. Biederman 2020-06-11 23:31 ` Alexei Starovoitov 2020-06-12 0:57 ` Tetsuo Handa 2020-06-13 3:38 ` Alexei Starovoitov 2020-06-13 4:22 ` Tetsuo Handa 2020-06-13 14:08 ` Eric W. Biederman 2020-06-13 15:33 ` Alexei Starovoitov 2020-06-13 16:14 ` Alexei Starovoitov 2020-06-14 14:51 ` Eric W. Biederman 2020-06-16 1:55 ` Alexei Starovoitov 2020-06-16 16:21 ` Alexei Starovoitov 2020-06-23 18:04 ` Eric W. Biederman 2020-06-23 18:35 ` Alexei Starovoitov 2020-06-23 18:53 ` Eric W. Biederman 2020-06-23 19:40 ` Alexei Starovoitov 2020-06-24 1:51 ` Tetsuo Handa 2020-06-24 4:00 ` Alexei Starovoitov 2020-06-24 4:58 ` Tetsuo Handa 2020-06-24 6:39 ` Alexei Starovoitov 2020-06-24 7:05 ` Tetsuo Handa 2020-06-24 15:41 ` Casey Schaufler 2020-06-24 17:54 ` Alexei Starovoitov 2020-06-24 19:48 ` Casey Schaufler 2020-06-24 6:05 ` Alexei Starovoitov 2020-06-24 14:18 ` Alexei Starovoitov 2020-06-24 12:13 ` Eric W. Biederman 2020-06-24 14:26 ` Alexei Starovoitov 2020-06-24 23:14 ` Tetsuo Handa 2020-06-25 1:35 ` Alexei Starovoitov 2020-06-25 6:38 ` Tetsuo Handa 2020-06-25 9:57 ` Greg KH 2020-06-25 11:03 ` Tetsuo Handa [this message] 2020-06-25 12:07 ` Greg KH 2020-06-25 14:21 ` Tetsuo Handa 2020-06-25 19:34 ` David Miller 2020-06-26 1:36 ` Linus Torvalds 2020-06-26 1:51 ` Alexei Starovoitov 2020-06-26 4:58 ` Tetsuo Handa 2020-06-26 5:41 ` Alexei Starovoitov 2020-06-26 6:20 ` Tetsuo Handa 2020-06-26 6:39 ` Alexei Starovoitov 2020-06-26 12:51 ` [PATCH 00/14] Make the user mode driver code a better citizen Eric W. Biederman 2020-06-26 12:53 ` [PATCH 01/14] umh: Capture the pid in umh_pipe_setup Eric W. Biederman 2020-06-26 12:53 ` [PATCH 02/14] umh: Move setting PF_UMH into umh_pipe_setup Eric W. Biederman 2020-06-26 12:54 ` [PATCH 03/14] umh: Rename the user mode driver helpers for clarity Eric W. Biederman 2020-06-26 12:54 ` [PATCH 04/14] umh: Remove call_usermodehelper_setup_file Eric W. Biederman 2020-06-26 12:55 ` [PATCH 05/14] umh: Separate the user mode driver and the user mode helper support Eric W. Biederman 2020-06-26 16:22 ` Tetsuo Handa 2020-06-26 16:45 ` Eric W. Biederman 2020-06-27 1:26 ` Tetsuo Handa 2020-06-27 4:21 ` Eric W. Biederman 2020-06-27 4:36 ` Tetsuo Handa 2020-06-26 12:55 ` [PATCH 06/14] umd: For clarity rename umh_info umd_info Eric W. Biederman 2020-06-26 15:37 ` Kees Cook 2020-06-26 16:31 ` Eric W. Biederman 2020-06-26 12:56 ` [PATCH 07/14] umd: Rename umd_info.cmdline umd_info.driver_name Eric W. Biederman 2020-06-26 12:56 ` [PATCH 08/14] umd: Transform fork_usermode_blob into fork_usermode_driver Eric W. Biederman 2020-06-26 12:57 ` [PATCH 09/14] umh: Stop calling do_execve_file Eric W. Biederman 2020-06-26 12:57 ` [PATCH 10/14] exec: Remove do_execve_file Eric W. Biederman 2020-06-26 12:58 ` [PATCH 11/14] bpfilter: Move bpfilter_umh back into init data Eric W. Biederman 2020-06-26 12:58 ` [PATCH 12/14] umd: Track user space drivers with struct pid Eric W. Biederman 2020-06-26 12:59 ` [PATCH 13/14] bpfilter: Take advantage of the facilities of " Eric W. Biederman 2020-06-26 12:59 ` [PATCH 14/14] umd: Remove exit_umh Eric W. Biederman 2020-06-26 13:48 ` [PATCH 00/14] Make the user mode driver code a better citizen Eric W. Biederman 2020-06-29 19:55 ` [PATCH v2 00/15] " Eric W. Biederman 2020-06-29 19:56 ` [PATCH v2 01/15] umh: Capture the pid in umh_pipe_setup Eric W. Biederman 2020-06-29 19:57 ` [PATCH v2 02/15] umh: Move setting PF_UMH into umh_pipe_setup Eric W. Biederman 2020-06-29 19:57 ` [PATCH v2 03/15] umh: Rename the user mode driver helpers for clarity Eric W. Biederman 2020-06-29 19:59 ` [PATCH v2 04/15] umh: Remove call_usermodehelper_setup_file Eric W. Biederman 2020-06-29 20:00 ` [PATCH v2 05/15] umh: Separate the user mode driver and the user mode helper support Eric W. Biederman 2020-06-30 16:58 ` Linus Torvalds 2020-07-01 17:18 ` Eric W. Biederman 2020-07-01 17:42 ` Alexei Starovoitov 2020-06-29 20:01 ` [PATCH v2 06/15] umd: For clarity rename umh_info umd_info Eric W. Biederman 2020-06-29 20:02 ` [PATCH v2 07/15] umd: Rename umd_info.cmdline umd_info.driver_name Eric W. Biederman 2020-06-29 20:03 ` [PATCH v2 08/15] umd: Transform fork_usermode_blob into fork_usermode_driver Eric W. Biederman 2020-06-29 20:03 ` [PATCH v2 09/15] umh: Stop calling do_execve_file Eric W. Biederman 2020-06-29 20:04 ` [PATCH v2 10/15] exec: Remove do_execve_file Eric W. Biederman 2020-06-30 5:43 ` Christoph Hellwig 2020-06-30 12:14 ` Eric W. Biederman 2020-06-30 13:38 ` Christoph Hellwig 2020-06-30 14:28 ` Eric W. Biederman 2020-06-30 16:55 ` Alexei Starovoitov 2020-06-29 20:05 ` [PATCH v2 11/15] bpfilter: Move bpfilter_umh back into init data Eric W. Biederman 2020-06-29 20:06 ` [PATCH v2 12/15] umd: Track user space drivers with struct pid Eric W. Biederman 2020-06-29 20:06 ` [PATCH v2 13/15] bpfilter: Take advantage of the facilities of " Eric W. Biederman 2020-06-29 20:07 ` [PATCH v2 14/15] umd: Remove exit_umh Eric W. Biederman 2020-06-29 20:08 ` [PATCH v2 15/15] umd: Stop using split_argv Eric W. Biederman 2020-06-29 22:12 ` [PATCH v2 00/15] Make the user mode driver code a better citizen Alexei Starovoitov 2020-06-30 1:13 ` Eric W. Biederman 2020-06-30 6:16 ` Tetsuo Handa 2020-06-30 12:29 ` Eric W. Biederman 2020-06-30 13:21 ` Tetsuo Handa 2020-07-02 13:08 ` Eric W. Biederman 2020-07-02 13:40 ` Tetsuo Handa 2020-07-02 16:02 ` Eric W. Biederman 2020-07-03 13:19 ` Tetsuo Handa 2020-07-03 22:25 ` Eric W. Biederman 2020-07-04 6:57 ` Tetsuo Handa 2020-07-08 4:46 ` Eric W. Biederman 2020-06-30 16:52 ` Alexei Starovoitov 2020-07-01 17:12 ` Eric W. Biederman 2020-07-02 16:40 ` [PATCH v3 00/16] " Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 01/16] umh: Capture the pid in umh_pipe_setup Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 02/16] umh: Move setting PF_UMH into umh_pipe_setup Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 03/16] umh: Rename the user mode driver helpers for clarity Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 04/16] umh: Remove call_usermodehelper_setup_file Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 05/16] umh: Separate the user mode driver and the user mode helper support Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 06/16] umd: For clarity rename umh_info umd_info Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 07/16] umd: Rename umd_info.cmdline umd_info.driver_name Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 08/16] umd: Transform fork_usermode_blob into fork_usermode_driver Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 09/16] umh: Stop calling do_execve_file Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 10/16] exec: Remove do_execve_file Eric W. Biederman 2020-07-08 6:35 ` Luis Chamberlain 2020-07-08 12:41 ` Luis Chamberlain 2020-07-08 13:08 ` Eric W. Biederman 2020-07-08 13:32 ` Luis Chamberlain 2020-07-12 21:02 ` Pavel Machek 2020-07-02 16:41 ` [PATCH v3 11/16] bpfilter: Move bpfilter_umh back into init data Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 12/16] umd: Track user space drivers with struct pid Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 13/16] exit: Factor thread_group_exited out of pidfd_poll Eric W. Biederman 2020-07-03 20:30 ` Alexei Starovoitov 2020-07-03 21:37 ` Eric W. Biederman 2020-07-04 0:03 ` Alexei Starovoitov 2020-07-04 15:50 ` Christian Brauner 2020-07-07 17:09 ` Eric W. Biederman 2020-07-08 0:05 ` Daniel Borkmann 2020-07-08 3:50 ` Eric W. Biederman 2020-07-04 16:00 ` Christian Brauner 2020-07-02 16:41 ` [PATCH v3 14/16] bpfilter: Take advantage of the facilities of struct pid Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 15/16] umd: Remove exit_umh Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 16/16] umd: Stop using split_argv Eric W. Biederman 2020-07-02 23:51 ` [PATCH v3 00/16] Make the user mode driver code a better citizen Tetsuo Handa 2020-07-09 22:05 ` [merged][PATCH " Eric W. Biederman 2020-07-14 19:42 ` Alexei Starovoitov 2020-07-08 5:20 ` [PATCH v2 00/15] " Luis Chamberlain 2020-06-26 14:10 ` [PATCH 00/14] " Greg Kroah-Hartman 2020-06-26 16:40 ` Alexei Starovoitov 2020-06-26 17:17 ` Eric W. Biederman 2020-06-26 18:22 ` Alexei Starovoitov 2020-06-27 11:38 ` Tetsuo Handa 2020-06-27 12:59 ` Eric W. Biederman 2020-06-27 13:57 ` Tetsuo Handa 2020-06-28 19:44 ` Alexei Starovoitov 2020-06-29 2:20 ` Tetsuo Handa 2020-06-29 20:19 ` Eric W. Biederman 2020-06-30 6:28 ` Tetsuo Handa 2020-06-30 12:32 ` Eric W. Biederman 2020-06-30 16:48 ` Alexei Starovoitov 2020-06-30 21:54 ` Tetsuo Handa 2020-06-30 21:57 ` Alexei Starovoitov 2020-06-30 22:58 ` Tetsuo Handa 2020-06-25 12:56 ` [RFC][PATCH] net/bpfilter: Remove this broken and apparently unmantained Stephen Smalley 2020-06-25 13:25 ` Greg Kroah-Hartman 2020-06-25 14:26 ` Stephen Smalley 2020-06-25 14:36 ` Stephen Smalley 2020-06-25 15:21 ` Tetsuo Handa 2020-06-25 16:03 ` Stephen Smalley 2020-06-25 16:06 ` Casey Schaufler 2020-06-26 11:30 ` Eric W. Biederman 2020-06-07 5:58 ` Eric W. Biederman 2020-06-07 11:56 ` Eric W. Biederman 2020-06-08 16:35 ` Alexei Starovoitov 2020-06-08 16:33 ` Alexei Starovoitov 2020-06-06 20:43 ` Matthew Wilcox 2020-06-07 15:51 ` Eric W. Biederman 2020-06-07 1:13 ` Tetsuo Handa
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=778297d2-512a-8361-cf05-42d9379e6977@i-love.sakura.ne.jp \ --to=penguin-kernel@i-love.sakura.ne.jp \ --cc=GLin@suse.com \ --cc=akpm@linux-foundation.org \ --cc=alexei.starovoitov@gmail.com \ --cc=ast@kernel.org \ --cc=bmeneg@redhat.com \ --cc=bpf@vger.kernel.org \ --cc=casey@schaufler-ca.com \ --cc=daniel@iogearbox.net \ --cc=davem@davemloft.net \ --cc=ebiederm@xmission.com \ --cc=greg@kroah.com \ --cc=keescook@chromium.org \ --cc=kuba@kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=torvalds@linux-foundation.org \ --cc=viro@zeniv.linux.org.uk \ --cc=yamada.masahiro@socionext.com \ /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
Linux-Fsdevel Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \ linux-fsdevel@vger.kernel.org public-inbox-index linux-fsdevel Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git