On Sat, Feb 3, 2018 at 4:55 PM, Chet Ramey <chet.ra...@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
