Re: Output redirection to sockets possible within rbash

[Chet Ramey]

On 2/3/18 12:20 PM, Blake Burkhart wrote:
> Within rbash, attempting to open a socket using /dev/tcp with <> fails as
> expected due to output redirection being disabled:
> 
> rbash-4.4$ exec 3<>/dev/tcp/www.gnu.org/80
> rbash: /dev/tcp/www.gnu.org/80: restricted: cannot redirect output
> 
> However, I noticed that output redirection is not disabled on open file
> descriptors in rbash:
> 
> rbash-4.4$ echo foo >&1
> foo
> 
> Additionally, even if a socket is opened only for reading, bash allows
> writing to it. (This is not true for normal files, attempting to a file
> opened read only fails with "write error: Bad file descriptor" as expected.)

This isn't bash bug, exactly, it's more a consequence of read-only sockets
not existing.

Bash assumes that you can dup a file descriptor in a restricted shell
(the dup2 and fcntl interfaces don't restrict you to `input' and `output'
file descriptors), but also assumes the kernel will enforce the permissions
on the original file descriptor, since the new fd is supposed to be `an
exact copy' of the original. The shell knows how it opens the file, and can
enforce the read-write mode restrictions at that time.

If the kernel decides that the socket is going to be read-write no matter
what, the socket(2) and connect(2) system calls don't let you specify
any kind of file descriptor flags, and you can't change the mode after the
fact using fcntl, that assumption is not going to be valid.

I suppose the only real fix is to disallow sockets in the restricted shell.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/