A proposed habit-friendly feature to increase security and user friendliness

[aperi....@gmail.com]

Hello,

Hopefully I did not overlook it if this has been proposed already. This is a suggestion to hypothetically help making Qubes more secure and increasing user-friendliness by making good use of users over decade long hard embodied habits. Furthermore additionally reducing the amount of mouse clicking overhead.

The idea is to allow for a way to tie together shutdown of a specific app with the shutdown of the entire AppVM it is located in.
Potential uses may be for users who wish to allocate an AppVM for a single app, which may help in numerous of different or multiple reasons, such as:

• It reduces the attack surface inside the VM by naturally helping the VM run in less overall time. As Qubes remains mostly protected, but the contents of the VM itself remains vulnerable while actively running, just like any other Linux operating system.
• More frequent natural habit induced reloads of the VM would lead to an automatic reload of the "read-only" system operation files, making better use of Qubes strength to clean system files from any attacks.
  
• It helps freeing up computer resources, such as RAM, especially on laptops, cheap or old computers, so forth.
• Aesthetically it helps making the Qubes VM Manager look more clean, sleek, less bloated, when non-active VM's are not running.
• Probably some use-cases I didn't manage to think of.

1. It makes it easier to stay secure for those who already remembers to shutdown an AppVM after use (less clicking / management to do).
2. It improves the security and/or system-resources for those who knows but forget to shutdown an AppVM after use.
3. It also has an additional potential for making Qubes more secure out of the box for non-technical users through default settings for common apps, such as browsers.

A hypothetical weakness could be? - if malware or hacker interrupts the shutdown command inside the AppVM in the system files in order to preserve the attack system files. However that too would warn a user that something is amiss and serves as a common sense warning sign among technical users once discovered unusual activity is discovered. If I'm not wrong to assume this, that many attacks partly rely on remaining stealthy in order to perform their task, such as key-logging, surveillance, so forth. The act of hindering an AppVM to shutdown would send red-flags and undo the stealth cover.

A potential location for this opt-in feature could be in the settings menu when creating an AppVM or when editing existing AppVM's.

I'm not aware if it is possible though, but it should be theoretically simple to implement?
For example, if possible, code in the Qubes VM Manager to insert/inject a terminal shutdown command code into the Interface Window Manager inside the AppVM's system files, which is activated every time a user is clicking the upper right corner window "x" button of the specific user-chosen AppVM app.
Also can such a system be made for specific apps that resides inside the AppVM, or will it end up affecting the AppVM whenever a random app is shutdown in the AppVM?

Is it feasible or even desirable to do such a thing?

Cheers,
Aperi

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2017-01-30 14:53, aperi....@gmail.com wrote:
>
> Hello,
>
> Hopefully I did not overlook it if this has been proposed already.
> This is a suggestion to hypothetically help making Qubes more
> secure and increasing user-friendliness by making good use of users
> over decade long hard embodied habits. Furthermore additionally
> reducing the amount of mouse clicking overhead.
>
> The idea is to allow for a way to tie together shutdown of a
> specific app with the shutdown of the entire AppVM it is located
> in. Potential uses may be for users who wish to allocate an AppVM
> for a single app, which may help in numerous of different or
> multiple reasons, such as:
>

> - It reduces the attack surface inside the VM by naturally helping

> the VM run in less overall time. As Qubes remains mostly protected,
> but the contents of the VM itself remains vulnerable while actively

> running, just like any other Linux operating system. - More

> frequent natural habit induced reloads of the VM would lead to an
> automatic reload of the "read-only" system operation files, making
> better use of Qubes strength to clean system files from any

> attacks. - It helps freeing up computer resources, such as RAM,
> especially on laptops, cheap or old computers, so forth. -

> Aesthetically it helps making the Qubes VM Manager look more clean,

> sleek, less bloated, when non-active VM's are not running. -

> Probably some use-cases I didn't manage to think of.
>
>

> 1. It makes it easier to stay secure for those who already

> remembers to shutdown an AppVM after use (less clicking /

> management to do). 2. It improves the security and/or

> system-resources for those who knows but forget to shutdown an

> AppVM after use. 3. It also has an additional potential for making

This is pretty similar to this issue:

https://github.com/QubesOS/qubes-issues/issues/832

As you can see, there's been a long discussion about this issue, which
you might find interesting.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYkCEHAAoJENtN07w5UDAwaLMQALVtcMH+iT8aqp2Ee5WTTc+C
/RciKHP2+y2EqgjgKt+htkMnWeZxwN1ZY7SYbFt1WX91Ccvm4kiOygSaCtfc1W+d
K6UNKZ9EtHGR5lbYhVq7fHOMlrXaje2SFmrzTt7x8i89IUknuJ4fDzX7TF/Mvyww
DfkJZvOani9kssJV7tSpFE5/jk+vZcks9UT4x/vaOZAMOh2ASmp6IrPtEOe1jr1j
ftsSQsoHEZA5bNh0qXVknoFHswse3cE04D1A8KjfSbytL8fXj8O/+w7bQsWeB5xi
VohPaoihn8pzoatpgdJFqlXrr+W8HHRkW5kIM/UuadNfuTT/9AEZ4sWbX7QywAOY
OSz0ybKkV/sAQoPi3NbdCRxWZvOHXVWLi6AZzwUHwS8ebcdR4UJSY+OoznuMkL70
EnCOmb28AC+NDMWnTt8AKjq1g6XZrFwkGUMmf0/KF1HJh36BVsA3nOGBGaWTCwTZ
fre4vXIaWXt4HFv1REP5aXeRx07Fwo/8eE5urysYgfUXElNu0gjs1xIJqXUFd+J0
ap9APqca0EDTZzfQzs28iWuUbQ+C4vVvKaKZUcnI16ZP3EqGINjams8xX3yLtt9L
JYVwGIRhxGUAEyc6FZceQm4GqKXyEvBOBp63MkCO0ueZLml9QWfBDrbeaCB3WI8s
LYaLX5SKMTRzEQ38jgA/
=MCpZ
-----END PGP SIGNATURE-----

[john.david.r.smith]

add this service to your vm:
autoshutdown_no_windows.service
------
[Unit]
Description=shut down the system if no window was open for 30 sec
ConditionPathExists=/var/run/qubes-service/autoshutdown_no_windows
[Service]
Type=oneshot
ExecStart=/bin/bash -c 't=30;while [[ $t>0 ]]; do t=$(($t-1)); [[ "" != "$(DISPLAY=:0 xdotool search -name --onlyvisible .)" ]] && exit ; sleep 1s; done; [[ "" == "$(DISPLAY=:0 xdotool search -name --onlyvisible .)" ]] && sudo shutdown now;'
------

autoshutdown_no_windows.timer
------
[Unit]
Description=periodicly check for open windows
ConditionPathExists=/var/run/qubes-service/autoshutdown_no_windows
[Timer]
OnBootSec=120
OnUnitActive=30
------

your vm will need xdotool and the qubes service autoshutdown_no_windows.
if this service is not active, nothing will happen, so you can activate the timer in your template.

if no window is open for 30 seconds, the vm will shut down.


i have something similar for proxyvms (to shut down if no one is using them):

autoshutdown_no_incomming_vms.sevice
------
[Unit]
Description=shut down the system if no running vm usis this vm as netvm
ConditionPathExists=/var/run/qubes-service/autoshutdown_no_incomming_vms
[Service]
Type=oneshot
ExecStart=/usr/bin/qrexec-client-vm dom0 custom.RequestProxyVMShutdown
------

autoshutdown_no_incomming_vms.timer
------
[Unit]
Description=periodicly check for incomming vms using this vm as netvm
ConditionPathExists=/var/run/qubes-service/autoshutdown_no_incomming_vms
[Timer]
OnBootSec=120
OnUnitActive=30
------

and additionally i have a rpc and command in dom0:

custom.RequestProxyVMShutdown
------
qvm-shutdown-unused-proxyvm
------

qvm-shutdown-unused-proxyvm
------
#!/bin/bash
interactive=0
domu="$QREXEC_REMOTE_DOMAIN"
if [ -z "$domu" ] && [ ! -z "$1" ]
then
domu="$1"
else
interactive=1
while [ -z "$domu" ]
do
echo "interactive mode:"
echo "enter the proxyvm to check"
read domu
done
fi

#check if the given vm is a proxyvm

vmtype="`qvm-prefs $domu type`"
if [ "$vmtype" != "ProxyVM" ]
then
echo "the vm $domu is no proxyvm! (its type is: $vmtype)"
exit 1
fi

qvm_ls_output="`qvm-ls`"

if ! echo "$qvm_ls_output"| grep -q -E '^([^\|]*\|){2}[ ]*state[ ]*\|([^\|]*\|){3}[ ]*netvm[ ]*\|([^\|]*\|)*$'
then
echo "ERROR it seems the output format of qvm-ls changed (the 3rd and 7th collumn are not 'state' and 'netvm')"
echo "the collumns are:"
echo "$qvm_ls_output"|head -n 3
exit 2
fi

using_vms="$(echo "$qvm_ls_output"| grep -E "^([^\|]*\|){2}[ ]*Running[ ]*\|([^\|]*\|){3}[ ]*$domu[ ]*\|([^\|]*\|)*$")"

if [ -z "$using_vms" ]
then
qvm-shutdown $domu
else
echo "there are vms using $domu as proxyvm:"
echo "$qvm_ls_output"| head -n 3
echo "$using_vms"
fi
------

[Jean-Philippe Ouellet]

On Wed, Feb 1, 2017 at 2:27 PM, john.david.r.smith
<john.davi...@openmailbox.org> wrote:
> [some scripts to auto-shutdown]

Cross linking: https://github.com/QubesOS/qubes-issues/issues/832

[Chris Laprise]

On 01/30/2017 05:53 PM, aperi....@gmail.com wrote:
>
>
> The idea is to allow for a way to tie together shutdown of a specific
> app with the shutdown of the entire AppVM it is located in.

I'd see this also as a burden where the user has to remember which apps
trigger which VMs to exit. So I think this may be worse than the idea in
issue 832.

A better fit is to enable the user (who is already encouraged to be
aware of which VMs are running) to indicate via *any* window that the
associated VM is to be shutdown after closing the window. This could be
done via an extra windowframe widget, or adding a qualifier to existing
widgets, or a key combo like Shift-Ctrl-F4.

Chris