# Telnet to Jail Not Working



## BawdyAnarchist (Sep 15, 2020)

I thought this was supposed to be simple...

On the host:  create an epair, send one side to jail, add IPaddr
In the vnet jail:  Add IP addr, `ping host`  (response).  Then  */etc/inetd.conf *, uncomment the telnet line for IPv4. `service inetd onestart`
On the host:  telnet -l user <IPaddr>

The user in this jail has no password.  `pfctl -d` has disabled pf for both host and jail. 
But I keep getting login failed.  I also tried the root account.  Same result. I haven't found anything in searches for help with similar problem.


```
root@dom0:~ # telnet -l user 10.99.1.2
Trying 10.99.1.2...
Connected to 10.99.1.2.
Escape character is '^]'.
Trying SRA secure login:
User (user): user
Password:
[ SRA login failed ]
```

I'm aware of ssh.  I'm aware of telnet being insecure.  I'm aware there are other ways to control jails.

Please, only relevant help to solve _this _problem.


----------



## BawdyAnarchist (Sep 15, 2020)

Well, just moments after posting this, onward I continued in my struggle.  Turns out it was because I had chflags schg on the system files for the jail.

For anyone wondering what I'm doing and why I'd be so crazy as to use the horribly insecure telnet ... it's for GUI.  I can't see a reason why I need to use ssh, consume CPU, and slow my video feed, when I'm "traveling" across 10.0.0.1/30 and 10.0.0.2/30 epairs to forward X11.  I'm currently using `xhost + local:` with /tmp/.X11-unix socket, which enables all jails to see all of the host and other jail's X windows.  So as far as I can tell, telnet X11 forwarding should be a security upgrade.  Obviously I will be allowing telnet ONLY over my epair to the host.

But I'm still kinda new to this, so if anyone can articulate why this is still a bad idea, I am open to criticism.  I'm hear to learn [sic] after all.


----------



## BawdyAnarchist (Sep 15, 2020)

Nice little convo I'm having with myself, but maybe some lurker will get use out of it in the future.  Ok, so update:
telnet is not necessary for X11 forwarding.  All that's required is

```
startx -- -listen tcp
xhost +x 10.0.0.2/30   # Or whatever your jail IP is for the pre-defined epair between host and jail
jexec -l <jail> setenv DISPLAY 10.0.0.1:0   # The :0 part being the display, and the other being obviously the host IP side of the epair
```

But unfortunately this doesn't seem to have prevented the jail's screencapture tool from seeing the other windows on host.  (I was using KDE's, `spectacle`)

So... yeah... anyone know of a way to prevent this?


----------



## eldaemon (Sep 15, 2020)

X11 security is a mess. I use Xephyr and lock down the X11 socket files to the relevant users they are in.

It's a little painful copying/pasting, but the only bulletproof method I've found short of VMs.


----------



## olli@ (Sep 15, 2020)

If you just want to shovel data from one IP/port to another IP/port (whether it’s a jail or another host) and don’t care about encryption and authentication, you can also use “netcat” (nc) instead of telnet. It is probably more efficient for this kind of things and has more options, and it’s also easier to use within shell scripts. See the nc(1) manual page for details.


----------



## olli@ (Sep 15, 2020)

Regarding the X11 access … Unfortunately, X11 has no per-window security or access controls. Basically, if some application can access the X server, it can access _everything_ else that’s connected to the same X server. There’s little you can do about that. It doesn’t make a significant difference if you forward a TCP port from the jail or share the local X11-unix socket (the latter is much more efficient, of course, especially for things that use hardware acceleration, like playing video or 3D stuff).

There are several ways to separate the jail’s X11 apps from the rest, but all of them come with a performance penalty. For example, you can run a VNC X server inside the jail, and then connect to it from the host’s X server with a VNC viewer. The jail’s X11 apps run inside the VNC X server and are unable to access the host’s X server. I’ve done this before, it actually works fairly well with most apps like terminals, web browsers, email clients and things like that, but video playback won’t work well. See Xvnc(1), vncserver(1) and vncviewer(1); these are from the net/tightvnc package.

Another option is to use Xnest(1) (from x11-servers/xorg-nestserver). This is an X server within an X server. You can give the jail access to the nested X server which runs inside a window within the host’s X server. In principle this is similar to the VNC solution above, and has similar restrictions. Under certain circumstances it works better because it uses the native X protocol instead of the VNC protocol. This is especially true when both servers run on the same machine, i.e. no external network connection involved.


----------



## BawdyAnarchist (Sep 15, 2020)

olli@ said:


> Regarding the X11 access … Unfortunately, X11 has no per-window security or access controls. Basically, if some application can access the X server, it can access _everything_ else that’s connected to the same X server. There’s little you can do about that. It doesn’t make a significant difference if you forward a TCP port from the jail or share the local X11-unix socket (the latter is much more efficient, of course, especially for things that use hardware acceleration, like playing video or 3D stuff).
> 
> There are several ways to separate the jail’s X11 apps from the rest, but all of them come with a performance penalty. For example, you can run a VNC X server inside the jail, and then connect to it from the host’s X server with a VNC viewer. The jail’s X11 apps run inside the VNC X server and are unable to access the host’s X server. I’ve done this before, it actually works fairly well with most apps like terminals, web browsers, email clients and things like that, but video playback won’t work well. See Xvnc(1), vncserver(1) and vncviewer(1); these are from the net/tightvnc package.
> 
> Another option is to use Xnest(1) (from x11-servers/xorg-nestserver). This is an X server within an X server. You can give the jail access to the nested X server which runs inside a window within the host’s X server. In principle this is similar to the VNC solution above, and has similar restrictions. Under certain circumstances it works better because it uses the native X protocol instead of the VNC protocol. This is especially true when both servers run on the same machine, i.e. no external network connection involved.



Thanks alot for the detailed response.  That kind of info is exactly what I've been searching for a few weeks now.  I might give Xnest a try.  Until then, I suppose I'll just be careful about which X apps and jails I'm running if handling sensitive data.  Thanks again.


----------

