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

On 12/8/2023 2:38 PM, Markus Robert Kessler 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
>

X11 is old enough, we forget some of the moving parts.
A part of my brain says "xauth", but I don't remember
the moving parts well enough to advise.

https://linux.die.net/man/1/xauth

"This program is usually used to extract authorization records from one machine
and merge them in on another (as is the case when using remote logins
or granting access to other users) <===

One other thing that X11 may not like, is when applications
using X11 run as root. How the detection of that works
(normal xauth or special case code), again, I don't know
the details. All I remember is the odd application will
say something about "don't run as root". The issue is X11
could be an attack surface, and elevating code which has
a significant attack surface is considered to be a bad idea.
Like, running Firefox as root, would be "extremely bad" :-)
Even with a Snap container, who can even guess what the
risk level is.

Paul

On 12/8/2023 11:38 AM, Markus Robert Kessler 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.
>
>

I believe you need to use xhost to add test1 as authorized to connect.

Before you do the su, issue the following command from a terminal
window:

xhost +test1

In comp.sys.raspberry-pi red floyd <no.spam.here@its.invalid> wrote:
> On 12/8/2023 11:38 AM, Markus Robert Kessler wrote:
>>
>> $ 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.
>
> I believe you need to use xhost to add test1 as authorized to connect.

Xhost is for allowing connections from other computers, so it would
only make sense if test1 was the name of another computer on the
network, not a user. The use of test1 with the "su" command
suggests that's not the case.

--
__ __
#_ < |\| |< _# | Note: I won't see posts made from Google Groups |

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.

HTH

--
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

On 12/8/23 11:38, Markus Robert Kessler 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

make sure xauth is installed.
you'll probably just have to do as your normal user:
xauth list $DISPLAY

then use xauth add that output into your su/sudo user's .Xauthority file

https://www.simplified.guide/ssh/x11-forwarding-as-root

On 12/8/23 23:22, stepore wrote:
> make sure xauth is installed.
> you'll probably just have to do as your normal user:
> xauth list $DISPLAY
>
> then use xauth add that output into your su/sudo user's .Xauthority file
>
> https://www.simplified.guide/ssh/x11-forwarding-as-root

+2 for xauth

Xauth uses cryptographic tokens -- called MIT magic cookies -- to
authenticate X11 client applications with the X11 display server that
you want to connect to.

The MIT magic cookies are per user.

Conversely xhost is per host.

So if you want more granular than an IP level, you want to use xauth.

I am using something like the following to run Firefox and Thunderbird
remotely using X11 across the network to display on what is effectively
an X11 display server.

xauth extract - ${HOST}${DISPLAY} | ssh user@remote "xauth merge -;
thunderbird ${@}"

N.B. I'm *NOT* using SSH's X11 forwarding. The X11 traffic travels
outside of / parallel to the SSH stream. SSH is only used to import the
current MIT magic cookie and to launch the thunderbird binary. I could
just as easily log into a serial console on the remote system and launch
the thunderbird binary, assuming I had the MIG magic cookie in place.

It seems like the MIT magic cookie change each boot / time I start the
X11 display server. But, for simplicity, I extract the MIT magic cookie
from the X11 display server and import it on the remote X11 client
system each time I launch the thunderbird binary.

${HOST} is the FQDN of the X11 display server as known internally on my
network.
${DISPLAY} is :0.0 for the first display on the X11 display server.

--
Grant. . . .

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

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.

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

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

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

--
https://www.greenend.org.uk/rjk/

On 12/9/23 08:56, Richard Kettlewell wrote:
> However, that isolation does not exist in the X11 model.

Yes, X11 does have some security concerns, particularly around screen
shot, clipboard, and reading keyboard / mouse.

However, if you are extending authorization to for another user to
access your X11 session, I would hope that you also trust the user to
not abuse those privileges.

What's more is that if the different users use judicious file
permissions, users can't access each other's files at the file system
level and I'm not aware of any X11 method to access other users files.

So as far as I understand it, there is /some/ merit to running X11
applications as different users.

> http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html

I've not read the article yet.

--
Grant. . . .

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

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. . . .

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

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

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. . . .

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

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

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. . . .

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. . . .

On 08/12/2023 19:38, Markus Robert Kessler 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
>

I may not be understanding correctly, but why not use a different
terminal to access the test1 user?
Ctrl-Alt-F[2345] to get a new terminal, log in as test1 and then run startx.
This would seem, to me, to give you a completely separate, private, X
session.
I stand ready to be corrected.

--
Chris Elvidge, England
I WILL NOT CHARGE ADMISSION TO THE BATHROOM

On 12/10/23 07:49, Chris Elvidge wrote:
> I may not be understanding correctly, but why not use a different
> terminal to access the test1 user?

Not everybody knows or cares to do that.

> Ctrl-Alt-F[2345] to get a new terminal, log in as test1 and then run
> startx.

Not all Linux / X11 / WM / DE configurations support doing that.

Not all graphics hardware / X11 servers therefor will support that.

> This would seem, to me, to give you a completely separate, private, X
> session.

It is much more private.

But it's also more disruptive.

There is likely no way to directly share things like the clipboard
between the multiple X11 sessions.

> I stand ready to be corrected.

I'm sure there are ways to overcome many, if not most, of the problems.
But this is an atypical / not out of the box solution that will probably
only be acceptable for a few.

Could it work in the proper configuration, absolutely.

Is your average home system / college starter notebook going to support
it out of the box? I doubt it.

--
Grant. . . .

On Sun, 10 Dec 2023 13:49:56 +0000
Chris Elvidge <chris@mshome.net> wrote:

> I may not be understanding correctly, but why not use a different
> terminal to access the test1 user?
> Ctrl-Alt-F[2345] to get a new terminal, log in as test1 and then run
> startx. This would seem, to me, to give you a completely separate,
> private, X session.

That should work fine, but remember VT switching doesn't lock
screens.

--
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