Start VMs on boot before user login (Qubes OS 4.0rc4)

[msg...@gmail.com]

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.

[msg...@gmail.com]

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.

[Yuraeitha]

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?

[msg...@gmail.com]

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.

[Tim W]

Make sure there is no way to softboot\power cycle the box as with sed opal2 hw encrypt drives they will stay unlocked until either manual locked or power loss state i.e. true power cycle. I run Samsu. 850pro But still run luks as a precaution to some tricks to softboot a locked powered on system.

[Qubed One]

msg...@gmail.com:

Your question made me curious so I ran a quick test on 4 RC4.

In dom0, run:

[user@dom0 ~]$ sudo systemctl enable qubes-vm@serverVM

(replace serverVM with the actual name of the VM running the server)

Restart the machine, then after entering your LUKS passphrase hit
escape, and you should see the serverVM being autostarted before login
the same way that sys-net, sys-usb, and sys-firewall do. This
successfully started a testVM for me before login.

[msg...@gmail.com]

On Tuesday, February 20, 2018 at 7:04:00 AM UTC+7, Tim W wrote:
> Make sure there is no way to softboot\power cycle the box as with sed opal2 hw encrypt drives they will stay unlocked until either manual locked or power loss state i.e. true power cycle. I run Samsu. 850pro But still run luks as a precaution to some tricks to softboot a locked powered on system.

I know about this problem, I want to use hardware-based encryption against unprepared/unskilled attackers, but if someone really want to get the keys, there'll allways be a way to do this when you have physical access to the hardware. For example, even if you use LUKS in addition to hardware encryption, the LUKS keys will be in the RAM and attacker can read them directly from RAM:
https://en.wikipedia.org/wiki/Cold_boot_attack

[Yuraeitha]

@msg...@gmail.com
oh interesting, I did not know it was possible to do remote hardware decryption, I made the mistake expecting it had to be physically at the server. This is one powerful ability that indeed changes everything. Looks like it might work after all then, I'm glad its starting to work out for you.

Apologize for the large post below, but I'd argue I have a solution for you regarding the RAM issue, but it's a different way of thinking, that's why it needs to be compiling different pieces of logics together. There are ways you can raise un-tapped potential for security here if you look for measures outside the computer itself.




First an established logic analogy that embodies everything below:
The whole logic below can be summarized as an analogy of the difference between ps/2 and USB. First establishing a logic here through an analogy between USB/ps/2. USB is universal, advanced, and powerful, it can do a lot of things, but it's not very secure, which is made worse by its own complexity. Ps/2 on the other hand is very simple, analogue, based on the simple mechanic of interrupting an otherwise constant signal to the CPU. Ps/2 is therefore really secure, compared to the weak and exploitable USB.

The issue:
Is essentially the same analogy here, the problem being the whole industry is caught in using the method comparable to the USB analogy above, and it easily misleads us to also use "USB" <-- analogy to security approaches of course.

Working out weak links:
So by flipping this on its head, instead of relying of a system that is trying the impossible with today's technology to be protected fully on its own, if you include yourself in that equation in comparison to the analogue analogy to ps/2 signals, it becomes a whole different picture. The whole industry tries to remove the human factor, but when you're just one person, including the human factor is a strength, not a weakness. I think this is one very important overlooked factor in security, and we're being mislead to think in the same way as the industry. The story is very different for an individual person, especially one who is logical, technical skilled, and careful, which it seems like to be a type of person that you are, which is good.

Also the industry systems are not build to shutdown unexpectedly, this would be cost a lot of money to do. But as an individual, it "might not" be much of an issue to have unplanned shutdowns.

As an individual, you don't have to rely on trust issues, or other people making mistakes. You can further reduce your own mistakes by following strict habits, after you made a through plan to reduce any complexity, to as simple security measures as possible. Not always being the case, but frequently less complexity, more security, right.




Now for the solution:
If putting up a full array of sensors, anything specious happens to your servers environment, even the smallest beep, can trigger you to not send a new remote hardware key signal, and have the server shutdown, or make the server automatically shutdown.

You can have cameras, movement sensors, raspberry pi laser detectors (cheap and easy to build yourself), entropy reading sensors, room temperature and water vapor sensors, you can essentially build any measure into your servers room, to measure anything that will not naturally change. If anything unnatural changes, you will know immediately. If power is cut off, you will know immediately. If internet is cut off, you will know immediately. If anything, whatsoever changes, you will know immediately.

These sensors can be made hack-proof from remote attacks too, by only using one-way signals. For example you can control your server with two-way signals, but if the detection system is uncontrollable remotely, meaning, it can only send signals out, and never receive signals, therefore it can not be manipulated, and thereby is impossible to hack remotely. This results that it has to be physically attacked in the local environment, essentially creating a protected sphere around your server where an attacker has to get physically through, in order to reach your server.

It sounds very Mission Impossible sci-fi like, however, nonetheless is very effective. And you can build much of this yourself of cheap parts if you're creative, raspberry pi is an excellent resource here.

Have your server shutdown by any unnatural changes in the environment, whatever it is, measure anything humanly possible that is within your means, that does not change naturally. If the server is down, it won't matter, they can't record your RAM to steal your keys. All they got is two fully encrypted disks, and some painful brute-forcing ahead, which may very well end up being impossible if disk encryption is done properly, with secure encryption code and near perfect entropy (important).

To beat a hacker, you have to think like one. I believe the same goes for server protection, include the human factor (yourself), and they will not be able to attack your system, at least not without some really cutting edge rare and probably expensive attack vectors. At some point, it may even become impossible to get through something like this, at least with conventional classical physics, but it's not like we're expecting what could be considered alien-like sophistication level technology to attack a server, right? I mean, moving through walls without being detected by a full array of different kinds of sensors? If anyone is worried about that, then come on.. I know any system has weaknesses and anything can be hacked, but this is pushing it :')

I think simple and cheap systems like these, but nonetheless effective, are not popular because the industry wants to rely on systems raises profit, as well as the security argument for systems that does not include the human factor, thereby requiring trust in a human (humans who can't be trusted or make mistakes all the time). And there is also the whole political factor to take into account too. Consider the industry don't make these systems for themselves, they are making them for others, and they have a whole range of reasons to remove the human factor. Also taking a second look at the economic factor which matters hugely as most large companies are driven forward by investors who work for maximizing profit. If anything is not selling well, it probably won't be made. A system like this probably returns much less profit, for one, the parts are cheap and doesn't require sophisticated complex systems that can be sold over and over again. It's better for profits to sell insecure sophisticated systems, but in all irony, it's also what makes systems less secure. For these reasons, we cannot blindly trust the security industry. We can't say "the smartest people have put their minds to this", because it's so full of conflicting interests, and the belief only complex systems can solve security is leading us astray, so much, that even the smart people with good values, don't stop and consider the simple solutions.

We are growing too reliant on the security industry, rather, by applying something like this, for a single person, trust in yourself is more than sufficient, especially if you make it a habit to never take risks by exposing your security, i.e. the moment you see the smallest change in your remote server, never, EVER, send the encryption key. At that moment, expect it to be compromised.

If someone blocks communication, even for a small brief second or less, expect it to compromised. Have multiple of ISP's and connections, so that it cannot just be your provider or something natural causing it. If you loose connection to your sensors, even for a moment, expect a compromise. Keeping in mind, they can only be attacked physically, so if you build a sphere around your server, then they cannot breach it without detection, and they cannot break the one-way sensor signal you without rising your suspicion.

I think it's true humans generally can't be trusted (at least not very easily, and probably never fully), and that humans will always make mistakes. But for one, you can trust your own agenda, you're not an organization, you're a single person left with only your own interests and yours alone. Second, while mistakes can happen even to the most careful person, if you minimize the complexity, make good and very strong habits which you never stray away from, then the odds you make a mistake is rather low in a straight forward simple system, where you never take risks or careless actions on sending your remote hardware signals.

The weakness of this system is if something has been overlooked, some ways to reach your server's physical location without detection, or somehow trick you into sending your security hardware key. But you're definitely thinking logically and critically, you should be able to pull this off, you have the needed resources. The only mistake done here is not trusting oneself enough, and trusting too much on the industry which is compromised by the economic, and also political factors. Sometimes too, we drawn in the complex systems and we end up overlooking the simple solutions right in front of us. This could be considered a human curse, the smarter one becomes, the less likely it is to be able to identify simple solutions. We forget to take a step back, and look at things from an abstract view.

To get started on this, you could fetch some cheap raspberry pi computers, sensors and detectors, maybe someone already made computer code you can use too, preferably some trusted and open code right. Then expand your sensory system, find weaknesses in it, keep strengthening it.

I mean, it's not like any of this is terribly advanced, but we are working with so much advanced technology, that we're forgetting to think simple. Simple methods can be quite effective if pulled together very carefully, trusting ones own logic and plan ahead.

Sure, there is probably a way to find a weak link in all this with sufficient advanced effort, but whoa, it would essentially be like a mission impossible movie. Good luck to that attacker, you'd have to be a really high value target to put in such effort.




Conclusion/Afterthought:
Be the old-school independent ps/2, not the exploitable dependable USB. If you look into organizational theory and culture, you'll find research on institutionalization (which are everywhere in our society, literally), which embodies beliefs, views and values, even such as those believing to be objectively true. There is a lot of institutionalization in organizations that is wrong, simply by the fact it can be attacked logically. But then, there is also those that attack logic, but lets not get philosophical on this, it only leads to circular conflicts and ultimately madness if not stopping one self.

The security industry is not an exception to major flaws in their institutionalization, if anything it's probably even worse due to the complexity, as well as the economic (profit) and political interest (backdoors) in it. I think it's healthy if we challenge the institutionalization of IT security. Sometimes even simple approaches can be effective, but there are other forces that keep simple and good solutions at bay, for multiple of reasons.

Perhaps I overlooked something crucial, but I'm sure someone will point out the flaw then. In fact, I'm relying on that, if anyone finds a flaw, then please criticize it openly. Mistakes are the best teachers, and I'm not that arrogant to claim I know better than the smartest people in the security industry, I most certainly don't. I simply look to criticize the industry in where it's not looking, and our own habits, which is a weakness occurring everywhere in society, and the security industry is not immune to that. I'm well self-aware that I too am subject to mistakes, and perhaps I'm looking at this the wrong way. But for now, it just looks like security industry is almost entirely overlooking the individual person when designing security, and is almost entirely focused on systems meant and designed for complex organizations. So too, is it designed with an economic and political agenda, maximizing security is not the top agenda, it's profit & political, security often becomes a lower priority in security designs.

Taking a step back, I'm not criticizing the technology itself, but the use and focus being put on technology in the industry, which is looking to be misplaced. I hope I did not waste your time, I hope it can be of use to secure your server even further.

[msg...@gmail.com]

Thank you for your post. Actually, I've already thinked about this as well and wanted to implement basic unauthorised access control + audio/video/sensors data streaming + recording with reserve power supply and internet connection. I've talked about _unprepared_ attackers before because of it.
The question is the extent of unauthorised access sensing to be implemented, because too much sensing will cause the frequent system reboots and a need to transmit the encryption keys to boot the system which will lead to the possibilitiy of attacker to target you phisically to get the keys when you decrypted them and want to transfer them. Too high sensing threshold may be exploited somehow.
But that's all the Mission Imposible like events.
The true problem lies in yourself. If attacker can get close to you physically and know that you've protected the system from unauthorised access then all the sensors will be for nought, because it'll be more easy to target you. And not only about threating you with thermorectal cryptanalysis/harming your folks/etc or using some medical means to make you spill the passwords/etc. It's just simple hidden camera/hardware logger/etc installed in your PC/bag/somewhere in the room when you away or asleep. That is if you don't live in the bunker and never get outside.

[Yuraeitha]

That's a good point, in the end, it can't be fully secure if there is any existing ways to gain access, and since there have to be if it has to be useful.. exploiting the human weaknesses, uhue.. yeah..

Somehow the story-line in 'The Hobbit' just came to mind though, with the Durin's secret passage into the Lonely Mountain, the great lost city of the dwarf kingdom for a period of time in the Middle Earth history.

The key required, can only be used once a year, at a specific time, otherwise it's impossible to get through. The clue is also tricky, because it's one of those situations it tricks the intelligent people with "the last light of the day", but in the end, it was the moonlight before midnight, thereby misleading people as as last secure measure to the door.

I find it interesting, it might be feasible to do something like this too in computers, although not once a year, but instead make other rules, rules which does not allow a mistake, not even once. For example, if they don't know the conditions, and they mess up, then they're essentially giving themselves away. You don't have to tell them the conditions like the map in the story either, although, they can instead gather clues from your behavior. I suppose it's down to who's able to out-trick the other before one gets tricked first. But the interesting part about this, is that there is only once chance to get it right. Screw it up even just once, and it's done, the attacker is exposed.

For example if you make it dynamic, giving it a pattern, which you memorize in your mind? If anyone tries to probe your server for the pattern, then you can make it so it makes you aware of it. For example by stopping sending a signal, instead of trying to send a signal (which can be blocked by an attacker). Since an attacker can't prevent it from stopping sending a signal, it'll be like an unblock-able warning sign.

Another aspect, what about face recognition technology? It's becoming more and more available these days, and it doesn't have to look for faces, it can also look for human shapes and bodies, or anything that changes but automatically removes natural movements (it can be trained to not see false positives).

This is all good and all, but I don't know if these are available to regular people yet. I know a face recognition code is floating on the internet after it was leaked some months/year ago, but it might require some programming skills to adjust it? Could it be feasible to do this in practice without a lot of resources?

I suppose the pattern you access your server can be observed too and estimated and cracked if observing you long enough, but if they get it wrong, just once, is enough to warn you though. Somehow implement a secret trick, which can't be easily observed, which function like a trip-wire and warns you?

I'm really not sure, what software is available here? is it feasible right now to do these things without programming it all yourself? and then there is the question about making a pattern or trip-wire that will out-smart most attackers, that one can be hard to solve on a level that makes it hard to detect. You will probably have to dig into psychology too for this.

It does seem like it could be a fun project though, flipping it around, instead turning it into a mind-game of who out-smarts who. Further, you have the advantage, since you pick the playing field and the rules. Instead of thinking of it like a security system, perhaps thinking of it like a deadly game, where loosing, even once, is fatal, both for the attacker, and for you if the attack gets through, but no matter what, there is only one chance for the both of you. It's just, you can make a really unfair playing field to the attacker. But how to make a game, that can't be figured out by observing you, though? You'd need some kind of smoke-screen to cover up how you pass through it. Not really sure how to go about that one, not yet at least.

[Yuraeitha]

On Tuesday, February 20, 2018 at 10:51:55 AM UTC+1, msg...@gmail.com wrote:

I suppose it comes down to not making enemies that would attack you physically to get to your server, and outsmarting the other? So there are 3 perspectives here? Assuming the sensors and detection system can't be bypassed with the hack-proof's applied to it.

1) Physically attacked? Game over. Unless you know jiu jitsu.. err.. I suppose the best is to avoid situations where you are worth all this trouble to get to you?

2) Mind Games, a system who outsmarts the other, there is only one chance to succeed or fail. You have the advantage, you pick the field and rules.

3) The downside is how to cover up how you play the game to access your server, so that no one can repeat your footsteps through the minefield of explosives.



The first one is tricky, but if you don't have resourceful enemies, then it's probably unlikely to happen. The second one point is possible, especiailly given the strong advantage you have. The third, how to hide your game, seems to be a big problem too, like the first one.

So avoid resourceful lawless enemies whom are motivated to get on your server? Build a strong game, that is fatal to fail for the attacker. But then, how to cover up how the game is played to access it?

Perhaps, it's not so much about hiding the answer to the rules in the game. But more of a question to hide some fatal rules among the visible rules? If a rule cannot be observed, then you can easier trick people. But it does take a fair shot at psychology too.

[msg...@gmail.com]

There is actually a way to exclude a threat of attacker finding out how to unlock the server by any other mean then physical threats - use onetime passwords to unlock the server and keep them in your brain.
Here is an example:
Keep the system drive encryption key in the LUKS container on the hardware encryption device HDD with 8 passwords in LUKS slots (maybe use 8 simple passwords + some simple cryptographic algorithm that can be done in the head).
Remember these 8 passwords in your brain.
When you want to unlock the system, you remotely connect to the hardware encryption device and unlock the LUKS container with one of the passwords and then remove this password from LUKS slot. Then you can unlock the system drive and start the system. Then you lock the LUKS container in the hardware encryption device.
When you run out of passwords and one or two passwords will be left you need to go to the server and enter new passwords in the empty LUKS slot offline in the hardware encryption device.
This way, if you can be sure that the server room is not compromised, nobody can unlock the system without you even if they install the keylogger to your PC or hidden camera around you or even stand next to you and watch when you unlock the system.