Subject: Re: x2goserver and rhel6.4 / selinux Problem

From: Mike Gabriel <[email-masked]>
Date: Thu, 27 Feb 2014 15:30:48 +0000

Control: tag -1 moreinfo

Hi Frank,

> ---------------------------
>
> ls -Z .Xauthority
>  -rw-------. frank users unconfined_u:object_r:default_t:s0 .Xauthority
>
> --------------------------
>
> Then I do a logout. Now, when I try to connect again to the x2go  
> server system, I get
> the following error message on the client side and no session is started.
>
> -----------------------------
> .....
>
> "Warning: Cookie mismatch in the X authentication data.
> "
>
> "Session: Terminating session at 'Thu Feb 27 09:40:05 2014'.
> Info: Your session was closed before reaching a usable state.
> Info: This can be due to the local X server refusing access to the client.
> Info: Please check authorization provided by the remote X application.
> Session: Session terminated at 'Thu Feb 27 09:40:05 2014'.
> "
>
> deleting proxy
>
> nxproxy not running
>
> proxy deleted
>
> -----------------------------------
>
> But when I change the selinux permissions to
>
> ------
>
> ls -Z .Xauthority
>
> -rw-------. frank users unconfined_u:object_r:xauth_home_t:s0 .Xauthority

What are the SELinux permissions after you have logged out?

Do you need that chcon command call when resuming sessions or when  
starting sessions.

Excuse my SELinux innocence at this point. I would like to add support  
for SELinux, but I need to understand better why we have to tweak the  
security context of .Xauthority for X2Go.

Thanks+Greets,
Mike

-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: [email-masked], http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

---

From: Frank Knoben <[email-masked]>
Date: Fri, 28 Feb 2014 09:22:47 +0100

Hello Mike,

the problem is, that I'm not an expert on selinux too.
But I did some more tests.

Interactive Session - first login, the ~/.Xauthority file is created
and stays after logout with the permissions *system_u:object_r:default_t:s0*
I am still able to login in interactively again.

But with this permissions, I got the Cookie mismatch problem, when using 
the x2goclient.
And when I login with ssh to the computer, I got a xauth error message:
/usr/bin/xauth:  ~/.Xauthority not writable, changes will be ignored

Now I  remove all .Xauthority* files. Then a login with ssh will create 
the ~/.Xauthority file
with the *system_u:object_r:xauth_home_t:s0* permissions and the files 
stays with
these permissions after logout.

Now when I use the x2goclient, the file permissions change during the 
login process from
*system_u:object_r:xauth_home_t:s0* to *system_u:object_r:default_t:s0 
*and stay
that way after logout. The same, as it is with interactive sessions.
So I guess, everything is fine with the x2goserver software and
this is not a bug.
My problem is, that ssh is not able to overwrite the .Xauthority file, 
when it has the
default permissions of *system_u:object_r:default_t:s0* . Therefore the 
x2goclient is
not able to start a successful session and gets the Cookie mismatch error.

So I think, you can close this bugreport.

Thank you very much for your quick response and please excuse my mistake in
thinking that this was a x2goserver bug.

Sincerly

Frank

Frank Knoben
Institut fuer Geometrie und Praktische Mathematik
RWTH Aachen
Aachen,
Germany

---

From: Mike Gabriel <[email-masked]>
Date: Fri, 28 Feb 2014 09:24:46 +0000

Hi Frank,

On  Fr 28 Feb 2014 09:22:47 CET, Frank Knoben wrote:

> But with this permissions, I got the Cookie mismatch problem, when  
> using the x2goclient.
> Now I  remove all .Xauthority* files. Then a login with ssh will  
> create the ~/.Xauthority file
> with the *system_u:object_r:xauth_home_t:s0* permissions and the  
> files stays with
> Now when I use the x2goclient, the file permissions change during  
> the login process from
> *system_u:object_r:xauth_home_t:s0* to  
> *system_u:object_r:default_t:s0 *and stay
> My problem is, that ssh is not able to overwrite the .Xauthority  
> file, when it has the
> default permissions of *system_u:object_r:default_t:s0* . Therefore  
> the x2goclient is

Nonono... I actually think there is something wrong with X2Go Server.

X2Go Client / PyHoca-GUI (another X2Go client app) should immitate  
what SSH does.

As the X2Go clients call the script /usr/bin/x2gostartagent and this  
script fiddles with the .Xauthority files via xauth, we should make  
sure that after modifying the .Xauthority file the SELinux permissions  
stay intact.

Can you please add your proposed chcon command into x2gostartagent  
(near line 268, there is another position further up for shadow  
sessions) after xauth has been called and see it that fixes your  
troubles.

Next step: please provide me with an if clause that will test if  
SELinux is in use or not, so we can call chcon only if SELinux is in  
use on that system.

Thanks+Greets,
Mike

-- 

DAS-NETZWERKTEAM

GnuPG Key ID 0x25771B31

freeBusy:

---

From: Frank Knoben <[email-masked]>
Date: Fri, 28 Feb 2014 12:12:43 +0100

Hi Mike,

thank you very much for the proposal, where I could fix the problem for 
my system.
But I still have to think, how to make a permanent workaround in the 
x2gostartagent script.

- if I use icewm windowmanager with selinux and x2goserver / x2goclient 
everything is fine and the .Xauthority file has the right permissions
- if I use the kde or gnome  windowmanager the .Xauthority permissions 
will be modified to the wrong permissions
- when the home directory is on a nfsserver with no selinux installed 
and the x2goserver system uses selinux, there is no problem at all.
   Trying to fix the selinux permissions will give the error message 
'Operation not supported'

So I think, it is a problem of the kde and gnome windowmanager.
For the kde windowmanager, I put a chcon statement at the end of the 
/usr/bin/startkde script.
I'm still looking for a workaround for the gnome windowmanager.

Sincerly

Frank

---

From: Mike Gabriel <[email-masked]>
Date: Fri, 28 Feb 2014 12:00:38 +0000

Hi Frank,

On  Fr 28 Feb 2014 12:12:43 CET, Frank Knoben wrote:

> Hi Mike,
>
> thank you very much for the proposal, where I could fix the problem  
> for my system.
> - if I use icewm windowmanager with selinux and x2goserver /  
> x2goclient everything is fine and the .Xauthority file has the right  
> permissions
> - if I use the kde or gnome  windowmanager the .Xauthority  
> permissions will be modified to the wrong permissions
> - when the home directory is on a nfsserver with no selinux  
> installed and the x2goserver system uses selinux, there is no  
> problem at all.

Thanks for this heavy debugging.

I will be fine with adding such magic into x2gostartagent (or  
x2goruncommand). But we need to be as detailled and explicit on the  
how and when.

Get back to me, once you have more insights.

Mike
-- 

DAS-NETZWERKTEAM

GnuPG Key ID 0x25771B31

freeBusy:

---

From: Frank Knoben <[email-masked]>
Date: Fri, 28 Feb 2014 13:15:41 +0100

Hi Mike,

what about the following solution / proposal for the x2goruncommand script:

....
# run logout scripts

FIX_XAUTH=`ls -Z $HOME/.Xauthority | egrep default_t`
if test -n $FIX_AUTH
then
   /usr/bin/chcon unconfined_u:object_r:xauth_home_t:s0 $HOME/.Xauthority
fi

test -r /etc/x2go/x2go_logout && . /etc/x2go/x2go_logout

...

this fixes the selinux file permission in case, it it set to 
system_u:object_r:default_t:s0
It works on my system.

sincerly

Frank

---

From: Mike Gabriel <[email-masked]>
Date: Fri, 28 Feb 2014 12:20:51 +0000

Hi Frank,

> system_u:object_r:default_t:s0

The position where you propose adding the fix does not seem right to  
me. As the file permissions will stay "wrong" for the duration of the  
session and will only be corrected after the session has ended.

Do I understand it correctly, that the file permissions need adaptions  
directly after session startup (i.e. after launching the session  
(destop) command)?

Greets,
Mike

-- 

DAS-NETZWERKTEAM

GnuPG Key ID 0x25771B31

freeBusy:

---

From: Frank Knoben <[email-masked]>
Date: Fri, 28 Feb 2014 13:30:36 +0100

Hi Mike,

the file permissions only need to be fixed for the next login.
During startup, the xauth command needs the selinux file permissions
of *unconfined_u:object_r:xauth_home_t:s0* or of 
*unconfined_u:object_r:user_home_t:s0* to the .Xauthority file,
so that it can overwrite the file with the new Xauthority Information.
After that, everything works fine for the session.
At least for my test, where I did login and opened a terminal window.
Maybe I should try opening some more kde and gnome applications.
On my system, it is ok, when the permissions will be fixed at logout time.

Sincerly

Frank

---

From: Frank Knoben <[email-masked]>
Date: Fri, 28 Feb 2014 14:56:43 +0100

Hi Mike,

I gave some more thoughts to your remark, that the position is the wrong 
one.
And you were right. On a system, where users work interactively at an 
attached
screen and use x2go for accessing the system remotely, the fix won't 
work at that
position. There it should be just before the .Xauthority file is 
accessed. I will
see on tuesday, wether I can find that position.

Sincerly

Frank

---

From: Orion Poplawski <[email-masked]>
Date: Fri, 28 Feb 2014 16:07:02 -0700

>    /usr/bin/chcon unconfined_u:object_r:xauth_home_t:s0 $HOME/.Xauthority

I would suggest using restorecon to set the label.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       [email-masked]
Boulder, CO 80301                   http://www.nwra.com

---

From: Frank Knoben <[email-masked]>
Date: Tue, 04 Mar 2014 12:02:38 +0100

When I put the lines in the x2gostartagent script

after the

XAUTHORITY=${XAUTHORITY:-"$HOME/.Xauthority"}

line, the permissions will be fixed on login and not on logout.
Unfortunately, restorcon sets the permissions to 
system_u:object_r:default_t:s0
and this does not work on my system.
Instead of fixing the selinux .Xauthority permissions, the file could 
also be deleted on login,
if it existed. Something like:

if test -f $HOME/.Xauthority
then
   rm $HOME/.Xauthority
fi

But it could also be, that my selinux system is misconfigured in some 
strange way,
so that other people, who run the system, don't have this problem.

Frank

---

From: Orion Poplawski <[email-masked]>
Date: Tue, 04 Mar 2014 09:36:10 -0700

On 03/04/2014 04:02 AM, Frank Knoben wrote:
> Unfortunately, restorcon sets the permissions to system_u:object_r:default_t:s0

That's not right.  What is your home directory?  What does matchpathcon $HOME 
return?

> Instead of fixing the selinux .Xauthority permissions, the file could also be
> deleted on login,
> But it could also be, that my selinux system is misconfigured in some strange
> way,

---

From: Frank Knoben <[email-masked]>
Date: Wed, 05 Mar 2014 07:59:06 +0100

On 03/04/2014 05:36 PM, Orion Poplawski wrote:
> That's not right.  What is your home directory?  What does 
> matchpathcon $HOME return?
>
>

matchpathcon  $HOME
returns system_u:object_r:default_t:s0

I switched the default home location from /home/user to /data/user and 
changed the
permissions of /data/user with
chcon -R unconfined_u:object_r:user_home_dir_t:s0 /data/user

---

From: Orion Poplawski <[email-masked]>
Date: Wed, 05 Mar 2014 08:13:59 -0700

> chcon -R unconfined_u:object_r:user_home_dir_t:s0 /data/user

Home directories are very special in SELinux - a whole policy tree is
built based on the base home directory.  Usually this is determined
automatically from entries in /etc/password, but I suspect you are using
LDAP or similar so that SELinux does not know you use /data/user for
home directories.  To inform it, you should do:

semanage fcontext -a -e /home /data/user

This is from /etc/selinux/semanage.conf.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  [email-masked]
Boulder, CO 80301              http://www.cora.nwra.com

---

From: Mike Gabriel <[email-masked]>
Date: Wed, 05 Mar 2014 21:20:47 +0000

Control: tag -1 not-a-bug

Hi Frank, hi Orion,

> This is from /etc/selinux/semanage.conf.

@Orion: thanks for giving support on this issue.

Do I understand it correctly, that the observed issues are not X2Go  
related, but rather caused by a non-default setup?

Mike
-- 

DAS-NETZWERKTEAM

GnuPG Key ID 0x25771B31

freeBusy:

---

From: Orion Poplawski <[email-masked]>
Date: Wed, 05 Mar 2014 14:37:37 -0700

On 03/05/2014 02:20 PM, Mike Gabriel wrote:
> Do I understand it correctly, that the observed issues are not X2Go related,
> but rather caused by a non-default setup?
>
> Mike

That's certainly my take.

---

From: Frank Knoben <[email-masked]>
Date: Thu, 06 Mar 2014 08:16:14 +0100

Hi Orion, hi Mike,

thank you very much for your support and your patience.

Sincerly

Frank

---

From: Mike Gabriel <[email-masked]>
Date: Thu, 06 Mar 2014 07:41:09 +0000

Control: close -1

Hi Frank,

> thank you very much for your support and your patience.

You are welcome!

Mike
-- 

DAS-NETZWERKTEAM

GnuPG Key ID 0x25771B31

freeBusy: