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
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
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.