Messages in this thread | | | From | Kees Cook <> | Date | Tue, 28 Nov 2017 14:18:18 -0800 | Subject | Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap() |
| |
On Tue, Nov 28, 2017 at 2:12 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote: > On Tue, Nov 28, 2017 at 01:39:58PM -0800, Kees Cook wrote: >> On Tue, Nov 28, 2017 at 1:16 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote: >> > And *all* auto-loading uses aliases? What's the difference between auto-loading >> > and direct-loading? >> >> The difference is the process privileges. Unprivilged autoloading >> (e.g. int n_hdlc = N_HDLC; ioctl(fd, >> TIOCSETD, &n_hdlc)), triggers a privileged call to finit_module() >> under CAP_SYS_MODULE. > > Ah, so system call implicated request_module() calls.
Yup. Unprivileged user does something that ultimately hits a request_module() in the kernel. Then the kernel calls out with the usermode helper (which has CAP_SYS_MODULE) and calls finit_module().
> OK and since CAP_SYS_MODULE is much more restrictive one could argue, what's the > point here?
The goal is to block an unprivileged user from being able to trigger a module load without blocking root from loading modules directly.
-Kees
-- Kees Cook Pixel Security
| |