| Message ID | d1e2488f-a969-30d4-5023-6fa85a4e3833@I-love.SAKURA.ne.jp (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | fs: Allow opening only regular files during execve(). | expand |
On Mon, Jan 21, 2019 at 11:15 PM Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote: > > On Tue, Dec 12, 2017 at 2:06 PM, Eric Biggers <ebiggers3@gmail.com> wrote: > > I'm not sure what the fix will be. Maybe the proc handlers should take a > > different lock instead of cred_guard_mutex. Or perhaps execve should check that > > the file is a regular file before it attempts to open it. > > We can easily distinguish open() from execve() and open() from others. ;-) > > From a8c559566f743eeec31c3cf5bab7a90b1ff7f78b Mon Sep 17 00:00:00 2001 > From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> > Date: Mon, 21 Jan 2019 13:55:11 +0900 > Subject: [PATCH] fs: Allow opening only regular files during execve(). > > syzbot is hitting lockdep warning [1] due to trying to open a fifo during > an execve() operation. But we don't need to open non regular files during > an execve() operation, for all files which we will need are the executable > file itself, the interpreter program, and libraries like ld-linux.so.2 > required by the executable file or the interpreter program. > > Since the manpage for execve(2) says that execve() returns EACCES when > the file or a script interpreter is not a regular file, and we set > current->in_execve flag during an execve() operation, let's bail out > when current thread tried to open a non regular file during an execve() > operation. > > [1] https://syzkaller.appspot.com/bug?id=b5095bfec44ec84213bac54742a82483aad578ce > > Reported-by: syzbot <syzbot+e93a80c1bb7c5c56e522461c149f8bf55eab1b2b@syzkaller.appspotmail.com> > Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> I like it! Acked-by: Kees Cook <keescook@chromium.org> -Kees > --- > fs/open.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/fs/open.c b/fs/open.c > index 0285ce7dbd51..b2e7b04ade46 100644 > --- a/fs/open.c > +++ b/fs/open.c > @@ -733,6 +733,12 @@ static int do_dentry_open(struct file *f, > return 0; > } > > + /* The file or a script interpreter has to be a regular file. */ > + if (unlikely(current->in_execve && !S_ISREG(inode->i_mode))) { > + error = -EACCES; > + goto cleanup_file; > + } > + > if (f->f_mode & FMODE_WRITE && !special_file(inode->i_mode)) { > error = get_write_access(inode); > if (unlikely(error)) > -- > 2.17.1
On Mon, Jan 21, 2019 at 07:14:39PM +0900, Tetsuo Handa wrote: > On Tue, Dec 12, 2017 at 2:06 PM, Eric Biggers <ebiggers3@gmail.com> wrote: > > I'm not sure what the fix will be. Maybe the proc handlers should take a > > different lock instead of cred_guard_mutex. Or perhaps execve should check that > > the file is a regular file before it attempts to open it. > > We can easily distinguish open() from execve() and open() from others. ;-) > + /* The file or a script interpreter has to be a regular file. */ > + if (unlikely(current->in_execve && !S_ISREG(inode->i_mode))) { > + error = -EACCES; > + goto cleanup_file; > + } We are *NOT* going to use current->in_execve to propagate that information. Come up with a cleaner solution, if you care, but this one is a non-starter. Too ugly to live. Sorry.
On Tue, Jan 22, 2019 at 10:18 AM Al Viro <viro@zeniv.linux.org.uk> wrote: > > On Mon, Jan 21, 2019 at 07:14:39PM +0900, Tetsuo Handa wrote: > > On Tue, Dec 12, 2017 at 2:06 PM, Eric Biggers <ebiggers3@gmail.com> wrote: > > > I'm not sure what the fix will be. Maybe the proc handlers should take a > > > different lock instead of cred_guard_mutex. Or perhaps execve should check that > > > the file is a regular file before it attempts to open it. > > > > We can easily distinguish open() from execve() and open() from others. ;-) > > > + /* The file or a script interpreter has to be a regular file. */ > > + if (unlikely(current->in_execve && !S_ISREG(inode->i_mode))) { > > + error = -EACCES; > > + goto cleanup_file; > > + } > > We are *NOT* going to use current->in_execve to propagate that information. > Come up with a cleaner solution, if you care, but this one is a non-starter. > Too ugly to live. Sorry. What would you suggest for a cleaner indication of being in an execve?
diff --git a/fs/open.c b/fs/open.c index 0285ce7dbd51..b2e7b04ade46 100644 --- a/fs/open.c +++ b/fs/open.c @@ -733,6 +733,12 @@ static int do_dentry_open(struct file *f, return 0; } + /* The file or a script interpreter has to be a regular file. */ + if (unlikely(current->in_execve && !S_ISREG(inode->i_mode))) { + error = -EACCES; + goto cleanup_file; + } + if (f->f_mode & FMODE_WRITE && !special_file(inode->i_mode)) { error = get_write_access(inode); if (unlikely(error))