linux-kernel - Re: [PATCH v2] fs: Allow opening only regular files during execve().

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 19 Feb 2019 18:51:49 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Eric Biggers <ebiggers3@...il.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Kees Cook <keescook@...omium.org>,
        syzbot 
        <bot+e93a80c1bb7c5c56e522461c149f8bf55eab1b2b@...kaller.appspotmail.com>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: [PATCH v2] fs: Allow opening only regular files during execve().

Hello, Al.

What would you suggest if FMODE_EXEC is not the right choice?

On 2019/01/22 9:51, Kees Cook wrote:
> On Tue, Jan 22, 2019 at 10:18 AM Al Viro <viro@...iv.linux.org.uk> wrote:
>> 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?
> 

On 2019/02/12 14:26, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
>> Andrew Morton wrote:
>>>> --- a/fs/open.c
>>>> +++ b/fs/open.c
>>>> @@ -733,6 +733,12 @@ static int do_dentry_open(struct file *f,
>>>>  		return 0;
>>>>  	}
>>>>  
>>>> +	/* Any file opened for execve()/uselib() has to be a regular file. */
>>>> +	if (unlikely(f->f_flags & FMODE_EXEC && !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))
>>>
>>> This change sounds legitimate for various other reasons, but it's a
>>> concern that this locking error occurred in the first place.  There's a
>>> problem somewhere (probably the pipe code) which may bite us in other
>>> situations, even with this workaround in place.
>>>
>>>
>>
>> This error seems to be introduced in 2.6.39-rc1 by commit a9712bc12c40c172
>> ("deal with races in /proc/*/{syscall,stack,personality}"). Thus, I don't
>> think that this patch will bite us in other situations.
>> Al, how do you want to handle this?
>>
> 
> According to bisection, commit 8924feff66f35fe2 ("splice: lift pipe_lock out of splice_to_pipe()")
> added in 4.9-rc1 is the trigger of this deadlock. Thus, the fix needs to go to 4.9+.