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.
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.
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
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
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
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.
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
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
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.