Re: bug: stdio pipe is root owned so reopening it fails
* Jamie Lokier [2020-05-01 17:10:24 +0100]: > Hi Matt, > > > Not really sure of a good workaround. > > You can fchmod() or fchown() the pipe descriptor, with fchown() being more > secure. > > # echo hello | (ls -lL /proc/self/fd/0; sudo -u nobody cat > /proc/self/fd/0) > prw--- 1 root root 0 May 1 17:06 /proc/self/fd/0 > cat: /proc/self/fd/0: Permission denied > > # echo hello | (chmod a+rw /proc/self/fd/0; ls -lL /proc/self/fd/0; sudo > -u nobody cat /proc/self/fd/0) > prw-rw-rw- 1 root root 0 May 1 17:05 /proc/self/fd/0 > hello > > # echo hello | (chown nobody: /proc/self/fd/0; ls -lL /proc/self/fd/0; > sudo -u nobody cat /proc/self/fd/0) > prw--- 1 nobody nogroup 0 May 1 17:06 /proc/self/fd/0 > hello > > Best wishes, > - Jamie > > Matt Johnston wrote: > > Hi Szabolcs, > > > > Ah, that's a bit nasty. I guess the difference is that OpenSSH runs the > > daemon > > as the user, while Dropbear runs as root. isn't it better security design to drop privs as soon as possible so everything in the process that's managing a user's session runs as that user and not as root? but i guess that requires more changes than fchown on 0/1/2 fds. i can rebuild dropbear so if the fchwon is a simple patch that works for me. thanks. > > > > The procfs manpage mentions the problem. [1]http://man7.org/linux/man-pages/ > > man5/proc.5.html > > > > Note that for file descriptors referring to inodes (pipes and > > sockets, see above), those inodes still have permission bits > > and ownership information distinct from those of the > > /proc/[pid]/fd entry, and that the owner may differ from the > > user and group IDs of the process. An unprivileged process > > may lack permissions to open them, as in this example: > > > > $ echo test | sudo -u nobody cat > > test > > $ echo test | sudo -u nobody cat /proc/self/fd/0 > > cat: /proc/self/fd/0: Permission denied > > > > Not really sure of a good workaround.
Re: bug: stdio pipe is root owned so reopening it fails
Hi Matt, Matt Johnston wrote: > Not really sure of a good workaround. You can fchmod() or fchown() the pipe descriptor, with fchown() being more secure. # echo hello | (ls -lL /proc/self/fd/0; sudo -u nobody cat /proc/self/fd/0) prw--- 1 root root 0 May 1 17:06 /proc/self/fd/0 cat: /proc/self/fd/0: Permission denied # echo hello | (chmod a+rw /proc/self/fd/0; ls -lL /proc/self/fd/0; sudo -u nobody cat /proc/self/fd/0) prw-rw-rw- 1 root root 0 May 1 17:05 /proc/self/fd/0 hello # echo hello | (chown nobody: /proc/self/fd/0; ls -lL /proc/self/fd/0; sudo -u nobody cat /proc/self/fd/0) prw--- 1 nobody nogroup 0 May 1 17:06 /proc/self/fd/0 hello Best, - Jamie Matt Johnston wrote: > Hi Szabolcs, > > Ah, that's a bit nasty. I guess the difference is that OpenSSH runs the daemon > as the user, while Dropbear runs as root. > > The procfs manpage mentions the problem. [1]http://man7.org/linux/man-pages/ > man5/proc.5.html > > Note that for file descriptors referring to inodes (pipes and > sockets, see above), those inodes still have permission bits > and ownership information distinct from those of the > /proc/[pid]/fd entry, and that the owner may differ from the > user and group IDs of the process. An unprivileged process > may lack permissions to open them, as in this example: > > $ echo test | sudo -u nobody cat > test > $ echo test | sudo -u nobody cat /proc/self/fd/0 > cat: /proc/self/fd/0: Permission denied > > Not really sure of a good workaround.
Re: bug: stdio pipe is root owned so reopening it fails
Hi Szabolcs,
Ah, that's a bit nasty. I guess the difference is that OpenSSH runs the daemon
as the user, while Dropbear runs as root.
The procfs manpage mentions the problem.
http://man7.org/linux/man-pages/man5/proc.5.html
Note that for file descriptors referring to inodes (pipes and
sockets, see above), those inodes still have permission bits
and ownership information distinct from those of the
/proc/[pid]/fd entry, and that the owner may differ from the
user and group IDs of the process. An unprivileged process
may lack permissions to open them, as in this example:
$ echo test | sudo -u nobody cat
test
$ echo test | sudo -u nobody cat /proc/self/fd/0
cat: /proc/self/fd/0: Permission denied
Not really sure of a good workaround.
Cheers,
Matt
> On Fri 1/5/2020, at 2:46 am, Szabolcs Nagy wrote:
>
> hello, when dropbear server runs on host
>
> $ echo hi | ssh user@host 'cat'
>
> works as expected (so reading stdin works), but
>
> $ echo hi | ssh user@host 'cat /proc/self/fd/0'
>
> fails with EPERM (the open syscall in cat that is).
>
> it seems the /proc file is user owned but it's a magic symlink
> to a pipe that is owned by root so reopening it fails:
>
> $ ssh user@host 'stat -L /proc/self/fd/0'
> File: /proc/self/fd/0
> Size: 0 Blocks: 0 IO Block: 4096 fifo
> Device: bh/11d Inode: 7193Links: 1
> Access: (0600/prw---) Uid: (0/root) Gid: (0/root)
> Access: 2020-04-30 18:29:01.0
> Modify: 2020-04-30 18:29:01.0
> Change: 2020-04-30 18:29:01.0
>
> i haven't seen this behaviour with openssh and affects some
> scripts that use /dev/stdin, /dev/stdout, /dev/stderr
> (which just point to /proc/self/fd/{1,2,3})
>
> if there is a simple workaround i'd like to hear about it.
> thanks
