All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Morris <jmorris@namei.org>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: linux-security-module@vger.kernel.org
Subject: Re: [PATCH v2] tomoyo: Don't check open/getattr permission on sockets.
Date: Sat, 6 Jul 2019 19:44:43 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LRH.2.21.1907061944050.2662@namei.org> (raw)
In-Reply-To: <bc146372-764d-93a9-af27-666d73ed3af5@i-love.sakura.ne.jp>

On Thu, 4 Jul 2019, Tetsuo Handa wrote:

> Hello.
> 
> Since it seems that Al has no comments, I'd like to send this patch to
> linux-next.git . What should I do? Do I need to set up a git tree?

Yes, you can create one at github or similar.


> 
> On 2019/06/22 13:45, Tetsuo Handa wrote:
> > From c63c4074300921d6d1c33c3b8dc9c84ebfededf5 Mon Sep 17 00:00:00 2001
> > From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Date: Sat, 22 Jun 2019 13:14:26 +0900
> > Subject: [PATCH v2] tomoyo: Don't check open/getattr permission on sockets.
> > 
> > syzbot is reporting that use of SOCKET_I()->sk from open() can result in
> > use after free problem [1], for socket's inode is still reachable via
> > /proc/pid/fd/n despite destruction of SOCKET_I()->sk already completed.
> > 
> > But there is no point with calling security_file_open() on sockets
> > because open("/proc/pid/fd/n", !O_PATH) on sockets fails with -ENXIO.
> > 
> > There is some point with calling security_inode_getattr() on sockets
> > because stat("/proc/pid/fd/n") and fstat(open("/proc/pid/fd/n", O_PATH))
> > are valid. If we want to access "struct sock"->sk_{family,type,protocol}
> > fields, we will need to use security_socket_post_create() hook and
> > security_inode_free() hook in order to remember these fields because
> > security_sk_free() hook is called before the inode is destructed. But
> > since information which can be protected by checking
> > security_inode_getattr() on sockets is trivial, let's not be bothered by
> > "struct inode"->i_security management.
> > 
> > There is point with calling security_file_ioctl() on sockets. Since
> > ioctl(open("/proc/pid/fd/n", O_PATH)) is invalid, security_file_ioctl()
> > on sockets should remain safe.
> > 
> > [1] https://syzkaller.appspot.com/bug?id=73d590010454403d55164cca23bd0565b1eb3b74
> > 
> > Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Reported-by: syzbot <syzbot+0341f6a4d729d4e0acf1@syzkaller.appspotmail.com>
> > ---
> >  security/tomoyo/tomoyo.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
> > index 716c92e..8ea3f5d 100644
> > --- a/security/tomoyo/tomoyo.c
> > +++ b/security/tomoyo/tomoyo.c
> > @@ -126,6 +126,9 @@ static int tomoyo_bprm_check_security(struct linux_binprm *bprm)
> >   */
> >  static int tomoyo_inode_getattr(const struct path *path)
> >  {
> > +	/* It is not safe to call tomoyo_get_socket_name(). */
> > +	if (S_ISSOCK(d_inode(path->dentry)->i_mode))
> > +		return 0;
> >  	return tomoyo_path_perm(TOMOYO_TYPE_GETATTR, path, NULL);
> >  }
> >  
> > @@ -316,6 +319,9 @@ static int tomoyo_file_open(struct file *f)
> >  	/* Don't check read permission here if called from do_execve(). */
> >  	if (current->in_execve)
> >  		return 0;
> > +	/* Sockets can't be opened by open(). */
> > +	if (S_ISSOCK(file_inode(f)->i_mode))
> > +		return 0;
> >  	return tomoyo_check_open_permission(tomoyo_domain(), &f->f_path,
> >  					    f->f_flags);
> >  }
> > 
> 

-- 
James Morris
<jmorris@namei.org>


  reply	other threads:[~2019-07-07  2:45 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-05 18:42 KASAN: use-after-free Read in tomoyo_realpath_from_path syzbot
2019-06-05 22:09 ` Tetsuo Handa
2019-06-06  2:08 ` Tetsuo Handa
2019-06-06  5:20 ` Tetsuo Handa
2019-06-09  6:41   ` [PATCH] tomoyo: Don't check open/getattr permission on sockets Tetsuo Handa
2019-06-16  6:49     ` Tetsuo Handa
2019-06-18 20:49       ` Al Viro
2019-06-22  4:45         ` [PATCH v2] " Tetsuo Handa
2019-07-04 11:58           ` Tetsuo Handa
2019-07-07  2:44             ` James Morris [this message]
2019-07-07  2:50               ` James Morris
2019-08-09 15:51                 ` Tetsuo Handa
2019-09-03  6:52                 ` Tetsuo Handa
2019-09-13 13:41                   ` Tetsuo Handa
     [not found]                     ` <A9CE5147-4047-4C42-B772-F0ED510FA283@canb.auug.org.au>
2019-10-02 10:50                       ` Tetsuo Handa
2019-10-02 22:25                         ` Stephen Rothwell
2019-10-03  9:59                           ` Tetsuo Handa
2019-11-13 13:49                             ` Tetsuo Handa
2019-11-21  7:21                               ` James Morris
2019-11-21 10:18                                 ` Tetsuo Handa
2019-11-21 13:59                                   ` Tetsuo Handa
2019-12-04 12:50                                     ` Tetsuo Handa
2019-12-09 21:37                                       ` James Morris
2019-12-10 10:21                                         ` Tetsuo Handa
2019-12-10 23:02                                           ` Stephen Rothwell
2019-12-11 11:19                                             ` Tetsuo Handa
2019-10-02 22:22                     ` Stephen Rothwell
2019-08-22  6:30           ` Eric Biggers
2019-08-22  6:55             ` Tetsuo Handa
2019-08-22  7:01               ` Eric Biggers
2019-08-22  7:42                 ` Tetsuo Handa
2019-08-22 15:47                   ` Eric Biggers

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=alpine.LRH.2.21.1907061944050.2662@namei.org \
    --to=jmorris@namei.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.