Securing X-sessions

[Mihails Nikitins]

I have a problem securing X-sessions from Windows boxes to HP-UX servers.

I tried to create /etc/X0.hosts with two records inside (only localhost and 1.1.1.1
should be allowed to connect)

localhost
1.1.1.1

However, the file is being ignored allowing everyone to connect.

Please find below some additional diagnostic information.

If typing 'xhost' from a non-root session, I get
% xhost
access control enabled, only authorized clients can connect

If typing 'xhost' from a root session, I get
# /usr/bin/X11/xhost
Xlib: connection to "2.2.2.2:0.0" refused by server
Xlib: Client is not authorized to connect to Server
/usr/bin/X11/xhost: unable to open display "2.2.2.2:0.0"

Here 2.2.2.2 is IP address of the Windows workstation running X-server application.
The 2.2.2.2 address should be refused when trying to connect.

Thanks in advance for any directions.

[Alex Glennie]

also the local xserver should always have access to it's own display you shouldn't need the localhost entry ..what happens if you remove it ?

[Alex Glennie]

could you elaborate a little .... where's the /etc/X0.host file located on a server or the W/S ?

[Alex Glennie]

just did a quick test looks like localhost isn't the answer but worth removing for now anyway, also of use would be a ps -ef ? grep X in case user based access is playing a part .....

[Thomas Schler_1]

If you edited /etc/X0.hosts and the entries
seem to be ignored, this may be due to
having not restarted the Xserver: Log
completely out and login again.

If /etc/X0.hosts still seems to be ignored
you must be sure, that nowhere during the
login procedure (e.g. /etc/profile, $HOME/
.profile) a 'xhost +' is issued.

The output of your first xhost (non-root
session) is ok, and X security seems to
work fine.

The output of your second xhost (root
session) is ok because you disabled
Xserver access by anyone but not
1.1.1.1 or localhost.

What do you mean with "allowing everyone
to connect"? What connections do you
mean? Of course, just applications that
need any components of the Xserver are
refused, but not other connections (e.g.
rlogins).

[Mihails Nikitins]

Thanks to all of you for the feedback! Unfortunately, the problem has not been fixed yet.

1. I find X-terminology (idea of 'server' and 'client') to be a bit confusing. I'll try to describe the problem once more.

I have HP-UX 10.20 server that should be secured against unsolicited remote access. inetd security is already set in /var/adm/inetd.sec, but another security hole still exists.
inetd.sec does not affect ability to establish remote connection via X-session. So, the host should be configured properly so that to refuse all incoming X connections except the ones from few trusted hosts.

I'm trying to set up /etc/X0.hosts on the HP-UX box that should be secured. The security should defend the HP-UX box from incoming remote access via X-sessions.

2. Removing of localhost from /etc/X0.hosts did not hep (I rebooted the HP-UX box). Probably, I understood manual incorrectly (Graphics Administration Guide for HP-UX 10.20 ACE, Making an X*.hosts File), since it tells

************
> The /etc/X0.hosts file is an ASCII text file containing the hostnames of each
> remote host permitted to access your local server...
> For example, if you are hpaaaaa, and regularly ran clients on hpccccc, and
> hpddddd, you would want the following lines.
>
> hpaaaaa
> hpccccc
> hpddddd
I guessed hpaaaaa is localhost in my case.

3. Startup files does not contain 'xhost +' command. (/etc/profile, /etc/csh/login, ~/.profile, ~/.login, ~.cshrc)

4. This is ps -ef |grep X output

ps -ef |grep X

root 944 1 0 13:14:53 ? 0:00 /usr/bin/X11/SLSd_daemon
daemon 1062 1056 0 13:15:24 ? 0:03 /usr/bin/X11/X :0

5. Running xhost from root account tells that security seem to be set up
# /usr/bin/X11/xhost
Xlib: connection to "2.2.2.2:0.0" refused by server
Xlib: Client is not authorized to connect to Server
/usr/bin/X11/xhost: unable to open display "2.2.2.2:0.0"
However, I can iniate X-session from 2.2.2.2.

Many thanks in advance for more comments!

[Alex Glennie]

Sorry for more questions but this has got me interested but confused all at once :

Points to note / try : check using vi that we don't have any trailing blanks etc in the /etc/X0.hosts file.

Does the problem still occur if you use hostnames as opposed to ip addresses ?

Am I right by saying we have a local hp-ux system (1.1.1.1) and another remote system (2.2.2.2) involved here : you are on the local box with a Xsession running, you wish to prevent the remote system having access to your local systems display right ?

Entries on 1.1.1.1 in /etc/X0.hosts = localhost & 1.1.1.1
You then run your application remotely on 2.2.2.2 by either using -display 1.1.1.1:0 or by remotely logging onto 1.1.1.1 from 2.2.2.2 and exporting DISPLAY=1.1.1.1:0 and then running .

You are expecting the above to fail but instead the application appears on screen 1.1.1.1:0

Also you mention the root output in point 5 gives a connection refused error where's this being run ? and does it involve rlogin or a telnet session ?

[Rick Beldin]

I'll try and summarize what I have heard so far...

The 10.20 that you are referring to as a 'server' is a workstation, running X. Is it
running a login manager, such as CDE's dtlogin, VUE's vuelogin, or xdm?

If it is running a login manager, then by default the system will:

- prevent access to the screen by *any* user while the login manager is displaying

- prevent access to the screen to only the user who holds the 'cookie' after login is complete.

If you are not running a login manager, then you need to try and mimic what the login manager does in terms of MIT-MAGIC-COOKIE authentication. man dtlogin and man Xserver should give you a start on what that is about. An additional man page on xauth might be of some interest as well.

Once you are logged into a workstation as user 'a', in the default setup, user 'a' can display because he has access to the $HOME/.Xauthority file where the cookie is stored. If 'a' su's to another user (root), then that user (root), *must* have access to the .Xauthority OR he must be given a copy so that he may put it in his own .Xauthority file.

If you are not using MIT-MAGIC-COOKIE authentication (.Xauthority) then the only access is through host-based authentication. This is what happens when you use xhost. Any user from host 'b' can access the display if you have done xhost +b.

And, yes, the client and server terminology can be quite confusing the first time you see it. Think of it this way the 'server' is the machine that is controlling the graphics *card* (hardware), while the 'client' is the machine where the program is executing. In the case of an Xterminal, for example, it is the 'server' in X-parlance because it controls the graphics card.

[Alex Glennie]

Hello Rick ! Curious one this .... I don't think Xauth (User based Access is involved here) as ps -ef ? grep X didn't return X:0 -auth blah blah string but you know more about this than I, Mihails we await your reply ......

[Mihails Nikitins]

Thanks a lot! I'll check everything as soon as I have time.