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.

-- 
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/c51654cc-3cea-42f4-a1ff-c043b95dd236%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to