On Monday, February 19, 2018 at 7:29:37 PM UTC+7, Yuraeitha wrote: > 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 expert. > > 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?
Thank you for the suggestion to check the boot process log, the AppVMs really are starting up before user login. It seems that when I've tested this, the testing AppVM failed to load and I couldn't connect to it. I've tried to connect to the ssh service in AppVM, but failed to connect and when I've logged in the Qubes OS I've seen the VMs just starting to boot from the look of it. The problem is solved. Regarding the encryption, I'm thinking of using hardware-based full disk encryption with the feature to remote unlocking the drive to keep the encryption keys away from the Qubes OS hardware. This will avoid the threats like meltdown/spectre/IntelME/AMD PSP stealing the encryption keys. -- 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 firstname.lastname@example.org. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/abaf104e-914a-4a7f-8d9a-a9284d2492c7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.