Allow procstat to view current working directory? [xfce4-terminal, linprocfs, ...]

[Rodney W. Grimes]

> On Wed, May 6, 2020 at 11:46 PM Konstantin Belousov <kib at 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.

> 
> 
> >
> > >
> > > 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 at freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > > To unsubscribe, send any mail to "
> > freebsd-hackers-unsubscribe at freebsd.org"
> >
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> 

-- 
Rod Grimes                                                 rgrimes at freebsd.org