KDE screen locker leaks peeks, once didn't work at all

[nvesely]

Very often, KDE's screen locker will activate and it will seem like the computer is just frozen, when really it is locked. If you enter in the password, it at that point unlocks and you can use it again. Other times, the desktop flashes when waking the screen up both by mouse if it had turned off while open, and by opening the laptop if I had closed it and suspended to RAM.

One time, after closing my laptop, it opened and I did not have to enter my password to resume using it. KDE's screen locker completely failed.

Yet other times, the screen will just glitch out instead of displaying the desktop (this case is not security critical, but a bug nonetheless). You can still unlock it by entering the password blind.

I consider this a security critical bug because part of the purpose of a screen locker is to prevent your desktop from being seen. Furthermore, even though it was one in a thousand, KDE failed to lock my screen. There should be zero margin of error here.

Running a Lenovo Yoga S1 w/ i7-4600U and BIOS: BOET20WW. All software from default Qubes repo (not current or w/e the one with the newer kernel is called).

[cfcs]

The only secure way to lock the screen in Linux (that I know of) is implemented in vlock.
Unfortunately the vlock-new module is not included in the (horribly outdated) version included in Fedora.
It can however be made to work, and it can also be combined with xautolock to lock the screen automatically.

It works by changing to a new TTY, issuing an ioctl to prevent TTY changing, and disables sysrq key combinations. I believe you'd probably want to read the entire systemd documentation as well to make sure it doesn't magically undo some of this -- unfortunately I haven't had time to do that yet.
link to vlock site

[cfcs]

The only secure way to lock the screen in Linux (that I know of) is implemented in vlock.
Unfortunately the vlock-new module is not included in the (horribly outdated) version included in Fedora.
It can however be made to work, and it can also be combined with xautolock to lock the screen automatically.

It works by changing to a new TTY, issuing an ioctl to prevent TTY changing, and disables sysrq key combinations. I believe you'd probably want to read the entire systemd documentation as well to make sure it doesn't magically undo some of this -- unfortunately I haven't had time to do that yet.
link to vlock site

[nvesely]

Ahh this has been brought up in #888, which was created in response to this https://groups.google.com/forum/#!topic/qubes-devel/G_wVSL9WtEk mailing list post.

I just spent a relatively long time procrastinating on my thesis and it seems like our best options are:

physlock: a fork of vlock that fixes the fact vlock doesn't support suspend/ hibernate. Also, it seems more actively maintained. It can be enforced by a systemd service as in muennich/physlock#10.

KDE 5.2 on Wayland: This method is probably way more work as it require getting KDE 5.2 running and could maybe be considered in the future. A KDE dev claims it is impossible to write a secure X11 screen locker and that this is fixed by the new Wayland kscreensaver in KDE 5.2: http://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/.

[nvesely]

Ahh this has been brought up in #888, which was created in response to this https://groups.google.com/forum/#!topic/qubes-devel/G_wVSL9WtEk mailing list post.

I just spent a relatively long time procrastinating on my thesis and it seems like our best options are:

physlock: a fork of vlock that fixes the fact vlock doesn't support suspend/ hibernate. Also, it seems more actively maintained. It can be enforced by a systemd service as in muennich/physlock#10.

KDE 5.2 on Wayland: This method is probably way more work as it require getting KDE 5.2 running and could maybe be considered in the future. A KDE dev claims it is impossible to write a secure X11 screen locker and that this is fixed by the new Wayland kscreensaver in KDE 5.2: http://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/.

[nvesely]

In issue #966 @marmarek mentions that Qubes 3.1 may move to Fedora 22, which will ship with either KDE 5.2.2 or 5.3 https://fedoraproject.org/wiki/Changes/Plasma_5. If as Martin Gräesslin states the new Wayland kscreen does securely lock the session, then it might be best to wait until 3.1 to resolve this issue.

In the mean time, if I wrote instructions on setting up physlock would you be interested in putting that on the wiki? I feel like it's one of those "we can't cleanly fix this atm--but you should still be aware of it and here's how you can fix it for yourself--issues." USBVM is another example like this.

[nvesely]

In issue #966 @marmarek mentions that Qubes 3.1 may move to Fedora 22, which will ship with either KDE 5.2.2 or 5.3 https://fedoraproject.org/wiki/Changes/Plasma_5. If as Martin Gräesslin states the new Wayland kscreen does securely lock the session, then it might be best to wait until 3.1 to resolve this issue.

In the mean time, if I wrote instructions on setting up physlock would you be interested in putting that on the wiki? I feel like it's one of those "we can't cleanly fix this atm--but you should still be aware of it and here's how you can fix it for yourself--issues." USBVM is another example like this.

[nrgaway]

That would be helpful and I would also suggest you create a topic i the users mail list as well

[nrgaway]

That would be helpful and I would also suggest you create a topic i the users mail list as well

[nvesely]

Anyone have a good way of copying files into dom0? I cloned the physlock repo in a dispvm then tried for i in $( qvm-run --pass-io <src_domain> 'ls /path/to/folder_in_src_domain' ); do qvm-run --pass-io <src_domain> 'cat /path/to/folder_in_src_domain/$i' > /path/to/folder_name_in_dom0/$i; done, but it didn't work correctly (not sure why).

[nvesely]

Anyone have a good way of copying files into dom0? I cloned the physlock repo in a dispvm then tried for i in $( qvm-run --pass-io <src_domain> 'ls /path/to/folder_in_src_domain' ); do qvm-run --pass-io <src_domain> 'cat /path/to/folder_in_src_domain/$i' > /path/to/folder_name_in_dom0/$i; done, but it didn't work correctly (not sure why).

[nrgaway]

On 26 April 2015 at 15:51, Noah Vesely notifications@github.com wrote:

Anyone have a good way of copying files into dom0? I cloned the physlock
repo in a dispvm then tried for i in $( qvm-run --pass-io <src_domain>
'ls /path/to/folder_in_src_domain' ); do qvm-run --pass-io <src_domain>
'cat /path/to/folder_in_src_domain/$i' > /path/to/folder_name_in_dom0/$i;
done, but it didn't work correctly (not sure why).

IMO, this also does not seem like a Qubes issue.

You might get a better response to ask this on the mailing list
https://groups.google.com/forum/#!forum/qubes-users since this more people
frequent it than the issues area.

[nrgaway]

On 26 April 2015 at 15:51, Noah Vesely notifications@github.com wrote:

Anyone have a good way of copying files into dom0? I cloned the physlock
repo in a dispvm then tried for i in $( qvm-run --pass-io <src_domain>
'ls /path/to/folder_in_src_domain' ); do qvm-run --pass-io <src_domain>
'cat /path/to/folder_in_src_domain/$i' > /path/to/folder_name_in_dom0/$i;
done, but it didn't work correctly (not sure why).

IMO, this also does not seem like a Qubes issue.

You might get a better response to ask this on the mailing list
https://groups.google.com/forum/#!forum/qubes-users since this more people
frequent it than the issues area.

[nvesely]

@nrgaway I wasn't suggesting it was a Qubes Issue :-) What is meant by your use of 'also'? Confusing as my original post certainly did refer to a Qubes issue. I was just asking for a bit of help on making a fix.

[nvesely]

@nrgaway I wasn't suggesting it was a Qubes Issue :-) What is meant by your use of 'also'? Confusing as my original post certainly did refer to a Qubes issue. I was just asking for a bit of help on making a fix.

[nrgaway]

On 26 April 2015 at 19:38, Noah Vesely notifications@github.com wrote:

@nrgaway https://github.com/nrgaway I wasn't suggesting it was a Qubes
Issue :-) What is meant by your use of 'also'? Confusing as my original
post certainly did refer to a Qubes issue. I was just asking for a bit of
help on making a fix.

Yes that would be confusing; 'also' was a typo since I moved that part it
from the end of sentence to beginning. My only point was you may find an
answer sooner if posted in the main group since more users tend to follow
that group to help you find a solution. Apologize for any confusion there
:)

[nrgaway]

On 26 April 2015 at 19:38, Noah Vesely notifications@github.com wrote:

@nrgaway https://github.com/nrgaway I wasn't suggesting it was a Qubes
Issue :-) What is meant by your use of 'also'? Confusing as my original
post certainly did refer to a Qubes issue. I was just asking for a bit of
help on making a fix.

Yes that would be confusing; 'also' was a typo since I moved that part it
from the end of sentence to beginning. My only point was you may find an
answer sooner if posted in the main group since more users tend to follow
that group to help you find a solution. Apologize for any confusion there
:)

[cfcs]

@fowlslegs : thanks for pointing out physlock, that's great! You can probably solve your problem by using tar/cpio for now, even if it's a bit silly that you can't copy files into dom0 using qvm-copy-to-vm. Or copy-paste for that matter - what the actual fuck?

Regarding KDE 5.x on Wayland: That'd require changing away from Xorg, wouldn't it -- wouldn't that mean that someone will have to patch the framebuffer code currently used to display VM contents, and the code for mouse / focus / keyboard handling? I haven't dived into the patchset required to get Xorg working, but it sounds like this might be a larger undertaking?

I moved away from KDE in Qubes since the screen would randomly freeze and stop accepting any kind of input, rendering the machine useless as a desktop for all intents and purposes (SSH and networking still worked flawlessly). I would hate to have the XFCE/"run-your-own" removed, and I feel that physlock seems both like a sounder and more portable solution. Just my 2 cents.

[cfcs]

@fowlslegs : thanks for pointing out physlock, that's great! You can probably solve your problem by using tar/cpio for now, even if it's a bit silly that you can't copy files into dom0 using qvm-copy-to-vm. Or copy-paste for that matter - what the actual fuck?

Regarding KDE 5.x on Wayland: That'd require changing away from Xorg, wouldn't it -- wouldn't that mean that someone will have to patch the framebuffer code currently used to display VM contents, and the code for mouse / focus / keyboard handling? I haven't dived into the patchset required to get Xorg working, but it sounds like this might be a larger undertaking?

I moved away from KDE in Qubes since the screen would randomly freeze and stop accepting any kind of input, rendering the machine useless as a desktop for all intents and purposes (SSH and networking still worked flawlessly). I would hate to have the XFCE/"run-your-own" removed, and I feel that physlock seems both like a sounder and more portable solution. Just my 2 cents.

[nvesely]

@cfcs I agree on the dom0 file transfer comment. There should definitely be a confirmation dialog so that we don't move something into dom0 by accident, but a tool should exist nonetheless for this purpose.

Anyway, I have physlock and xautolock set up now like so:

[Unit]
Description=Lock X session
Before=sleep.target

[Service]
Type=forking
ExecStart=/usr/local/bin/physlock -ds -u root
Restart=on-failure

[Install]
WantedBy=sleep.target

This service runs on suspend. -d forks and detaches physlock, which works as desired with qubes-suspend.service, and -s disables SysRq which may be used to kill physlock (see https://en.wikipedia.org/wiki/Magic_SysRq_key). Finally, the -u root option passed to physlock here makes it so that root is the only user who can unlock the system. This way I don't have to type 'fowlslegs' or 'root' before entering my password when the screen is locked.

[Unit]
Description=Lock the screen automatically after a timeout

[Service]
Type=simple
User=<username>
Environment=DISPLAY=:0
ExecStart=/usr/bin/xautolock  -time 10 -corners 000- -locker "/usr/local/bin/physlock -ds -u root" -detectsleep

[Install]
WantedBy=graphical.target

This service locks the screen after 10 minutes of idle time, unless your mouse is in the very bottom right corner as specified by the -corners 000- (which is useful for watching videos). -detectsleep has been working correctly with suspend as well, i.e., the timer on the locker resets and doesn't start again until it recognizes the computer is awake again.

Other than that, I disabled KDE's screen locker entirely and remapped Ctrl+Alt+L to /usr/bin/xautolock -locknow.

Before I post this for the group and maybe wiki it would be nice if one or more of you could test this out and let me know if you run into any problems.

[nvesely]

@cfcs I agree on the dom0 file transfer comment. There should definitely be a confirmation dialog so that we don't move something into dom0 by accident, but a tool should exist nonetheless for this purpose.

Anyway, I have physlock and xautolock set up now like so:

[Unit]
Description=Lock X session
Before=sleep.target

[Service]
Type=forking
ExecStart=/usr/local/bin/physlock -ds -u root
Restart=on-failure

[Install]
WantedBy=sleep.target

This service runs on suspend. -d forks and detaches physlock, which works as desired with qubes-suspend.service, and -s disables SysRq which may be used to kill physlock (see https://en.wikipedia.org/wiki/Magic_SysRq_key). Finally, the -u root option passed to physlock here makes it so that root is the only user who can unlock the system. This way I don't have to type 'fowlslegs' or 'root' before entering my password when the screen is locked.

[Unit]
Description=Lock the screen automatically after a timeout

[Service]
Type=simple
User=<username>
Environment=DISPLAY=:0
ExecStart=/usr/bin/xautolock  -time 10 -corners 000- -locker "/usr/local/bin/physlock -ds -u root" -detectsleep

[Install]
WantedBy=graphical.target

This service locks the screen after 10 minutes of idle time, unless your mouse is in the very bottom right corner as specified by the -corners 000- (which is useful for watching videos). -detectsleep has been working correctly with suspend as well, i.e., the timer on the locker resets and doesn't start again until it recognizes the computer is awake again.

Other than that, I disabled KDE's screen locker entirely and remapped Ctrl+Alt+L to /usr/bin/xautolock -locknow.

Before I post this for the group and maybe wiki it would be nice if one or more of you could test this out and let me know if you run into any problems.

[nvesely]

....Aaaaand something just failed on suspend. Tty4 was locked by physlock, but I was able to get to tty1 where my running X session was. I have tried probably 15 times to replicate this, but can't.

[nvesely]

....Aaaaand something just failed on suspend. Tty4 was locked by physlock, but I was able to get to tty1 where my running X session was. I have tried probably 15 times to replicate this, but can't.

[cfcs]

You should really suspend-to-disk anyway, the other thing leaves your computer rather vulnerable ?

[cfcs]

You should really suspend-to-disk anyway, the other thing leaves your computer rather vulnerable ?

[nvesely]

I'm going to take a guess you're hinting at spraying my memory with liquid nitrogen.

the other thing

Suspending to RAM/ S3?

suspend-to-disk anyway

Assume I've interpreted you right above, isn't my key just loaded back into memory at that point and oh-so-cold-boot-attackable?

[nvesely]

I'm going to take a guess you're hinting at spraying my memory with liquid nitrogen.

the other thing

Suspending to RAM/ S3?

suspend-to-disk anyway

Assume I've interpreted you right above, isn't my key just loaded back into memory at that point and oh-so-cold-boot-attackable?

[cfcs]

Indeed, that's one way to go about it. But isn't the purpose of that specific attack to keep the ram contents fresh? In this case the attacker may grab your laptop and keep it powered on, but suspended, for (potentially) years while shopping for connectors on ebay that allows them to read out the memory using the regular control channels?

Assume I've interpreted you right above, isn't my key just loaded back into memory at that point and oh-so-cold-boot-attackable?

Yes, a problem, but at least you will be able to have tools running on the machine that aim to detect such tampering. And you may or may not have glued the memory to the motherboard, making it hard to remove (intact and with data preserved, at least) in the time span allowed by the liquid nitrogen cooling.

Another point may be that if you don't do supend-to-disk, physlock most likely won't give people access to TTY1 when they shouldn't have it ;)

---

Theoretical arguing aside, thanks for sharing the physlock configurations! o/

[cfcs]

Indeed, that's one way to go about it. But isn't the purpose of that specific attack to keep the ram contents fresh? In this case the attacker may grab your laptop and keep it powered on, but suspended, for (potentially) years while shopping for connectors on ebay that allows them to read out the memory using the regular control channels?

Assume I've interpreted you right above, isn't my key just loaded back into memory at that point and oh-so-cold-boot-attackable?

Yes, a problem, but at least you will be able to have tools running on the machine that aim to detect such tampering. And you may or may not have glued the memory to the motherboard, making it hard to remove (intact and with data preserved, at least) in the time span allowed by the liquid nitrogen cooling.

Another point may be that if you don't do supend-to-disk, physlock most likely won't give people access to TTY1 when they shouldn't have it ;)

---

Theoretical arguing aside, thanks for sharing the physlock configurations! o/

[nvesely]

There is a lot to be said on the above, and I don't have time to write a full response during finals week, but I will eventually reply.

Back to the main topic at hand, would you be willing to test this out @cfcs?

[nvesely]

There is a lot to be said on the above, and I don't have time to write a full response during finals week, but I will eventually reply.

Back to the main topic at hand, would you be willing to test this out @cfcs?

[cfcs]

Yes, I'm running it now. Will be back with feedback.

[cfcs]

Yes, I'm running it now. Will be back with feedback.

[cfcs]

I've had it running for a few weeks with your proposed .service files.
physlock seems to be doing its job, but xautolock has been hard to coerce into cooperation.

I've had issues such as:

1. xautolock dying completely, and failing to start again, when the user logs out and back in again. (can happen when x session crashes, which it frequently does with KDE on my machine)
2. xautolock failing to start (some kind of race condition on login?)

Perhaps relevant:

• http://askubuntu.com/questions/20585/how-to-lock-xscreensaver-on-suspend
• http://unix.stackexchange.com/questions/158687/systemd-locking-the-console

Scripts in /usr/lib/systemd/system-sleep/ will be executed pre and post suspension|hibernation when using systemctl suspend, so you can add a script to start vlock from there.

• http://www.freedesktop.org/software/systemd/man/systemd-suspend.service.html

It's entirely possible that I screwed up the systemd/systemctl config for your services.
Are you facing similar issues?

BTW: Files of potential interest:

• /etc/systemd/logind.conf
• (XFCE) /etc/xdg/autostart/inhibit-systemd-power-handling.desktop

[cfcs]

I've had it running for a few weeks with your proposed .service files.
physlock seems to be doing its job, but xautolock has been hard to coerce into cooperation.

I've had issues such as:

1. xautolock dying completely, and failing to start again, when the user logs out and back in again. (can happen when x session crashes, which it frequently does with KDE on my machine)
2. xautolock failing to start (some kind of race condition on login?)

Perhaps relevant:

• http://askubuntu.com/questions/20585/how-to-lock-xscreensaver-on-suspend
• http://unix.stackexchange.com/questions/158687/systemd-locking-the-console

Scripts in /usr/lib/systemd/system-sleep/ will be executed pre and post suspension|hibernation when using systemctl suspend, so you can add a script to start vlock from there.

• http://www.freedesktop.org/software/systemd/man/systemd-suspend.service.html

It's entirely possible that I screwed up the systemd/systemctl config for your services.
Are you facing similar issues?

BTW: Files of potential interest:

• /etc/systemd/logind.conf
• (XFCE) /etc/xdg/autostart/inhibit-systemd-power-handling.desktop

[nvesely]

For me what was happening is systemd would reach graphical target before xautolock could connect to display :0 and the unit would fail to launch. By adding the lines Restart=on-failure and RestartSec=10 this was fixed. RestartSec is necessary because w/o delay systemd will just restart the unit rapidly over and over until it decides it has tried too many times and then will override the Restart=on-failure line and just let it permanently fail. It seems graphical.target may be reached as soon as plymouth is displayed, but before X is connected. This would make sense as to why xautlock cannot start.

You can check w/ journalctl -u xautolock why it's failing for you, but I imagine it might be for the same reason. Fixed file looks like this:

[Unit]
Description=Lock the screen automatically after a timeout

[Service]
Type=simple
User=<username>
Environment=DISPLAY=:0
ExecStart=/usr/bin/xautolock  -time 10 -corners 000- -locker "/usr/local/bin/physlock -ds -u root" -detectsleep
Restart=on-failure
RestartSec=10

[Install]
WantedBy=graphical.target

[nvesely]

For me what was happening is systemd would reach graphical target before xautolock could connect to display :0 and the unit would fail to launch. By adding the lines Restart=on-failure and RestartSec=10 this was fixed. RestartSec is necessary because w/o delay systemd will just restart the unit rapidly over and over until it decides it has tried too many times and then will override the Restart=on-failure line and just let it permanently fail. It seems graphical.target may be reached as soon as plymouth is displayed, but before X is connected. This would make sense as to why xautlock cannot start.

You can check w/ journalctl -u xautolock why it's failing for you, but I imagine it might be for the same reason. Fixed file looks like this:

[Unit]
Description=Lock the screen automatically after a timeout

[Service]
Type=simple
User=<username>
Environment=DISPLAY=:0
ExecStart=/usr/bin/xautolock  -time 10 -corners 000- -locker "/usr/local/bin/physlock -ds -u root" -detectsleep
Restart=on-failure
RestartSec=10

[Install]
WantedBy=graphical.target

[cfcs]

That did the trick for me. I've been using it for a few days, and both automatic locking and ctrl/alt/L work.

I think this would be a good solution for Qubes, but right now the need to set a root password might be undesirable - perhaps we should patch it to allow specifying the user on the commandline (disabling the prompt)?

[cfcs]

That did the trick for me. I've been using it for a few days, and both automatic locking and ctrl/alt/L work.

I think this would be a good solution for Qubes, but right now the need to set a root password might be undesirable - perhaps we should patch it to allow specifying the user on the commandline (disabling the prompt)?

[nvesely]

Why might setting a root password be undesirable?

[nvesely]

Why might setting a root password be undesirable?

[cfcs]

Because it's not currently enforced by the installer, so if an update is made to Qubes that makes physlock the default solution, people who (currently) don't have a root password will be locked out of their laptops. It is also more maintenance for the user since you need to remember to change both your user and root passwords to change "log in" and "screen lock" passwords respectively.

I ran into some cases where the screen lock would fail to initialize. It seems to be an issue with physlock being launched several times, leaving one of them hanging when you unlock either (since that frees the screen). This in turn causes xautolock to fail to lock the screen (since, technically speaking, it's already "locked" by a lock command that hasn't returned).

Running sudo killall physlock after returning from physlock seems to fix the problem, so I've added that to my service spec now, but not sure it's the best solution. Thoughts?

[cfcs]

Because it's not currently enforced by the installer, so if an update is made to Qubes that makes physlock the default solution, people who (currently) don't have a root password will be locked out of their laptops. It is also more maintenance for the user since you need to remember to change both your user and root passwords to change "log in" and "screen lock" passwords respectively.

I ran into some cases where the screen lock would fail to initialize. It seems to be an issue with physlock being launched several times, leaving one of them hanging when you unlock either (since that frees the screen). This in turn causes xautolock to fail to lock the screen (since, technically speaking, it's already "locked" by a lock command that hasn't returned).

Running sudo killall physlock after returning from physlock seems to fix the problem, so I've added that to my service spec now, but not sure it's the best solution. Thoughts?

[nvesely]

They wouldn't actually be locked out of their laptops. At first I tried w/o setting root passwd first (see muennich/physlock/issues/17) and instead it allowed me to unlock w/ any passwd.

As an alternate approach to what I have thus far proposed, I was thinking we could instead make the X server require that the xautolock service is running.

I have a feeling that the Qubes team wants a GUI locker to keep Qubes feeling and looking (reasonably) easy to use. Maybe you can give some input on this @marmarek?

Could you maybe briefly explain how GUI domain will affect this?

Will the GUI domain be running X or Wayland?

Should I add something to the wiki about this, perhaps after further consideration and possible changes of the xautolock service?

[nvesely]

They wouldn't actually be locked out of their laptops. At first I tried w/o setting root passwd first (see muennich/physlock/issues/17) and instead it allowed me to unlock w/ any passwd.

As an alternate approach to what I have thus far proposed, I was thinking we could instead make the X server require that the xautolock service is running.

I have a feeling that the Qubes team wants a GUI locker to keep Qubes feeling and looking (reasonably) easy to use. Maybe you can give some input on this @marmarek?

Could you maybe briefly explain how GUI domain will affect this?

Will the GUI domain be running X or Wayland?

Should I add something to the wiki about this, perhaps after further consideration and possible changes of the xautolock service?

[nvesely]

Physlock now does a dry run to make sure root pwd is set: muennich/physlock@d56d19e

[nvesely]

Physlock now does a dry run to make sure root pwd is set: muennich/physlock@d56d19e

[cfcs]

Any news on the planned "GUI vm"? That could have an impact on this.

[cfcs]

Any news on the planned "GUI vm"? That could have an impact on this.

[marmarek]

On Thu, Jul 16, 2015 at 06:03:54AM -0700, cfcs wrote:

Any news on the planned "GUI vm"? That could have an impact on this.

We plan to implement it somewhere in 2016.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Thu, Jul 16, 2015 at 06:03:54AM -0700, cfcs wrote:

Any news on the planned "GUI vm"? That could have an impact on this.

We plan to implement it somewhere in 2016.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[talex5]

Another interesting failure mode happened to me today. On resuming from suspend, the lock screen appeared but nothing appeared in the password box when I tried to enter my password and I couldn't seem to log in. After rebooting, I discovered I'd sent my password to an online chat forum I'd had open at the time.

[talex5]

Another interesting failure mode happened to me today. On resuming from suspend, the lock screen appeared but nothing appeared in the password box when I tried to enter my password and I couldn't seem to log in. After rebooting, I discovered I'd sent my password to an online chat forum I'd had open at the time.

[rootkovska]

We hope this problem will be resolved once we switch to Gnome in Qubes 4

[rootkovska]

We hope this problem will be resolved once we switch to Gnome in Qubes 4

[v6ak]

Is the transition to Gnome discussed somewhere? (My concerns: Does it imply dropping Kwin support? What alternative WMs will be supported?)

[v6ak]

Is the transition to Gnome discussed somewhere? (My concerns: Does it imply dropping Kwin support? What alternative WMs will be supported?)

[cfcs]

@rootkovska The problem is not KDE; it's Xorg. I don't actually use KDE, and only briefly did. I moved to xfce, and then awesomewm, after I experienced issues with KDE repeatedly freezing my X session, leaving me with a forced (hold power button) reboot as the only way out.

Does Gnome 4 have a radically different approach to screenlocking (Wayland?) - if so, do you have a link to some background information on the new approach?

[cfcs]

@rootkovska The problem is not KDE; it's Xorg. I don't actually use KDE, and only briefly did. I moved to xfce, and then awesomewm, after I experienced issues with KDE repeatedly freezing my X session, leaving me with a forced (hold power button) reboot as the only way out.

Does Gnome 4 have a radically different approach to screenlocking (Wayland?) - if so, do you have a link to some background information on the new approach?

[nvesely]

I was using GNOME on my work machine actually and occasionally ran into screenlocker problems, although less frequently. @cfcs is correct, the problem cannot be solved within X (see again http://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/), however, a switch to GNOME might make it a lesser issue. I think the real fix will come in a couple years when Qubes moves to Wayland. Gotta keep in mind that physical access to your machine while powered on is very understandably out of the Qubes threat model.

[nvesely]

I was using GNOME on my work machine actually and occasionally ran into screenlocker problems, although less frequently. @cfcs is correct, the problem cannot be solved within X (see again http://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/), however, a switch to GNOME might make it a lesser issue. I think the real fix will come in a couple years when Qubes moves to Wayland. Gotta keep in mind that physical access to your machine while powered on is very understandably out of the Qubes threat model.

[cfcs]

This is also interesting. ping @fowlslegs
https://github.com/the-cavalry/light-locker/

[cfcs]

This is also interesting. ping @fowlslegs
https://github.com/the-cavalry/light-locker/