Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 8 May 2020 19:49:41 +0200
From:      Damjan Jovanovic <damjan.jov@gmail.com>
To:        "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>
Cc:        Konstantin Belousov <kib@freebsd.org>, Hackers freeBSD <freebsd-hackers@freebsd.org>
Subject:   Re: Allow procstat to view current working directory? [xfce4-terminal, linprocfs, ...]
Message-ID:  <CAJm2B-nRMbgfw1_5nDqurjLSMy-bpnx068SriqJwcn3s9Rd4og@mail.gmail.com>
In-Reply-To: <202005081737.048Hb2CA053936@gndrsh.dnsmgr.net>
References:  <CAJm2B-nShdJ65xy4cvCj-aNj08r_k2L0uHaLcaLAS15mDLbEOQ@mail.gmail.com> <202005081737.048Hb2CA053936@gndrsh.dnsmgr.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 8, 2020 at 7:37 PM Rodney W. Grimes <
freebsd-rwg@gndrsh.dnsmgr.net> wrote:

> > On Wed, May 6, 2020 at 11:46 PM Konstantin Belousov <kib@freebsd.org>
> wrote:
> >
> > > On Wed, May 06, 2020 at 08:32:08PM +0200, Damjan Jovanovic wrote:
> > > > Hi
> > > >
> > > > Currently "procstat fd [pid]" cannot view anything, even for other
> > > > processes owned by the user making the call, not even their current
> > > working
> > > > directory (CWD), unless it has PGET_CANDEBUG permission.
> > > >
> > > > linprocfs however allows reading the CWD for any process because it
> > > doesn't
> > > > perform that check (sys/compat/linprocfs/linprocfs.c, function
> > > > linprocfs_doproccwd()).
> > > >
> > > > Applications use this, eg. xfce4-terminal relies on
> > > > /compat/linux/proc/<pid>/cwd to find the shell's CWD, so that when
> you
> > > open
> > > > a new tab, it starts in the same CWD as the tab you opened it from (
> > > >
> > >
> https://github.com/xfce-mirror/xfce4-terminal/blob/master/terminal/terminal-screen.c#L2343
> > > ).
> > > > I would like to patch xfce4-terminal to use libprocstat for that
> instead
> > > of
> > > > needing linprocfs to be mounted, but since procstat is more
> restrictive,
> > > it
> > > > will break it.
> > > >
> > > > Can we please downgrade PGET_CANDEBUG to at least PGET_CANSEE, so
> you can
> > > > view the CWD for processes you own? Maybe other open files still
> need to
> > > be
> > > > hidden, but the CWD doesn't seem like a major security concern.
> > > Can you explain why CANDEBUG vs CANSEE matters for your case ?
> > > Or better, why xfce4-terminal cannot debug shells it spawns ?
> > > Is it suid ?
> > >
> > >
> > xfce4-terminal is a normal process, no suid. It wants to read CWD of the
> > current tab so the new tab opens in the same directory, which is often
> what
> > you want. On Linux /proc/<pid>/cwd is lrwxrwxrwx for all processes. On
> > FreeBSD /compat/linux/proc/<pid>/cwd is lrwxrwxrwx for all procesess. It
> > works as intended at present, as long as you have linprocfs mounted.
> >
> > But I'd rather not have to mount linprocfs. If I patch xfce4-terminal to
> > use libprocstat instead, then it will break, as it needs CANDEBUG to see
> > the CWD, a restriction that seems extreme.
> >
> >
> > >
> > > My initial reaction was that linprocfs should be patched to match
> FreeBSD
> > > native behaviour instead.
> > >
> >
> > Why does Linux allow everyone to see CWD for all processes?
>
> Does that include a path that I should not even be able to see
> via file system protections?  If so I would classify that as
> a data xfiltration security concern.
>

You're right, on Linux the symlink /proc/1/cwd is there, but the link
target is invisible, and "stat cwd" gives:

  File: 'cwd'stat: cannot read symbolic link 'cwd': Permission denied

  Size: 0         Blocks: 0          IO Block: 1024   symbolic link
Device: 4h/4d Inode: 24821       Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-05-08 18:10:45.485582443 +0200
Modify: 2020-05-08 18:10:45.441582441 +0200
Change: 2020-05-08 18:10:45.441582441 +0200
 Birth: -


> >
> >
> > >
> > > >
> > > > Linux's own /proc filesystem never hides the CWD (lrwxrwxrwx), and
> only
> > > > hides file descriptors for processes you don't own.
> > > >
> > > > A patch along the following lines could be a start:
> > > >
> > > > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c
> > > > index 423968b2e1cc..f487232d2cff 100644
> > > > --- a/sys/kern/kern_descrip.c
> > > > +++ b/sys/kern/kern_descrip.c
> > > > @@ -3692,7 +3692,7 @@ sysctl_kern_proc_filedesc(SYSCTL_HANDLER_ARGS)
> > > >
> > > >         sbuf_new_for_sysctl(&sb, NULL, FILEDESC_SBUF_SIZE, req);
> > > >         sbuf_clear_flags(&sb, SBUF_INCLUDENUL);
> > > > -   error = pget((pid_t)name[0], PGET_CANDEBUG | PGET_NOTWEXIT, &p);
> > > > + error = pget((pid_t)name[0], PGET_CANSEE | PGET_NOTWEXIT, &p);
> > > >         if (error != 0) {
> > > >                 sbuf_delete(&sb);
> > > >                 return (error);
> > > > @@ -3768,7 +3768,7 @@ sysctl_kern_proc_ofiledesc(SYSCTL_HANDLER_ARGS)
> > > >         struct proc *p;
> > > >
> > > >         name = (int *)arg1;
> > > > -   error = pget((pid_t)name[0], PGET_CANDEBUG | PGET_NOTWEXIT, &p);
> > > > + error = pget((pid_t)name[0], PGET_CANSEE | PGET_NOTWEXIT, &p);
> > > >         if (error != 0)
> > > >                 return (error);
> > > >         fdp = fdhold(p);
> > > >
> > > >
> > > >
> > > >
> > > > Thank you
> > > > Damjan
> > > > _______________________________________________
> > > > freebsd-hackers@freebsd.org mailing list
> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > > > To unsubscribe, send any mail to "
> > > freebsd-hackers-unsubscribe@freebsd.org"
> > >
> > _______________________________________________
> > freebsd-hackers@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "
> freebsd-hackers-unsubscribe@freebsd.org"
> >
>
> --
> Rod Grimes
> rgrimes@freebsd.org
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJm2B-nRMbgfw1_5nDqurjLSMy-bpnx068SriqJwcn3s9Rd4og>