On 9 Dec 2023 04:37:09 GMT Robert Riches wrote:

On 2023-12-08, Markus Robert Kessler <no_reply@dipl-ing-kessler.de>
wrote:

Hello everyone,

I'm just trying to switch the current user and then invoke some X11
application, but this does not work.

On Redhat-based machines this never was a problem and I need this means
to keep my axxounts separate from each other for security reasons.
E.g., I do a

'su - bank'
and after loggin in I can invoke 'chromium-browser
https://pathtoonlinebanking'

Now I see, that Debian-based Raspbian OS and Ubuntu (23.10) behave very
similar, it looks like this:

$ su - test1 Passwort:

$ firefox Error: no DISPLAY environment variable specified

$ DISPLAY=':0.0' firefox Authorization required, but no authorization
protocol specified

On Raspbian and on Ubuntu the same lets me assume that it was not me to
misconfigure something.

Can this be fixed easily? - Thanks!

Best regards,

Markus

It sounds like you're running into the XAUTH system.

Normally, in the home directory of the user who's running X stuff there
is a file called ".Xauthority", and environment variable XAUTHORITY
holds the full, absolute path to that file.

In order for user B to run X clients/apps when user A is the one who
started the X server, user B must set environment variable XAUTHORITY to
a file which user B has permission to read and which has the same
contents as user A's ~/.Xauthority.

How you get that file and environment variable set depends on your use
case. I run my web browsers, gimp, and a few other programs as a
different user for security and a few other reasons. I have wrapper
scripts that do the file copying,
environment variable setting, and environment variable preservation
across sudo and/or su. For the way I do all that,
user B's only reason for existence is to run browsers and such for user
A, and it's important that user A have write permission to user B's home directory by means of the g+w permission bit.

Hi,

maybe there's a way around wrapper scripts?
I am wondering, why on Redhat-based systems like Mageia there is no need
for that, instead all this is done in background.

What I found out is, that when switching 'su - newaccount', then

- a file ~/.xauth* (e.g.: .xauthOa9EpX) is automatically created
(by su? by pam?)
- and when either starting x-app like xclock, so this works, or
- deleting this .xauth* and starting x-app, then above error occurs

This looks like su does all this "wrapping" automatically, as long as it
is confugured adequately. Maybe also systemd plays some role here.

Does anyone have more details here?
I am asking, because life would be easier, if this runs automaically :-)

Thanks!

Best regards,

Markus

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 09/12/2023 11:54, Markus Robert Kessler wrote:

What I found out is, that when switching 'su - newaccount', then

- a file ~/.xauth* (e.g.: .xauthOa9EpX) is automatically created
(by su? by pam?)
- and when either starting x-app like xclock, so this works, or
- deleting this .xauth* and starting x-app, then above error occurs

This suggests that the original problem may have been su'ing to a user
with no home directory, or one that the user has no permissions for, so
this file cannot be created.
--
There is nothing a fleet of dispatchable nuclear power plants cannot do
that cannot be done worse and more expensively and with higher carbon emissions and more adverse environmental impact by adding intermittent renewable energy.


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A little, after lunch (2:250/1@fidonet)

On Sat, 9 Dec 2023 11:54:38 -0000 (UTC)
Markus Robert Kessler <no_reply@dipl-ing-kessler.de> wrote:

What I found out is, that when switching 'su - newaccount', then

- a file ~/.xauth* (e.g.: .xauthOa9EpX) is automatically created
(by su? by pam?)

Probably with this:

https://www.man7.org/linux/man-pages/man8/pam_xauth.8.html

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sat, 9 Dec 2023 12:09:35 +0000 The Natural Philosopher wrote:

On 09/12/2023 11:54, Markus Robert Kessler wrote:

What I found out is, that when switching 'su - newaccount', then

- a file ~/.xauth* (e.g.: .xauthOa9EpX) is automatically created
(by su? by pam?)
- and when either starting x-app like xclock, so this works, or -
deleting this .xauth* and starting x-app, then above error occurs

This suggests that the original problem may have been su'ing to a user
with no home directory, or one that the user has no permissions for, so
this file cannot be created.

Hi, good point, indeed, but on Mageia, where this works, I can switch
freely via su - test... betweeen test* accounts. Directory /home/ lists
like

drwx------ 9 test test 4,0K Dez 9 12:56 test/
drwx------ 2 test1 test1 4,0K Dez 7 16:46 test1/
drwx------ 2 test2 test2 4,0K Nov 4 20:10 test2/
drwx------ 10 test3 test3 4,0K Dez 9 11:24 test3/
drwx------ 2 test4 test4 4,0K Nov 21 14:45 test4/

So, the root cause may be located somewhere else.

BR,

Markus

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sat, 09 Dec 2023 09:18:40 -0500, Markus Robert Kessler <no_reply@dipl-ing-kessler.de> wrote:

On Sat, 9 Dec 2023 12:09:35 +0000 The Natural Philosopher wrote:

On 09/12/2023 11:54, Markus Robert Kessler wrote:

What I found out is, that when switching 'su - newaccount', then

- a file ~/.xauth* (e.g.: .xauthOa9EpX) is automatically created
(by su? by pam?)
- and when either starting x-app like xclock, so this works, or -
deleting this .xauth* and starting x-app, then above error occurs

This suggests that the original problem may have been su'ing to a user
with no home directory, or one that the user has no permissions for, so
this file cannot be created.

Hi, good point, indeed, but on Mageia, where this works, I can switch
freely via su - test... betweeen test* accounts. Directory /home/ lists
like

drwx------ 9 test test 4,0K Dez 9 12:56 test/
drwx------ 2 test1 test1 4,0K Dez 7 16:46 test1/
drwx------ 2 test2 test2 4,0K Nov 4 20:10 test2/
drwx------ 10 test3 test3 4,0K Dez 9 11:24 test3/
drwx------ 2 test4 test4 4,0K Nov 21 14:45 test4/

So, the root cause may be located somewhere else.

This can also happen if the user previously used "su" to become root and ran
X leaving the auth file owned by root.

Always use "su - root", which can be shortened to just "su -". Don't use
just "su". See https://wiki.mageia.org/en/Never_use_just_su

Check "ls -la ~|grep -e auth" to see if any of the auth files are owned by root.

Regards, Dave Hodgins

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sat, 09 Dec 2023 14:56:19 +0000 Richard Kettlewell wrote:

Markus Robert Kessler <no_reply@dipl-ing-kessler.de> writes:

I'm just trying to switch the current user and then invoke some X11
application, but this does not work.

On Redhat-based machines this never was a problem and I need this means
to keep my axxounts separate from each other for security reasons.
E.g., I do a

It sounds like you’re trying to isolate the web browser that you use for banking websites from other applications in the same login session by
running it under a different user ID.

However, that isolation does not exist in the X11 model.

http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-

gui-isolation.html

Dammit. I read above article and tested on Mageia and on Raspbian.
Assuming same behaviour on Ubuntu.

Just to summarize what I've seen:

When owning the desktop (xfce4 in my case) using xinput in one terminal
shows every keystroke in a different window. No matter if text console or browser.

I sniffed "USB keyboard" and opened one more xterm window, where I did a
su - newaccount and opened a firefox window there. Under this account I
opened my credit card account, and every keystroke (search etc.) was
displayed in the xinput-window.

When logging into creditcard account using username and password stored in
the browser, then (of course) these keystrokes are not shown.

So, quite slowly, I suspect more and more that Debian based distros are
not enabling su - / x-app right out of the box, by intention.

I already handled with caution to log into online banking during M$ teams meetings, because for audio in-/output they need access to the desktop,
and hence they could take screenshots from other windows like online
banking app.

So, it looks like, the only proper approach is to completely log off from
the X11 session instead of su - / x-app, or open a second X11- / desktop session.

Best regards,

Markus

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 12/9/23 12:13, Markus Robert Kessler wrote:

Dammit. I read above article and tested on Mageia and on Raspbian.
Assuming same behaviour on Ubuntu.

I'm not at all surprised.

The underlying -- so called -- problem has been well known and
understood by many in the Unix community for a long time.

In short, don't give untrusted people / apps / things access to your X11 display server.

So, quite slowly, I suspect more and more that Debian based distros are
not enabling su - / x-app right out of the box, by intention.

Not enabling `su -` in and of itself tends to come from a different
place, mostly one of trying to avoid the existence of the super user;
UID / GID of zero.

avoiding / denying super user (root) is a completely different discussion.

That being said, not going out of their way to enable cross user X11
access is probably somewhat intentional. Or at least insofar as
choosing to have people enable it if they want it, ostensibly assuming
that they understand the risks involved with doing so.

I already handled with caution to log into online banking during M$ teams meetings, because for audio in-/output they need access to the desktop,
and hence they could take screenshots from other windows like online
banking app.

If an X11 client application can access an X11 display server, then said
X11 client application can take a screen shot of said X11 display
server. They can also read keys / mouse or worse inject keys / move the mouse.

So, it looks like, the only proper approach is to completely log off from
the X11 session instead of su - / x-app, or open a second X11- / desktop session.

No, not really. The key thing to remember is that *any* *access* /to/
/an/ /X11/ /display/ /server/ is tantamount to *FULL* *ACCESS* /to/ /an/
/X11/ /display/ /server/.

With that in mind, it is critical to clarify what is the X11 display
server in each context.

Things like Xvnc and Xnest (whatever their actual names are today)
provide a /new/ /and/ /separate/ /X11/ /display/ /server/. As such an application that has access to X11 display server :10 doesn't inherently
have access to X11 display server :0.

The use of separate X11 display servers is critical.

With this in mind, you should be able to relatively safely run a virtual
X11 display server via Xvnc / Xnest / etc. and have less trusted
applications use it as their DISPLAY. Then use the proper viewer to
cause things on the virtual X11 display server to appear on your
physical X11 display server.

Things like Xvnc have the VNC protocol in separate / isolate the :0.0
X11 display server and the :10.0 X11 display server. This isolation
barrier makes it MUCH more difficult for things to pass through. What's
more is that Xvnc, et al. usually have much more control over what can
and can't pass through the protocol divide.

I remember reading about people running multiple X11 display servers
akin to virtual terminals (Control) Alt-F#. Wherein things on different
X11 display servers, which happen to use the same display hardware at different times, have separate data and are much more isolated from each other.



--
Grant. . . .

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: TNet Consulting (2:250/1@fidonet)

On Sat, 9 Dec 2023 18:13:36 -0000 (UTC)
Markus Robert Kessler <no_reply@dipl-ing-kessler.de> wrote:

So, it looks like, the only proper approach is to completely log off from the X11 session instead of su - / x-app, or open a second X11- / desktop session.

Or shut everything else down while doing private stuff. It's hard
to prevent screen scraping and key logging. If someone can get a keylogger
into one account they can probably get it into all accounts.

One important thing to think about when thinking about security is "what is the threat" - if screen scraping and key logging are the threat
then a dedicated session is a good answer, if browser hacks are the real
threat then a separate browser is all you need.

Always remember the only totally secure computer is turned off, in
a safe, buried in concrete with nobody alive who knows where it is. All
else is a compromise between security and usability,

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sat, 9 Dec 2023 12:44:53 -0600
Grant Taylor <gtaylor@tnetconsulting.net> wrote:

The underlying -- so called -- problem has been well known and
understood by many in the Unix community for a long time.

Since around the release of X11.

In short, don't give untrusted people / apps / things access to your X11 display server.

Yes exactly - X11 was designed with a politer more considerate set
of network users in mind (inside universities) - people who might play a
prank (run Xroach on all X displays in the lab or play strange noises
quietly through network audio[1]) but would never intend harm and would (mostly) carefully avoid looking at private information or at least not do anything with it but giggle.

It was a different world, the internet has spread to far less
pleasant people since then.

[1] I've seen both of these in places of work[2], to be fair the first did cause a scream! So perhaps not totally harmless pranks.

[2] We didn't have X terminals at college (circa 1980), but someone at Cambridge made the Enterprise fly round a room full of 80x25 terminals most
of which were in use at the time. Phoenix was easy to hack - so nobody
bothered except to do something fun and that was rare.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 12/9/23 12:57, Ahem A Rivet's Shot wrote:

Or shut everything else down while doing private stuff. It's hard
to prevent screen scraping and key logging. If someone can get a keylogger into one account they can probably get it into all accounts.

Providing any access to an X11 display server is tantamount to a key /
screen logger. It's actually worse than /just/ a logger in that it can
be a writer too.



--
Grant. . . .

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: TNet Consulting (2:250/1@fidonet)

Hi everyone,

I have suspected pam authentication already, and in the meantime I
compared Mageia and Raspbian more deeply regarding the entries in /etc/
pam.d.

I found out, that adding this line

session optional pam_xauth.so

to the front of /etc/pam.d/su

solves this issue. I've also tested this on Ubuntu successfully.

Now, after su - newuser, invoking an app for X11, like xclock, makes this window open and working.

Finally, big thanks to all of you for this wonderful and highly
interesting discussion!

Nevertheless, it turned out to be a good idea to always handle X / desktop sessions with care.

Thanks again,
best regards,

Markus





On Sat, 9 Dec 2023 11:54:38 -0000 (UTC) Markus Robert Kessler wrote:

On 9 Dec 2023 04:37:09 GMT Robert Riches wrote:

On 2023-12-08, Markus Robert Kessler <no_reply@dipl-ing-kessler.de>
wrote:

Hello everyone,

I'm just trying to switch the current user and then invoke some X11
application, but this does not work.

On Redhat-based machines this never was a problem and I need this
means to keep my axxounts separate from each other for security
reasons. E.g., I do a

'su - bank'
and after loggin in I can invoke 'chromium-browser
https://pathtoonlinebanking'

Now I see, that Debian-based Raspbian OS and Ubuntu (23.10) behave
very similar, it looks like this:

$ su - test1 Passwort:

$ firefox Error: no DISPLAY environment variable specified

$ DISPLAY=':0.0' firefox Authorization required, but no authorization
protocol specified

On Raspbian and on Ubuntu the same lets me assume that it was not me
to misconfigure something.

Can this be fixed easily? - Thanks!

Best regards,

Markus

It sounds like you're running into the XAUTH system.

Normally, in the home directory of the user who's running X stuff there
is a file called ".Xauthority", and environment variable XAUTHORITY
holds the full, absolute path to that file.

In order for user B to run X clients/apps when user A is the one who
started the X server, user B must set environment variable XAUTHORITY
to a file which user B has permission to read and which has the same
contents as user A's ~/.Xauthority.

How you get that file and environment variable set depends on your use
case. I run my web browsers, gimp, and a few other programs as a
different user for security and a few other reasons. I have wrapper
scripts that do the file copying,
environment variable setting, and environment variable preservation
across sudo and/or su. For the way I do all that,
user B's only reason for existence is to run browsers and such for user
A, and it's important that user A have write permission to user B's
home directory by means of the g+w permission bit.

Hi,

maybe there's a way around wrapper scripts?
I am wondering, why on Redhat-based systems like Mageia there is no need
for that, instead all this is done in background.

What I found out is, that when switching 'su - newaccount', then

- a file ~/.xauth* (e.g.: .xauthOa9EpX) is automatically created
(by su? by pam?)
- and when either starting x-app like xclock, so this works, or -
deleting this .xauth* and starting x-app, then above error occurs

This looks like su does all this "wrapping" automatically, as long as it
is confugured adequately. Maybe also systemd plays some role here.

Does anyone have more details here?
I am asking, because life would be easier, if this runs automaically :-)

Thanks!

Best regards,

Markus

--
Please reply to group only.
For private email please use http://www.dipl-ing-kessler.de/email.htm

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sat, 9 Dec 2023 13:39:16 -0600
Grant Taylor <gtaylor@tnetconsulting.net> wrote:

On 12/9/23 12:57, Ahem A Rivet's Shot wrote:

Or shut everything else down while doing private stuff. It's
hard to prevent screen scraping and key logging. If someone can get a keylogger into one account they can probably get it into all accounts.

Providing any access to an X11 display server is tantamount to a key / screen logger. It's actually worse than /just/ a logger in that it can
be a writer too.

This is true, and there are applications which depend on it.

One way to isolate applications completely would be to run each application in its own VM with its own X11 display (or Wayland) all
displayed in a real X11 display that does nothing but run VNC viewers to
the VMs. Nothing but a minimal window manager that launches VM sessions
runs in the real X11 display. This does require users to be able to launch
VMs - preferably ones that cannot be accessed by other users, if needs be a setuid tool could be used I suppose.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 12/9/23 15:23, Ahem A Rivet's Shot wrote:

One way to isolate applications completely would be to run each application in its own VM with its own X11 display (or Wayland) all
displayed in a real X11 display that does nothing but run VNC viewers to
the VMs. Nothing but a minimal window manager that launches VM sessions
runs in the real X11 display. This does require users to be able to launch VMs - preferably ones that cannot be accessed by other users, if needs be a setuid tool could be used I suppose.

I'm not convinced that VMs and the ability to start them are required.

I think you could get away with containers that each have their own
virtual X11 display server -- Xvnc for the sake of discussion -- would
likely suffice.

You can get quite close running each application as separate users on
the same system. Wherein each application has it's own virtual X11
display server (Xvnc).

But yes VMs will provide more isolation than containers which will
provide more isolation than separate users. It's all a question of
finding the balance for what is wanted vs what is needed and what
resources are available.

My personal goal is so that one application; e.g. Firefox, running as a dedicated user doesn't have access to all of my personal files that my
are accessed as my primary user.

Once you start going down the road of separation of the X11 display
server from the X11 client applications, options start opening up, e.g. running on different systems, OSs, architectures, etc.



Grant. . . .

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: TNet Consulting (2:250/1@fidonet)

On 12/9/23 15:25, Markus Robert Kessler wrote:

Hi everyone,

Hi,

I have suspected pam authentication already, and in the meantime I
compared Mageia and Raspbian more deeply regarding the entries in /etc/ pam.d.

Aside: I wouldn't call this "authentication" in this context. PAM has
grown to do more things than just "authentication". The very fact that
you are using the "session" module (?) supports that this isn't an authentication feature.

PAM is a very good place to do a lot of things to help streamline things related to client logins.

I found out, that adding this line

session optional pam_xauth.so

to the front of /etc/pam.d/su

N.B. My understanding is that the order of lines in PAM is important.
-- You are probably safe following another distro as a sample. But
don't sort the lines or anything like that.

solves this issue. I've also tested this on Ubuntu successfully.

Nice work.

Now, after su - newuser, invoking an app for X11, like xclock, makes this window open and working.

:-D

Finally, big thanks to all of you for this wonderful and highly
interesting discussion!

:-)

Nevertheless, it turned out to be a good idea to always handle X / desktop sessions with care.

Absolutely!

I think it's even better to have some idea that there is complexity
behind it and that there might be more to look up if / when you have
need to tilt at the X11 shaped wind mill.



--
Grant. . . .

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: TNet Consulting (2:250/1@fidonet)