Re: Output redirection to sockets possible within rbash

[Blake Burkhart]

On Sat, Feb 3, 2018 at 4:55 PM, Chet Ramey <chet.ramey@case.edu> wrote:

> 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.


That makes sense.

Disallowing sockets seems reasonable actually. I was surprised when I
discovered that a restricted and chrooted rbash shell could still make
sockets and talk to the outside world.

I suppose file descriptors inherited by rbash will always be writable if
possible, but I that behavior doens't sound like it should be too
surprising to users.

-- 
Blake Burkhart