search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
534 stars 46 forks source link

Change default screen locker from XScreenSaver #1917

Open mfc opened 8 years ago

mfc commented 8 years ago

Editor's note: This issue has evolved beyond the original issue description. Please see the comments below for more recent information about this issue.

Qubes OS version (e.g., R3.1): R3.1

Expected behavior:

lock screen looks like log-in screen

Actual behavior:

lock screen looks wacky-different. also ugly.

Steps to reproduce the behavior:

lock screen in XFCE

General notes:

see this Ask Ubuntu for reasons why this is a bad lockscreen: https://askubuntu.com/questions/216323/ugly-lock-screen-in-xubuntu

perhaps switch to gnome-screensaver as suggested in the Ask Ubuntu thread.

marmarek commented 8 years ago

I agree that xscreensaver is ugly. But it is effective. And given a number of problems with other screenlockers (#888, #963), not sure if it wise to change it here. Requires a lot of testing. Actually it may be better to switch to something even uglier - physlock, in all desktop environments.

ghost commented 8 years ago

Indeed there have been quite a few problems with the alternatives in the past https://www.jwz.org/blog/2015/04/i-told-you-so-again/

mfc commented 8 years ago

is there any setting in xscreensaver to have it look like the XFCE log-in screen, rather than the default screensaver screen? having them look the same would be a step forward in UX, and the XFCE log-in screen certainly looks better.

marmarek commented 8 years ago

I'm not aware of any, unfortunately. There are settings for screen saver itself, but not for password prompt.

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?

cfcs commented 8 years ago

XScreensaver is a security disaster. There is a long discussion / evaluation here: https://github.com/QubesOS/qubes-issues/issues/963

It's my personal opinion that spending time on prettifying a lock screen is great, but the work should be done on a screenlocking solution that we actually want to use. Please have a look at the two suggestions below:

mfc commented 8 years ago

XScreensaver is a security disaster.

confirmed: #2026

cfcs commented 8 years ago

I'm going to be bold and suggest that the KDE lock screen, apart from issues with random crashes, has similar issues related to stuff popping up on top, especially at times when you (or an attacker) attaches/detaches VGA/HDMI/whatever cables, or rotates monitors and so on.

Physlock is the way to go.

andrewdavidwong commented 7 years ago

XScreensaver is a security disaster. There is a long discussion / evaluation here:

963

No, that's a discussion of the KDE screen locker, which (as you know) is different. The only thing about XScreenSaver in that thread is a link to a problem with suspend. XScreenSaver is actually one of the more secure screen lockers available (which perhaps isn't saying much). At any rate, it does sound like physlock would be better.

XScreensaver is a security disaster.

confirmed: #2026

This, however, appears to be a legitimate security issue with XScreenSaver.

cfcs commented 7 years ago

@andrewdavidwong I kind of disagree, did you read the discussion? Anyway, the most important link in there, which I'd like to repost, is this one (by a KDE developer) who explains why the KDE screen locker is not sufficient, and why Xorg-based screen lockers are inherently insecure: http://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/

So, I restate my opinion about physlock and would like to hear some arguments against it. :)

andrewdavidwong commented 7 years ago

I kind of disagree,

You kind of disagree with what?

did you read the discussion?

Yes. I would not have said what I did if I had not.

Anyway, the most important link in there, which I'd like to repost, is this one (by a KDE developer) who explains why the KDE screen locker is not sufficient, and why Xorg-based screen lockers are inherently insecure: http://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/

What does this have to do with anything I said?

So, I restate my opinion about physlock and would like to hear some arguments against it. :)

What did I say that requires an argument against physlock or your opinion about physlock?

cfcs commented 7 years ago

No, that's a discussion of the KDE screen locker, which (as you know) is different.

@andrewdavidwong I kind of disagree, did you read the discussion?

You kind of disagree with what?

That the discussion is about the KDE screen locker [and all other Xorg-based screen lockers] is irrelevant to discussion of XScreenSaver security. The link provided in my comment above highlights why XScreenSaver (and the KDE screen locker, and all the other ones) is an attempt to solve the problem using an inherently insecure approach.

So, I restate my opinion about physlock and would like to hear some arguments against it. :)

What did I say that requires an argument against physlock or your opinion about physlock?

Nothing, except that XScreenSaver was one of the more secure projects around. That remark was meant for everyone, including @marmarek and people who can decide what goes into Qubes. I realize physlock is not very pretty, but perhaps it could be an optional thing? :)

PS: XScreenSaver nostalgia: http://insecure.org/sploits/xscreensaver.html ;)

andrewdavidwong commented 7 years ago

That the discussion is about the KDE screen locker [and all other Xorg-based screen lockers] is irrelevant to discussion of XScreenSaver security. The link provided in my comment above highlights why XScreenSaver (and the KDE screen locker, and all the other ones) is an attempt to solve the problem using an inherently insecure approach.

You specifically said "XScreensaver is a security disaster," so, naturally, I thought you were referring specifically to... XScreenSaver. If your comment was supposed to be about all Xorg-based screen lockers, then of course I agree. This is a point I raised about Qubes years ago:

https://groups.google.com/d/topic/qubes-devel/G_wVSL9WtEk/discussion

Nothing, except that XScreenSaver was one of the more secure projects around.

I said it's "one of the more screen lockers available (which perhaps isn't saying much). At any rate, it does sound like physlock would be better." As far as Xorg-based screen lockers go, I think it does better than most, but I also agree that Xorg-based screen lockers as a whole are problematic (again, this is all in the old thread linked above).

That remark was meant for everyone, including @marmarek and people who can decide what goes into Qubes. I realize physlock is not very pretty, but perhaps it could be an optional thing? :)

When it comes to security-critical components, I don't think prettiness should matter much, and I don't think a significantly more secure solution should be merely optional. It should be the default.

marmarek commented 7 years ago

What about light-locker? It spawns a second X server and switch to it for the locking. There are some technical difficulties with running a second X server in dom0, but I think it should be manageable.

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

jpouellet commented 7 years ago

We are in a unique position to be able to solve this once and for all in a more robust way than any other X-based system I am aware of.

We should be able to just kill and restart the entire dom0 X session (or s/dom0/GuiVM/ when we get there). This would not rely on your system not accidentally killing the screen locker, or accidentally making VTs available.

I've had this idea for a while, but implementation is blocked on not some issue reconnecting to already-running gui-daemons that I haven't gotten around to debugging. The same thing needs to be fixed to be able to log out and log back in (which happens sometimes, like when restoring a large VM backup and the OOM killer gets triggered in dom0 and decides X looks like the best candidate... sigh) instead of needing to reboot your whole machine.

jpouellet commented 7 years ago

The important thing to note is that we could do this without losing state about the currently logged-in session, because the AppVM X sessions stay alive but can be rendered inaccessible in a fail-closed manner unlike on other systems with a single X session connected to both the display and the apps you wish to protect needs to stay alive.

marmarek commented 7 years ago

Killing dom0 X session is not harmless. GUI daemon tries its best to recover what's possible but not everything is possible. For example:

Some of those probably could be solved somehow, but in general touching anything around X11 handling is very risky. There are so many different toolkits, or even custom implementations that almost every change here breaks some application...

cfcs commented 7 years ago

@andrewdavidwong Cool, I think we're on the same page then!

@marmarek I think light-locker seems really promising. Someone (well, multiple independent people!) would have to investigate how well it manages in crash situations.

I think that killing the dom0 session to lock the screen is a bit over the top - you don't want that to happen in the middle of a dom0 update, or when doing any sort of maintenance. I usually keep a dom0 terminal window around at all times, I would hate if that was killed every time the screen went idle. Also window placement, and everything else, would be totally fucked for users who use custom configurations for the window manager, or use their own window managers.

jpouellet commented 7 years ago

@cfcs If your only reason for wanting to retain a dom0 terminal is to ease disaster recovery in case of updates gone wrong (or other system-messed-up-ness), you can always just switch to a non-X VT (Ctrl+Alt+F2) and login there.

ideologysec commented 7 years ago

I'm sure this is buried in the issues or docs somewhere, but - at what point does Qubes envision transitioning to Wayland? (which would solve a heck of a lot of these "X11 lockscreens suck by design" problems.

Also, does physlock support YuibKey 2FA unlock? Wasn't able to dig up anything that said so (because while X11+YubiKey might be actually less secure than physlock, YubiKey+an actually secure screensaver would be dynamite).

ksoona commented 6 years ago

Can I at least set a screensaver instead of just the black screen? I can't install xscreensaver-extras or anything.

cfcs commented 6 years ago

@ksoona This thread is about making Qubes stop using an insecure screensaver, not about making the insecure screensaver prettier; you should probably file a new issue if that is what you want.

h01ger commented 6 years ago

FWIW, I just gave physlock a try and it worked great :) Is physlock available in fedora 25?

I also like its secure design, as opposed to other unsecure-by-design xscreenlockers... ;)

TBK commented 6 years ago

Apparently it is a hopeless cause on X11 - http://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/ the only way to solve it is to switch to Wayland (https://github.com/QubesOS/qubes-issues/issues/3366).

I experienced this scenario for the first time a couple of days ago: And yes that is the case: opening a context menu on any window prevents the screen locker from activating. - source: the link above

Luckily it happened at home and only gone for a short while.

Since then I have conducted several test on several machines and it is the same, context menu blocks the screensaver from activating.

cfcs commented 6 years ago

@TBK I posted that link last year: https://github.com/QubesOS/qubes-issues/issues/1917#issuecomment-274088587

if you would care to read 10% the comments in the thread before replying you would have noticed that there is another way, physlock.

TBK commented 6 years ago

@cfcs My bad, should not have posted in the middle of the night.

cfcs commented 6 years ago

@TBK No worries. You were completely right that it's hopeless on X11, and that this is a security flaw that is even documented in the FAQ of xscreensaver.

This three year old comment by @nvesely has a proposed fix to this security flaw in Qubes in case you want to secure your system (I don't think the Qubes upstream has made it clear by now that they don't consider screenlocking a security measure): https://github.com/QubesOS/qubes-issues/issues/963#issuecomment-107705261

TBK commented 6 years ago

@cfcs Thanks, I will look into that.

Qubes OS is not the easiest project to to get a clear image of the state of things.

psivesely commented 6 years ago

I haven't used qubes in a while, but the services in this repo were working as of 3 years ago.

dylangerdaly commented 6 years ago

I'm hitting errors using physlock (https://github.com/muennich/physlock/issues/44#issuecomment-297903096)

Issue looks to be related to PAM.

How are you guys using physlock? I want to stop relying on xscreensaver...

dylangerdaly commented 6 years ago

Rebuilding with SESSION=systemd and setting up the PAM module fixed it for me.

Aekez commented 6 years ago

It may not be feasible/desireable, but what are the prospects of using something like firejail on the various of different screensavers being considered, in order to minimize (make harder) bypassing with security exploits?

Firejail can sandbox any type of processes: servers, graphical applications, and even user login sessions.

Presumably, it could help increase the isolation layers within dom0 itself (or future stub-domain where lock-screen resides)?

cfcs commented 6 years ago

@Aekez Using firejail on xscreensaver and the other X-based screensavers actually increases the likelihood that they will crash, meaning that it increases the attack surface for someone looking to bypass your lock screen. For physlock I don't think it would make much of a difference, but wouldn't hurt.

EDIT: What they mean by user login sessions in the highlighted part of the quote above is that it can sandbox a "user session," ie you can attempt to separate multiple processes running under the same PID (in Linux that is pretty hard to do effectively; if you allow those sessions to access X you largely lose the benefit of the sandboxing).

Aekez commented 6 years ago

@cfcs ah, that's unfortunate if it can make it even worse. Thanks for sharing the insight though.

andrewdavidwong commented 4 years ago

Increasing priority to critical based on discussion in #2026.

na-- commented 4 years ago

I haven't tried physlock, but I was using light-locker until very recently, and I had to switch back to xscreensaver because of https://github.com/QubesOS/qubes-issues/issues/4943 :disappointed: The latest dom0 kernel that light-locker didn't have issues with 4.14.103 IIRC... :man_shrugging:

I only have the most surface-level knowledge of how these things work, and I have no idea about the root cause of my issues, so I'm not sure if physlock will have some of the same problems, :crossed_fingers: that it turns out to be a secure and problem-free locker :sweat_smile: I probably can't be very useful in actually implementing this, but I'm very eager to beta-test anything... :eyes:

martin-paulus commented 4 years ago

@andrewdavidwong @marmarek Did you consider https://tools.suckless.org/slock/ ? It was not mentioned in this issue, but I think it fits in with the Qubes OS goals: prioritize security and privacy, and avoid complexity where possible. I especially like that it doesn't feature a username or password field so nothing can be gained by shoulder surfing (unless it's your hands that are being observed). And it's already available in the dom0 package repos.

andrewdavidwong commented 4 years ago

@andrewdavidwong @marmarek Did you consider https://tools.suckless.org/slock/ ? It was not mentioned in this issue, but I think it fits in with the Qubes OS goals: prioritize security and privacy, and avoid complexity where possible. I especially like that it doesn't feature a username or password field so nothing can be gained by shoulder surfing (unless it's your hands that are being observed). And it's already available in the dom0 package repos.

I wasn't aware of it until now. I just read the page you linked, but it's very brief. Based on your description, it sounds like the lock screen would be just one solid color, and the user has to blindly type in their password to unlock. This sounds like it might not be the best UX for general users. CC: @ninavizz

rustybird commented 4 years ago

Also, slock is unfortunately still X11-based (unlike physlock), so it can't really solve the fundamental problems.

3hhh commented 4 years ago

+1 from me for physlock.

Reasons:

Cons:

Instructions for Qubes OS so that maybe some people test it: (Marek was fully right in 2016 to say that it requires quite some testing.)

sudo qubes-dom0-update gcc make pam-devel systemd-devel xss-lock verify tag signatures see physlock README in particular follow PAM instructions (or run into an endless "authentication failed" loop)

set physlock as screen locker after X minutes: via xfce4:

sudo su
passwd #root pw required to be set 
#make sure `/etc/xdg/autostart/xfce4-xss-lock.desktop` exists with `xss-lock xflock4` (does exist in Qubes OS 4)
xfconf-query -c xfce4-session -p /general/LockCommand -s "/usr/local/bin/physlock -ms" --create -t string

create a /etc/xdg/autostart/xset.desktop as found here (or set the timeout using another method):

[Desktop Entry]
Name=xset
Comment=Set screensaver timeout
Exec=bash -c 'sleep 60 && xset s 610'
Terminal=false
Type=Application
StartupNotify=false

If you need audio when locked: sudo usermod -a -G audio [your user]

An alternative which is likely better maintained, has a security focus, all the bells and whistles, is in newer Fedora repos, but suffers from the X problems nonetheless (at least they admit it): https://github.com/google/xsecurelock#security-design

Ah yes, and some may not like google. ^^

martin-paulus commented 4 years ago

andrewdavidwong : Based on your description, it sounds like the lock screen would be just one solid color, and the user has to blindly type in their password to unlock. This sounds like it might not be the best UX for general users.

It has three colors: initially black, then blue while typing, and red to show you just failed authentication. Considering a general user for Qubes OS using this kind of locker does not sound outlandish to me. But of course, you are entitled to your opinion.

3hhh takes care of other open logins (VTs) & SysRqs

In light of Andrew's comment about user-friendliness, and considering the efforts the Qubes OS project has put in creating a GUI which draws attention to qubes domain boundaries, why do we bother with virtual consoles at all?

Consider disabling virtual consoles, so that only the Qubes OS GUI is available:

dom0: /etc/systemd/logind.conf

[Login]
- #NAutoVTs=6
- #ReserveVT=6
+ NAutoVTs=0
+ ReserveVT=0

This will limit the requirements of any (replacement) screenlocker to securing the GUI only.

3hhh commented 4 years ago

Instructions for Qubes OS so that maybe some people test it: (Marek was fully right in 2016 to say that it requires quite some testing.)

sudo qubes-dom0-update gcc make pam-devel systemd-devel xss-lock verify tag signatures see physlock README in particular follow PAM instructions (or run into an endless "authentication failed" loop)

set physlock as screen locker after X minutes: via xfce4:

sudo su
passwd #root pw required to be set 
#make sure `/etc/xdg/autostart/xfce4-xss-lock.desktop` exists with `xss-lock xflock4` (does exist in Qubes OS 4)
xfconf-query -c xfce4-session -p /general/LockCommand -s "/usr/local/bin/physlock -ms" --create -t string

create a /etc/xdg/autostart/xset.desktop as found here (or set the timeout using another method):

[Desktop Entry]
Name=xset
Comment=Set screensaver timeout
Exec=bash -c 'sleep 60 && xset s 610'
Terminal=false
Type=Application
StartupNotify=false

If you need audio when locked: sudo usermod -a -G audio [your user]

After a while of testing I'd now recommend to use a script instead of using physlock directly:

#!/bin/bash

function isRunning {
pgrep -a '^physlock$'
}

#parse args
keep_open=1
if [[ "$1" == "--keep-open" ]] ; then
    keep_open=0
    shift
fi

#NOTE: for some reason the full path is required below for xss-lock
isRunning || { /usr/local/bin/physlock -dms "$@" ; sleep 1 ; }

#Idea:
#make xss-lock think that it controls the screenlocker, but in fact it doesn't
#reason: xss-lock may crash and we don't want it to take down the screen lock
if [ $keep_open -eq 0 ] ; then
    stime=10
    while isRunning ; do
        echo "Sleeping for ${stime}s..."
        sleep $stime
    done
fi
exit 0

I.e. use that for xfconf-query (with --keep-open there) and hotkeys etc. (without the argument there)

I guess some official doc on how to deploy an alternative screen locker would be nice in total - regardless of which one becomes the next default.

DemiMarie commented 3 years ago

Given that #3898 is a duplicate of this one, should this be backported to R4.0 as well?

dylangerdaly commented 3 years ago

When trying to use physlock a few months ago, I got x11 artifact, I'll give this another shot and see if it's working better now

ninavizz commented 3 years ago

The most important thing with a screenlocker wrt usability, is that it not make an impression with the user that it's malware. In the context of Qubes, this is especially important—doubly so, if there's a desire to get non-techy users to adopt Qubes. One of my first impressions of Qubes, was that the xscreen lock looks like malware. I even approached it's developer dude about changing that, but he finds that aesthetic to be charming so told me to eff-off (literally—yep, Jamie Zawinski is That Guy).

Second, is that there be an option for users to see their password as they type it. The current screenlocker also fails in this capacity.

I'm not a developer so can't give things a test run on a dev box. I'd love to see screenshots of what is being proposed for 4.1, and am STOKED this might go in! Yes, it is a big priority to me, and has also been flagged by others at FPF as being desirable.

3hhh commented 3 years ago

The most important thing with a screenlocker wrt usability, is that it not make an impression with the user that it's malware. In the context of Qubes, this is especially important—doubly so, if there's a desire to get non-techy users to adopt Qubes. One of my first impressions of Qubes, was that the xscreen lock looks like malware. I even approached it's developer dude about changing that, but he finds that aesthetic to be charming so told me to eff-off (literally—yep, Jamie Zawinski is That Guy).

If malware had a particular look, the job of AV vendors would be terribly easy.

Second, is that there be an option for users to see their password as they type it. The current screenlocker also fails in this capacity.

Security-wise that's an anti-feature as it opens up simple shoulder-surfing attacks.

I'm not a developer so can't give things a test run on a dev box. I'd love to see screenshots of what is being proposed for 4.1, and am STOKED this might go in! Yes, it is a big priority to me, and has also been flagged by others at FPF as being desirable.

I think you want something more visually appealing. physlock won't do that - it looks like a Ctrl-Alt-F1 tty logon.

Anyway if you want something visually appealing you'll need the X server for lovely graphics etc. As described above that's insecure. So currently there's these options:

X server screensavers: less secure, possibly more visual appeal non-X screensavers: possibly more secure, likely less appealing

xscreensaver belongs to the first category with low security properties, but ironically it isn't visually appealing either; physlock belongs to the second category.

DemiMarie commented 3 years ago

Another idea I had is for the screenlocker to be the display manager itself, and to use PRCTL_SET_DEATHSIG so that if the screenlocker crashes for any reason, X dies with SIGKILL.

3hhh commented 3 years ago

Another idea I had is for the screenlocker to be the display manager itself, and to use PRCTL_SET_DEATHSIG so that if the screenlocker crashes for any reason, X dies with SIGKILL.

So a non-X-screensaver. ;-)

But yes, it's an option. X server restarts aren't too good for user experience neither though. I'm not sure whether physlock causes less X restarts though (mine dies every now and then and especially after physlock, but it may be related to awesome).

Essentially there doesn't seem to be a perfect solution which ticks all boxes wrt security, usability and visual appeal.

DemiMarie commented 3 years ago

Actually, there is: we can switch to Wayland. That brings all sorts of improvements, but is also a lot of work.

jpouellet commented 3 years ago

On Mon, Nov 30, 2020 at 1:51 PM Nina Eleanor Alter notifications@github.com wrote:

The most important thing with a screenlocker wrt usability, is that it not make an impression with the user that it's malware. In the context of Qubes, this is important. One of my first impressions of Qubes, was that the xscreen lock looks like malware. I even approached it's developer dude about changing that, but he finds that aesthetic to be charming so told me to eff-off (literally—yep, Jamie Zawinski is That Guy).

On the contrary, I suspect that many Qubes users believe the most important thing with a screenlocker, is that it actually, you know, lock your screen, and do so in the most safe, reliable, and least-likely-to-be-bypassed manner. After all, these properties are directly security relevant, whereas appearance of the locker is only indirectly so, if at all.

In the author's defense, "That Guy" happens to have laid out specific technical security arguments (16 years ago!) against the risk which would be posed by making xscreensaver "prettier" in the usually-proposed manners, which can be found at https://www.jwz.org/xscreensaver/toolkits.html

And as it turns out, history happens to have shown the author's stance on this particular matter to have been prudent and correct.

I'd be willing to guess that the tone of the author's response is nothing personal, but comes from frustration with responding to the same question/suggestion over and over again since initially writing xscreensaver 28 years ago (!), and having written a detailed explanation of why they aren't interested in adopting the proposed suggestion 16 years ago. Anyone gets tired of repeating themselves eventually.

Now, this isn't to say that we can't have nice things (we certainly can!) and also not to say that xscreensaver should be considered the last word in screen locking either (one need only note the numerous observations of notifications leaking through, or failure-to-lock situations when another program holds XGrab{Pointer,Keyboard,...} to realize that).

There are various alternative approaches which may be considered, each with their own trade-offs. These include (among other things):

  1. Using a VT-switching+lockdown approach such as physlock.
  2. Using something like https://github.com/google/xsecurelock
  3. "locking the screen" in the most-unfriendly yet most-reliable manner that Qubes is uniquely positioned to leverage: by killing the X session entirely and "unlocking the screen" by logging in again and restarting the gui daemons (which restore windows, positions, titles, etc. from the still-running gui agents in the running guests).
  4. The various options available in wayland, which is fundamentally better positioned to safely solve screen locking than any X11-based screen locker is (due to architectural deficiencies in the X11 protocol, modulo extensions which never took off). This would of course require quite a bit of prerequisite work.

Xscreensaver is what it is, and it is understandable for the author/maintainer to refuse suggestions which they deem inappropriate, or simply do not like. If we don't like the result, we are free to pick another alternative (see above for suggestions) or fork it (hint, we already have 1, though substantially changing xscreensaver in particular is inadvisable -- see above-linked argument for why).

I don't mean to discourage any efforts at usability. I do support and appreciate them! I just want to raise awareness that in this case it can be at odds with security for real yet perhaps non-obvious reasons.

IMO, questions such as "How hard is the lock screen to bypass?" should be given primary consideration, including architectural / design considerations of theoretical bypasses which postulate the existence of bugs which are not presently known and cannot easily be demonstrated, but can be reasonably anticipated, for example in the arguments laid out by "That Guy" 16 years ago.

Confidence in the absence of edge-cases resulting in failure to guarantee a locked screen is, I would argue, more important than how it looks when allegedly locked.

Hopefully this won't be interpreted the wrong way. I really do bear no ill will, I just appreciate the author's work, as well as appreciate efforts to improve Qubes usability, and am sad to see them at odds. I hope this additional background helps.

DemiMarie commented 3 years ago

So one idea I had is:

The main advantage of this approach is that the only way it can fail is through a kernel vulnerability. PTRACE_O_EXITKILL is intended for ptrace-based sandboxing programs, meaning that if it doesn’t work as documented, that’s a security hole in the kernel.