On Tuesday, February 20, 2018 at 2:49:30 PM UTC+7, Yuraeitha wrote: > On Monday, February 19, 2018 at 3:37:39 PM UTC+1, msg...@gmail.com wrote: > > 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. > > @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.
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. -- 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 https://groups.google.com/d/msgid/qubes-users/960034e2-1751-4647-96a8-8823fe049e17%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
