On Monday, February 19, 2018 at 1:00:13 PM UTC+1, msg...@gmail.com wrote:
> On Sunday, February 18, 2018 at 4:10:56 PM UTC+7, msg...@gmail.com wrote:
> > Hello,
> > 
> > Is it possible to start all VMs marked as "Start qube automatically on 
> > boot" on Qubes OS boot and not on user login in Qubes OS?
> > Is it possible to do it without Qubes OS autologin?
> > I want to have a working server application on VM on Qubes OS boot without 
> > the need to login in Qubes OS.
> I've enabled autologin and add "xscreensaver-command -lock" in the Startup 
> Applications as temporary solution, but it's not perfect because the system 
> is unlocked briefly before xscreensaver will be locked and it may be 
> exploited.

I'm no expert, but in order to bypass a Qubes login, isn't this just about 
changing the PID levels? If this is possible to do without major change in the 
code, of course. The various processes are ordered in levels, init the root of 
all levels being 1, and the lowest possible firmware at init 0. While root as 
an account is disabled by default in Qubes, there should be something akin to 
root, in a way of "system" processes. So the system processes starts up during 
boot, which includes all autostart VM's. Which you can see in "sudo journalctl 
--boot" and adjust it to around the time you booted it up, or a much simpler 
appoach which is to press the F1 key after LUKS password, which will show you 
what happens during boot, up until the Qubes login for user sessions. 

I believe the AppVM's must be partly starting up in the background, but all the 
user aspects from the user account, did not. For example XFCE4, widgets, 
notifications, etc. are not bound by system processes, but are bount by the 
user account processes. 

If you can change all the processes related to a Qube AppVM, and all the 
required processes, i.e. by changing them from user processes type, to a system 
process type, then it may very well fully boot before you type in your password.

However, you will have no LUKS password, since this cannot be automated even if 
you use other systems. Essentially, your plan seems like it will fall apart, no 
matter what you do with current technology, no matter which Linux or system you 
pick, they are all vulnurable to this issue. Or so it seems, after all, I'm no 

Essentially, you can probably work around the last Qubes login, but not the 
first disk encryption login. And even then, putting some of Qubes processes 
from user to system, may be risky too.

I'm sorry, but if you look at it from an abstract point of view, no matter how 
you flip this, it just seems outright impossible if preserving security is your 
goal. Or did I miss something crucial?

You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to