[qubes-users] Re: Start VMs on boot before user login (Qubes OS 4.0rc4)

[Yuraeitha]

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 
secur

[qubes-users] Re: Start VMs on boot before user login (Qubes OS 4.0rc4)

[msgheap]

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

-- 
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/d8f87378-2530-4cd1-93ed-db735ad9dd00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] cannot build ubuntu template

[Tim W]

Yes I agree it would be best ifnthe unsupported templates were commented out 
with a notation in the doc of it incase some reason it needs to be built.   Its 
frustrating when you see 15 + template choices in the s ript but really only 6 
actually work.   The config may aslo ideally be adjusted so template choices 
are different for 3.2 and 4.0 to reflect the currently supported ones.   
Currently I have found that as part of an iso build none of the none standard 
templates will build correctly.   I can only make a qubes iso using fedora and 
debain whonix templates.  Archlinux. Ubuntu, Centos all error out.  On 4.0 even 
fc23 errors out.  Normally not a big deal but its nice to be able to build a 
kernel for 3.2 if you have dupli ate laptops.  I like ha ing active templates 
for current dom0 fc versions regardless it being in 4.0 or 3.2.

-- 
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/6ac39a1c-84b2-4264-808d-38546c6d4ad0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Start VMs on boot before user login (Qubes OS 4.0rc4)

[Qubed One]

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


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.

-- 
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/2d278cde-e9d5-cf8a-c84e-77e87f22fcfe%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Installing Win7 on a Dell

[Qubed One]

Glen H:
> On Monday, February 19, 2018 at 1:05:09 AM UTC-5, Yuraeitha wrote:
>> On Monday, February 19, 2018 at 6:08:44 AM UTC+1, Glen H wrote:
>>> On Sunday, February 18, 2018 at 9:59:24 AM UTC-5, Daniel Moerner wrote:
 On Saturday, February 17, 2018 at 9:06:03 PM UTC-5, Glen H wrote:
> Hi,
>
> I'm a new user and am trying to get Win7 Pro x64 installed in Qubes 4rc4. 
>  I have a Dell e7440 and it doesn't come with a Windows .iso.  Before I 
> installed Qubes I used the Dell recovery tool to create a recovery usb 
> disk for Win7 to re-install the OS but I'm not sure if this is usable to 
> install with Qubes.
>
> I tried following the instructions on the Qubes website by creating a new 
> Qube without a template but I could not change it from PVM to HVM.  Then 
> when I tried booting from the USB recovery disk it would load up a 
> terminal and then exit after 10 seconds.
>
> When I try to boot the recovery USB disk from the main BIOS it boots up 
> fine.  Does anyone have any tips for installing Win7 in Qubes 4?
>
> Thanks,
>
> Glen

 Hi,

 Check out these two issues:
 Installing Windows 7: https://github.com/QubesOS/qubes-issues/issues/3592
 Installing Qubes Windows Tools: 
 https://github.com/QubesOS/qubes-issues/issues/3585

 The two problems you describe in the post seem to be the following:
 1. Use qvm-prefs to set the virt_mode to hvm; the GUI doesn't work.
 2. Make sure you set the video-model to cirrus for install.

 Best,
 Daniel
>>>
>>> Hi,
>>>
>>> Thanks for the tips Daniel.  I'm stuck at not being able to boot from the 
>>> usb disk.  I am doing:
>>>
>>> ```
>>> qvm-create --class StandaloneVM --label red win7new
>>> qvm-prefs win7new virt_mode hvm
>>> qvm-prefs win7new memory 4000
>>> qvm-prefs win7new maxmem 4000
>>> qvm-prefs win7new kernel ''
>>> qvm-volume extend win7new:root 25g
>>> qvm-prefs win7new debug True
>>> qvm-features win7new video-model cirrus
>>>
>>> # Then attach usb drive to untrusted, but all of these fail to boot:
>>>
>>> qvm-start --hddisk untrusted:sda win7new
>>> qvm-start --hddisk untrusted:sda1 win7new
>>> qvm-start --hddisk untrusted:/dev/sda win7new
>>> qvm-start --hddisk untrusted:/dev/sda1 win7new
>>> ```
>>>
>>> I'm not sure whether to use the whole drive (no name) or the first 
>>> partition (named DELLRESTORE)...but I tried both.
>>>
>>> I get the error message in the win7new terminal:
>>>
>>> ```
>>> SeaBIOS (version ...)
>>> Machine UUID ...
>>> Booting from Hard Disk...
>>> Boot failed: not a bootable disk
>>>
>>> Booting from Floppy...
>>> Boot failed: could not read the boot disk
>>>
>>> No bootable device.
>>> ```
>>>
>>> So it seems that it doesn't recognize the USB drive as bootable even though 
>>> I can boot it from the main BIOS (in legacy mode).  
>>>
>>> Any help would be appreciated.
>>>
>>> Glen
>>
>> First, welcome to the Qubes community! :)
>>
>> A few things first, starting to use Qubes can be a bit overwhelming, but 
>> you'll get the hang of it over time if you keep using it. For starters, look 
>> here in the command you use "untrusted:sda" which is something Qubes 
>> exclusive and you therefore had no chance knowing this. Untrusted, is a word 
>> that needs replacing for whichever untrusted AppVM you're using to hold your 
>> USB or SATA controllers. It's called untrusted because dom0 is trusted, and 
>> you need to use an less untrusted domain that doesn't compromise your more 
>> trusted domain, dom0. This is a bit tricky for new users to catch on, on, as 
>> it's ambiguity for new users, at best. To solve this, then you first need to 
>> figure out where your controller is located. If you have no sys-usb or 
>> similar, then it's likely still in dom0. It's insecure to keep this in the 
>> secure dom0 domain, but mostly you should be fine for some time yet if 
>> you're not a high target profile, and never leave your computer unattended 
>> in public or near people you don't trust with your life. Still, having it in 
>> dom0 is still more secure than not using Qubes. Just keep in mind you 
>> eventually want to migrate away from using dom0 for anything, but it's not 
>> always easy just yet due to some fixes and hardwares require you still 
>> manually manage dom0 from time to time, so it's not yet entirely a users 
>> responsibility, as there are still times when you need to use dom0.
>>
>> So if your USB or SATA controllers are in dom0 (Your SATA controllers will 
>> be if you did not move them yourself, and USB controllers depend on your 
>> hardware, the installer might or might not have done it automatically). If 
>> you don't have a sys-usb VM, then it's probably still in dom0. 
>>
>> I don't know your current knowledge on Linux, so I'll take the liberty to 
>> add more details just in case.
>>
>> In conclusion from the above, instead of untrusted, it should look like this 
>> dom0:sda for dom0

[qubes-users] QSB #38: Qrexec policy bypass and possible information leak

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) #38:
Qrexec policy bypass and possible information leak.
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).

View QSB #38 in the qubes-secpack:



Learn about the qubes-secpack, including how to obtain, verify, and read it:



View all past QSBs:



```

 ---===[ Qubes Security Bulletin #38 ]===---

  February 20, 2018


  Qrexec policy bypass and possible information leak

Summary


One of our developers, Wojtek Porczyk, discovered a vulnerability in the way
qube names are handled, which can result in qrexec policies being bypassed, a
theoretical information leak, and possibly other vulnerabilities. The '$'
character, when part of a qrexec RPC name and/or destination
specification (like '$adminvm', '$default', or one of the variants of
'$dispvm') is expanded according to shell parameter expansion [1]
after evaluating the qrexec policy but before invoking the RPC handler
executable. 

Impact
===

1. Potential policy bypass. The qrexec argument value that is delivered to the
   handler executable can be different from the value that is present in the
   RPC policy at the time the policy is evaluated. This is especially
   problematic when the policy is defined as a blacklist of arguments rather
   than a whitelist, e.g.  "permit any arguments to example.Call but
   PROHIBITED". If an attacker were to call 'example.Call+PROHIBITED$invalid',
   the argument would not match the blacklisted variable at the time of policy
   evaluation, so it would be admitted.  However, performing shell parameter
   expansion on the argument results in the prohibited value, which is what the
   actual handler receives.

2. Potential information leak. If the qrexec handler acts upon the argument,
   the attacker could read or deduce the contents of those variables.

3. Other potential vulnerabilities. Some of the variables present in the
   environment, like $HOME and $PATH, also contain characters that are not
   permissible in qrexec names or arguments that could theoretically lead to
   other classes of vulnerabilities, such as directory traversal.

Technical details
==

The '$' character is used in several places in qrexec and is therefore an
allowed character in parameters to Qubes RPC calls. It is also allowed as part
of the RPC name. The validation code is as follows [2]:

static void sanitize_name(char * untrusted_s_signed, char 
*extra_allowed_chars)
{
unsigned char * untrusted_s;
for (untrusted_s=(unsigned char*)untrusted_s_signed; *untrusted_s; 
untrusted_s++) {
if (*untrusted_s >= 'a' && *untrusted_s <= 'z')
continue;
if (*untrusted_s >= 'A' && *untrusted_s <= 'Z')
continue;
if (*untrusted_s >= '0' && *untrusted_s <= '9')
continue;
if (*untrusted_s == '$' ||
   *untrusted_s == '_' ||
   *untrusted_s == '-' ||
   *untrusted_s == '.')
continue;
if (extra_allowed_chars && strchr(extra_allowed_chars, 
*untrusted_s))
continue;
*untrusted_s = '_';
}
}

and is invoked as [3]:

sanitize_name(untrusted_params.service_name, "+");
sanitize_name(untrusted_params.target_domain, ":");

Those arguments are part of the basis of policy evaluation. If policy
evaluation was successful, the parameters are then forwarded to the destination
domain over qrexec, and the call is executed using the qubes-rpc-multiplexer
executable, which is invoked by a POSIX shell. The exact mechanism differs
between dom0 and other qubes [4]:

if self.target == 'dom0':
cmd = '{multiplexer} {service} {source} {original_target}'.format(
multiplexer=QUBES_RPC_MULTIPLEXER_PATH,
service=self.service,
source=self.source,
original_target=self.original_target)
else:
cmd = '{user}:QUBESRPC {service} {source}'.format(
user=(self.rule.override_user or 'DEFAULT'),
service=self.service,
source=self.source)

# ...

try:
subprocess.call([QREXEC_CLIENT] + qrexec_opts + [cmd])

For the dom0 case, these are the relevant parts from the executable referenced
as QREXEC_CLIENT above [5]:

/* called from do_fork_exec */
void do_exec(const char *prog)
{
execl("/bin/bash", "bash", "-c", prog, NULL);
}

/* ... */

static void prepare_local_fds(char *cmdline)
{
/* ... */
do_fork_exec(cmdline, &local_pid, &local_stdin_fd,

[qubes-users] usb wifi randomly disconnects

[pc revival]

I installed qubes 4.0 rc 4 on my compal I7 laptop. My built in Wifi is not 
recognized so I use a generic usb mini dongle. It works fine but will randomly 
disconnect and reconnect to the wifi.
Any ideas as to why?

-- 
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/2e6670ad-6651-4751-8dde-7fd7e97e8dab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Start VMs on boot before user login (Qubes OS 4.0rc4)

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

-- 
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/983a6244-a504-4e56-b626-9c8f5e501b46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes OS 4.0RC4 can't get xterm from sys-usb, sys-net, sys-whonix

[wyory]

Hi,

I can't get anything to run using 'qvm-run' on the sys-vms (sys-usb,
sys-net, sys-whonix). Is this intentional? I'd like to get xterm on
sys-usb to run some disk diagnostics on an external drive using 'smartctl.'

Any suggestions?

Using Qubes OS 4.0RC4.

Thanks in advance.

-wyory

-- 
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/65f50157-71ca-5684-eac7-783c3c61edd5%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Installing Win7 on a Dell

[Glen H]

On Monday, February 19, 2018 at 1:05:09 AM UTC-5, Yuraeitha wrote:
> On Monday, February 19, 2018 at 6:08:44 AM UTC+1, Glen H wrote:
> > On Sunday, February 18, 2018 at 9:59:24 AM UTC-5, Daniel Moerner wrote:
> > > On Saturday, February 17, 2018 at 9:06:03 PM UTC-5, Glen H wrote:
> > > > Hi,
> > > > 
> > > > I'm a new user and am trying to get Win7 Pro x64 installed in Qubes 
> > > > 4rc4.  I have a Dell e7440 and it doesn't come with a Windows .iso.  
> > > > Before I installed Qubes I used the Dell recovery tool to create a 
> > > > recovery usb disk for Win7 to re-install the OS but I'm not sure if 
> > > > this is usable to install with Qubes.
> > > > 
> > > > I tried following the instructions on the Qubes website by creating a 
> > > > new Qube without a template but I could not change it from PVM to HVM.  
> > > > Then when I tried booting from the USB recovery disk it would load up a 
> > > > terminal and then exit after 10 seconds.
> > > > 
> > > > When I try to boot the recovery USB disk from the main BIOS it boots up 
> > > > fine.  Does anyone have any tips for installing Win7 in Qubes 4?
> > > > 
> > > > Thanks,
> > > > 
> > > > Glen
> > > 
> > > Hi,
> > > 
> > > Check out these two issues:
> > > Installing Windows 7: https://github.com/QubesOS/qubes-issues/issues/3592
> > > Installing Qubes Windows Tools: 
> > > https://github.com/QubesOS/qubes-issues/issues/3585
> > > 
> > > The two problems you describe in the post seem to be the following:
> > > 1. Use qvm-prefs to set the virt_mode to hvm; the GUI doesn't work.
> > > 2. Make sure you set the video-model to cirrus for install.
> > > 
> > > Best,
> > > Daniel
> > 
> > Hi,
> > 
> > Thanks for the tips Daniel.  I'm stuck at not being able to boot from the 
> > usb disk.  I am doing:
> > 
> > ```
> > qvm-create --class StandaloneVM --label red win7new
> > qvm-prefs win7new virt_mode hvm
> > qvm-prefs win7new memory 4000
> > qvm-prefs win7new maxmem 4000
> > qvm-prefs win7new kernel ''
> > qvm-volume extend win7new:root 25g
> > qvm-prefs win7new debug True
> > qvm-features win7new video-model cirrus
> > 
> > # Then attach usb drive to untrusted, but all of these fail to boot:
> > 
> > qvm-start --hddisk untrusted:sda win7new
> > qvm-start --hddisk untrusted:sda1 win7new
> > qvm-start --hddisk untrusted:/dev/sda win7new
> > qvm-start --hddisk untrusted:/dev/sda1 win7new
> > ```
> > 
> > I'm not sure whether to use the whole drive (no name) or the first 
> > partition (named DELLRESTORE)...but I tried both.
> > 
> > I get the error message in the win7new terminal:
> > 
> > ```
> > SeaBIOS (version ...)
> > Machine UUID ...
> > Booting from Hard Disk...
> > Boot failed: not a bootable disk
> > 
> > Booting from Floppy...
> > Boot failed: could not read the boot disk
> > 
> > No bootable device.
> > ```
> > 
> > So it seems that it doesn't recognize the USB drive as bootable even though 
> > I can boot it from the main BIOS (in legacy mode).  
> > 
> > Any help would be appreciated.
> > 
> > Glen
> 
> First, welcome to the Qubes community! :)
> 
> A few things first, starting to use Qubes can be a bit overwhelming, but 
> you'll get the hang of it over time if you keep using it. For starters, look 
> here in the command you use "untrusted:sda" which is something Qubes 
> exclusive and you therefore had no chance knowing this. Untrusted, is a word 
> that needs replacing for whichever untrusted AppVM you're using to hold your 
> USB or SATA controllers. It's called untrusted because dom0 is trusted, and 
> you need to use an less untrusted domain that doesn't compromise your more 
> trusted domain, dom0. This is a bit tricky for new users to catch on, on, as 
> it's ambiguity for new users, at best. To solve this, then you first need to 
> figure out where your controller is located. If you have no sys-usb or 
> similar, then it's likely still in dom0. It's insecure to keep this in the 
> secure dom0 domain, but mostly you should be fine for some time yet if you're 
> not a high target profile, and never leave your computer unattended in public 
> or near people you don't trust with your life. Still, having it in dom0 is 
> still more secure than not using Qubes. Just keep in mind you eventually want 
> to migrate away from using dom0 for anything, but it's not always easy just 
> yet due to some fixes and hardwares require you still manually manage dom0 
> from time to time, so it's not yet entirely a users responsibility, as there 
> are still times when you need to use dom0.
> 
> So if your USB or SATA controllers are in dom0 (Your SATA controllers will be 
> if you did not move them yourself, and USB controllers depend on your 
> hardware, the installer might or might not have done it automatically). If 
> you don't have a sys-usb VM, then it's probably still in dom0. 
> 
> I don't know your current knowledge on Linux, so I'll take the liberty to add 
> more details just in case.
> 
> In conclusion from the above, instead of untrusted, it should

[qubes-users] Installing Qubes 4 with petitboot

[qubes-os]

I have a new KCMA-D8 based machine with petitboot installed. When I 
attempt to boot from the Qubes 4 DVD, the install media is not 
recognized by petitboot. Other installation media that I've tried, like 
a Ubuntu CD, are recognized and I'm able to boot.


I've attempted to boot using a new manual entry in petitboot.

That has been somewhat successful as I've been able to get to the Qubes 
loading screen but eventually it just stops loading (no errors, etc.).


I suspect the problem is having the proper entires in my manual entry.

Currently I have:

kernel - /isolinux/vmlinuz
initrd - /isolinux/initrd.img
boot arguments - append xen.gz console=none --- vmlinuz 
inst.stage2=hd:LABEL=Qubes-R4.0-rc4-x86_64 i915.preliminary_hw_support=1 
quiet rhgb --- initrd.img


based on what I could find in the DVD's isolinux folder.

Not sure if that is what should be used. Can anyone with a KCMA-D8 or 
similar setup with petitboot shed any light?


Thanks in advance.

--
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/3c613d5d-ecbf-db5c-616f-09335a1374ad%40go-bailey.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: QUBES 4 r4 - dom0 UTC time is incorrect - manual change each reboot.

[QUBE-A-LICIOUS]

On Monday, February 19, 2018 at 4:08:36 AM UTC-6, schnuren...@gmail.com wrote:
> On Sunday, February 18, 2018 at 5:52:34 PM UTC+1, QUBE-A-LICIOUS wrote:
> > On Thursday, February 15, 2018 at 5:42:44 PM UTC-5, schnuren...@gmail.com 
> > wrote:
> > > On Tuesday, February 13, 2018 at 10:51:12 PM UTC+1, QUBE-A-LICIOUS wrote:
> > > > Hi there,
> > > > 
> > > > I have a fresh install of Qubes 4r4.  However, when I reboot and or 
> > > > login I have to manually change dom0 time to UTC.
> > > > 
> > > > Impact: Whonix/Tor does not work because of the incorrect time.
> > > > 
> > > > Manual workaround:
> > > > 1.  Get the correct UTC from a browser.
> > > > 2.  Open Dom0 Terminal and update to UTC such as the following:
> > > > 
> > > >   sudo date --set "2018-02-13 21:30"
> > > > 
> > > > 3. Shutdown Service:sys-whonix
> > > > 4.  Restart a whonix domain such as Domain:anon-whonix(this restarts 
> > > > the sys-whonix service that was just shutdown.
> > > > 5.  Then run WhonixCheck to make sure it works.  It usually does and 
> > > > Whonix/Tor is functional.
> > > > 
> > > > =
> > > > Qubes cannot be this bad, really.
> > > > 
> > > > How can I have this Date and time correctly updated on boot up?  Like 
> > > > it should.
> > > > 
> > > > Thanks for all your help.
> > > > NSJ
> > > 
> > > Most times it is easy to point on another guilty one instead looking what 
> > > may happen with the own stuff. So far you are the only one with this 
> > > misbehavior.
> > > Qubes works as expected - at least in this point.
> > > But most user already experienced this behavior; qubes-os or any other 
> > > distribution.
> > > The keyword is hwclock. You always update the software-based time, but if 
> > > you restart, all temporary data is gone. (should)
> > > So your OS fetches at boot the time from the bios.
> > > If you update your time within the qubes-os, you should update your 
> > > hardware clock (hc) as well: sudo hwclock --systohc
> > > If your time resets when you unplug your device from power supply, your 
> > > device's battery is flat.
> > 
> > --
> > I did some analysis this morning.  So at the same point in time the 
> > following settings on my Qubes laptop showed the following values.  (Bottom 
> > line is that whonix/tor does not work)
> > 
> > 1.  The hardware BIOS clock is:  1030  (BIOS battery good, removed laptop 
> > battery for few hours and date/time stayed same)
> > 
> > 2.  Dom0 time is: 0530 ( via date command)
> > 
> > 3.  service:sys-whonix is:  1030 (via date command)
> > 
> > 4.  Clock on upper right of screen is:  0430
> > 
> > Tor Boostrap info is:
> > 
> > Whonixcheck gave up waiting
> > clock skew -21635 in directory from DIRSERV
> > 
> > sudo date --set “2018 -02-18 17:30:00”
> > 
> > -
> > I think that on a normal bootup the clocks should be in sync and Whonix/Tor 
> > should work.
> 
> bios time differs a lot from dom0 and dom0 time seems in the UTC (timezone), 
> while the clock on your desktop should be therefore in the -1 hour timezone. 
> There is already something wrong, isn't it?
> Could you please set the correct time in dom0 and do a 'sudo hwclock 
> --systohw' to get dom0's sys date and bios time in sync.
> And reboot pls. After reboot check the time in bios, dom0 and your clockVM 
> (probably sys-net) before connecting to any network.
> In System Tools -> Qubes Global Settings in dom0 you can check the name of 
> the clock VM.
> The time of your whonix should, as far as I know, differs in timezone as 
> qubes built-in rule randomly each bootup of the VM. (Do not know for sure)
> 
> I either do not know whether sys-whonix only changes the timezone and if it 
> is an attack surface if someone from the outside could simulate/fake specific 
> minutes and seconds your network-time-daemon adapt and your whonix could be 
> associated to your isp.
> 
> Even there seems to be some misconfiguration I never got, the behavior 
> remembers me to an empty hardware battery.

==
1.  I changed to the correct Time Zone from the command line.  Fixed the -1 
hour offset.
2.  I updated the dom0 time
3.  I ran the sudo hwclock -w to set the hardware clock from the current system 
time.
4.  I rebooted the laptop.

The current results are:

1.  BIOS clock is:  1530  (via BIOS menu on startup)

2.  Dom0 time is: 0930 with correct time zone.  (Correct!)

3.  service:sys-whonix is:  1530 UTC

4.  Clock on upper right of screen is:  0930 (Correct!)

5.  sys-net is 0930.  (Correct!)

6.  Tor Boostrap info is:  (from sys-whonix occurs right after startup)

ERROR systemd clock check result:
Unexpected results by timedatectl
local time:  15:30:00
universal time: 15:30:00

However….
7.  Tor browser works!!!

I think that I am close, this error should not be coming up.  Any ideas?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group 

Re: [qubes-users] Re: Trying to install Ubuntu as HVM can't restart

[Unman]

On Mon, Feb 19, 2018 at 05:44:44AM -0800, snowboard...@gmail.com wrote:
> On Monday, February 19, 2018 at 2:36:08 PM UTC+1, Yuraeitha wrote:
> > On Monday, February 19, 2018 at 1:20:24 PM UTC+1, snowbo...@gmail.com wrote:
> > > I feel like a total idiot here but here is what I am doing:
> > > 
> > > 1) I make an HVM (tried both normal and template) and then assign more 
> > > disk space to it. 
> > > 2) I download the ubuntu iso file for desktop.
> > > 3) I run qvm-start ubuntu --cdrom=vmpath:/home/user/downloads/xxx.iso
> > > 4) I run the installation that surprisingly finishes ultra fast. There 
> > > are two disks one is xvda and xvdb. The first has the space that VM has 
> > > for "personal usage" and the second for "system". I tried installing on 
> > > both with same result.
> > > 5) As the installation finishes when I shutdown the machine it doesn't 
> > > shutdown. A black window keeps on. Then I kill it with Qubes-manager.
> > > 6) after that it doesn't start. It says booting from hard drive but 
> > > nothing happens.
> > > 
> > > I tried many times. What am I doing wrong?
> > > 
> > > thanks in advance
> > 
> > Don't label yourself as an idiot. Although I'm not an expert, but your 
> > logical approach seems pretty good to me, you try to find the reason and 
> > logic behind it. No matter what, trying to solve it is a good logical 
> > quality.
> > 
> > As for why it doesn't work, it seems like a driver issue for graphics? You 
> > could try change the AppVM's grub menu, and put a different graphic driver, 
> > xdriver=vesa, nomodeset, or something along those lines. Vast topics can be 
> > found on this issue, now that you can suspect graphiic issues, you can more 
> > easily find these topics to try troubleshoot it if neither commands above 
> > work.
> > 
> > You can also try change the used kernel to '' blank, since Ubuntu custom 
> > install without Qubes code, probably has no means to use its own kernel 
> > pulled from dom0 kernels, and the Ubuntu kernel may try to boot up while 
> > the VM kernel's located in dom0. As such, there may be a conflict here? I'm 
> > not sure if this is what is happening, but you can try put the qvm-prefs 
> > for the kernel in blank, install again and see what happens, it should 
> > allow Ubuntu to use its own kernel, I believe.
> > 
> > btw, for what purposes are you getting Ubuntu? By any chance is it codecs? 
> > are the other reasons? It may be more efficient to fix up Fedora or Debian, 
> > instead of getting Ubuntu up and running. It's just that there are so many 
> > Ubuntu questions lately, I'm a bit lost as to why people would want Ubuntu 
> > if they installed Qubes OS. Qubes OS is a bit of a leap to jump from 
> > Ubuntu, Debian or Fedora isn't that bad for next steps after Ubuntu, but 
> > Qubes OS may be a bit of a leap in its current state. 
> > 
> > The only real nice thing is the ease to install nvidia drivers, but that is 
> > hardly something you will end up needing in Qubes anyway. Can I ask what 
> > you need Ubuntu for? and perhaps if you desire to give it a shot for an 
> > alternative, and try Fedora and Debian to get the tasks done you usually do 
> > on Ubuntu? If you still feel like going for Ubuntu, then that's fine, I 
> > won't get in the way for that. 
> > 
> > As such, if keeping Ubuntu, fixing graphic drivers may be a good place to 
> > start here?
> 
> Hi thanks I will try that. I am using Ubuntu because Debian 8 is such a pain 
> when installing new software. You need to enable testing and unstable repos 
> and then you end up with a mixed system then things break down etc. Ubuntu 16 
> is for sure compatible with most software oob for the next 2 years. 
> 

Can you try again, just installing to the first disk?(xvda)
Also, make sure that you have enough memory allocated:
qvm-prefs  -s memory 8192
qvm-prefs  -s maxmem 8192

You're doing the right thing, and as you can boot from the iso all
should be fine. There are issues with Ubuntu resolution when running as
VM - you can see reference to this in the list in the past. Changing
graphics drivers wont help with that issue.

-- 
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/20180219161826.zizubfyve5h2tiat%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Start VMs on boot before user login (Qubes OS 4.0rc4)

[msgheap]

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 qubes-users@googlegroups.com.
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.

[qubes-users] Re: Trying to install Ubuntu as HVM can't restart

[snowboard789]

On Monday, February 19, 2018 at 2:36:08 PM UTC+1, Yuraeitha wrote:
> On Monday, February 19, 2018 at 1:20:24 PM UTC+1, snowbo...@gmail.com wrote:
> > I feel like a total idiot here but here is what I am doing:
> > 
> > 1) I make an HVM (tried both normal and template) and then assign more disk 
> > space to it. 
> > 2) I download the ubuntu iso file for desktop.
> > 3) I run qvm-start ubuntu --cdrom=vmpath:/home/user/downloads/xxx.iso
> > 4) I run the installation that surprisingly finishes ultra fast. There are 
> > two disks one is xvda and xvdb. The first has the space that VM has for 
> > "personal usage" and the second for "system". I tried installing on both 
> > with same result.
> > 5) As the installation finishes when I shutdown the machine it doesn't 
> > shutdown. A black window keeps on. Then I kill it with Qubes-manager.
> > 6) after that it doesn't start. It says booting from hard drive but nothing 
> > happens.
> > 
> > I tried many times. What am I doing wrong?
> > 
> > thanks in advance
> 
> Don't label yourself as an idiot. Although I'm not an expert, but your 
> logical approach seems pretty good to me, you try to find the reason and 
> logic behind it. No matter what, trying to solve it is a good logical quality.
> 
> As for why it doesn't work, it seems like a driver issue for graphics? You 
> could try change the AppVM's grub menu, and put a different graphic driver, 
> xdriver=vesa, nomodeset, or something along those lines. Vast topics can be 
> found on this issue, now that you can suspect graphiic issues, you can more 
> easily find these topics to try troubleshoot it if neither commands above 
> work.
> 
> You can also try change the used kernel to '' blank, since Ubuntu custom 
> install without Qubes code, probably has no means to use its own kernel 
> pulled from dom0 kernels, and the Ubuntu kernel may try to boot up while the 
> VM kernel's located in dom0. As such, there may be a conflict here? I'm not 
> sure if this is what is happening, but you can try put the qvm-prefs for the 
> kernel in blank, install again and see what happens, it should allow Ubuntu 
> to use its own kernel, I believe.
> 
> btw, for what purposes are you getting Ubuntu? By any chance is it codecs? 
> are the other reasons? It may be more efficient to fix up Fedora or Debian, 
> instead of getting Ubuntu up and running. It's just that there are so many 
> Ubuntu questions lately, I'm a bit lost as to why people would want Ubuntu if 
> they installed Qubes OS. Qubes OS is a bit of a leap to jump from Ubuntu, 
> Debian or Fedora isn't that bad for next steps after Ubuntu, but Qubes OS may 
> be a bit of a leap in its current state. 
> 
> The only real nice thing is the ease to install nvidia drivers, but that is 
> hardly something you will end up needing in Qubes anyway. Can I ask what you 
> need Ubuntu for? and perhaps if you desire to give it a shot for an 
> alternative, and try Fedora and Debian to get the tasks done you usually do 
> on Ubuntu? If you still feel like going for Ubuntu, then that's fine, I won't 
> get in the way for that. 
> 
> As such, if keeping Ubuntu, fixing graphic drivers may be a good place to 
> start here?

Hi thanks I will try that. I am using Ubuntu because Debian 8 is such a pain 
when installing new software. You need to enable testing and unstable repos and 
then you end up with a mixed system then things break down etc. Ubuntu 16 is 
for sure compatible with most software oob for the next 2 years. 

-- 
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/c57d7272-da14-4e8f-9938-df1b5a949bc1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Trying to install Ubuntu as HVM can't restart

[Yuraeitha]

On Monday, February 19, 2018 at 1:20:24 PM UTC+1, snowbo...@gmail.com wrote:
> I feel like a total idiot here but here is what I am doing:
> 
> 1) I make an HVM (tried both normal and template) and then assign more disk 
> space to it. 
> 2) I download the ubuntu iso file for desktop.
> 3) I run qvm-start ubuntu --cdrom=vmpath:/home/user/downloads/xxx.iso
> 4) I run the installation that surprisingly finishes ultra fast. There are 
> two disks one is xvda and xvdb. The first has the space that VM has for 
> "personal usage" and the second for "system". I tried installing on both with 
> same result.
> 5) As the installation finishes when I shutdown the machine it doesn't 
> shutdown. A black window keeps on. Then I kill it with Qubes-manager.
> 6) after that it doesn't start. It says booting from hard drive but nothing 
> happens.
> 
> I tried many times. What am I doing wrong?
> 
> thanks in advance

Don't label yourself as an idiot. Although I'm not an expert, but your logical 
approach seems pretty good to me, you try to find the reason and logic behind 
it. No matter what, trying to solve it is a good logical quality.

As for why it doesn't work, it seems like a driver issue for graphics? You 
could try change the AppVM's grub menu, and put a different graphic driver, 
xdriver=vesa, nomodeset, or something along those lines. Vast topics can be 
found on this issue, now that you can suspect graphiic issues, you can more 
easily find these topics to try troubleshoot it if neither commands above work.

You can also try change the used kernel to '' blank, since Ubuntu custom 
install without Qubes code, probably has no means to use its own kernel pulled 
from dom0 kernels, and the Ubuntu kernel may try to boot up while the VM 
kernel's located in dom0. As such, there may be a conflict here? I'm not sure 
if this is what is happening, but you can try put the qvm-prefs for the kernel 
in blank, install again and see what happens, it should allow Ubuntu to use its 
own kernel, I believe.

btw, for what purposes are you getting Ubuntu? By any chance is it codecs? are 
the other reasons? It may be more efficient to fix up Fedora or Debian, instead 
of getting Ubuntu up and running. It's just that there are so many Ubuntu 
questions lately, I'm a bit lost as to why people would want Ubuntu if they 
installed Qubes OS. Qubes OS is a bit of a leap to jump from Ubuntu, Debian or 
Fedora isn't that bad for next steps after Ubuntu, but Qubes OS may be a bit of 
a leap in its current state. 

The only real nice thing is the ease to install nvidia drivers, but that is 
hardly something you will end up needing in Qubes anyway. Can I ask what you 
need Ubuntu for? and perhaps if you desire to give it a shot for an 
alternative, and try Fedora and Debian to get the tasks done you usually do on 
Ubuntu? If you still feel like going for Ubuntu, then that's fine, I won't get 
in the way for that. 

As such, if keeping Ubuntu, fixing graphic drivers may be a good place to start 
here?

-- 
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/e1aff434-6818-4582-9fe7-e7d00982c5e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: How to add "nouveau.modeset=0" to boot settings in Qubes 4.x?

[Yuraeitha]

On Monday, February 19, 2018 at 11:24:14 AM UTC+1, @LeeteqXV wrote:
> I am considering Qubes 4.x for an ASUS ROG GL552VW-DM141 laptop with 
> NVIDIA graphics and built-in/onboard "fallback" Intel graphics.
> 
> In order to get for example Ubuntu Mate installed onto it, to get past 
> the installer incompatibilities with NVidia, it is necessary to edit the 
> boot menu and add "nouveau.modeset=0" to the startup command. Then 
> Ubuntu boots fine.
> 
> Can this be done with Qubes 4.x?
> How/where to affect such boot commands; can that be done from the boot 
> media/USB stick directly, as we do with other Linux live USB sticks?
> 
> Thanks,

@LeeteqXV
It's probably best you start a new thread, this thread is about a whole 
different issue altogether. 

But since this is an old thread, I'll briefly answer you. 
This what you seek, directing a GPU directly into an AppVM, or any other work 
arounds, can currently be done in Qubes 3.2. nor Qubes 4.0. 

However, it is planned for Qubes 4.1, which may reach release. Just don't get 
hyped yet, things can change, 4.0. is barely finished and 4.1. is currently 
only on the drawing board. Look here for quick information about 4.1. 
https://github.com/rootkovska/qubes-roadmap you can see the GTX passthrough 
ability on the map.

Also, you don't really need Ubuntu for these kind of things, it can easily be 
fixed up in both Debian and Fedora. You can use Intel graphics just fine for 4k 
videos, you don't need nvidia for stuff like that on modern motherboard/CPU 
systems. You may need powerful graphic cards for gaming and high end graphics, 
but this too isn't possible, at least before Qubes 4.1. anyway. If you didn't 
need these in Qubes 4, then it will likely make no difference to you to use 
Intel graphics. Also Qubes dom0 frequently has nvidia graphic issues and may 
require a full properitary driver download/install, with a manual install. 

To get a bit back on-topic, it saves you whole lot of hassle if you get 
adjusted to not be depending too much on Ubuntu and others that give everything 
on a silverplate. Although DVM protected content is never stable regardless of 
the Linux distribution, unless you download the Google Chrome browser from 
Google (Not Chromium), which usually always have working DVM videos in any 
Linux. Issue being, that Firefox and others, often loose the ability to play 
the video, especially Microsoft silverlight videos, which the work-arounds 
frequently break.

Essentially you can play the codecs fine, HTML5 is for example extremely easy 
to install in Fedora through enabling the RPMFusion repositories, which can 
easily be done in Qubes fedora template (best make a copy first). But it does 
not include HTML5-DVM. 

Essentially, DVM is so messed up, you may just want to download the Google 
Browser specifically for these videos, and just be done with the crapware 
copyright protectors throw at us. It's not like they care about Linux anyway, 
so why would changing to Ubuntu make any difference? Ubuntu is just as unstable 
in this regard of protected content due to lack of developer support of 
protected contents.

However, Fedora+Firefox+RPMFusionRepositories+ffmpeg+Firefox's own DVM = 
Netflix and all HTML5 videos on youtube, and similar modern websites, works 
smoothly without issues.

Try not to get too dependent on a system, really it makes little difference if 
you adjust yourself to it.

Also install Qubes with LegacyBIOS/Grub and press the E key during the Grub 
menu, then add after or before "quiet" on the module code-line. Or just 
temporarily disable nvidia in your UEFI, works too, more or less does the same 
as nouveau.modeset=0.

-- 
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/c1fa7a3f-1a8c-4f94-b841-b494a2463aa3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Start VMs on boot before user login (Qubes OS 4.0rc4)

[Yuraeitha]

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?

-- 
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/04f3099e-89ef-4dc0-a16d-497350d6db73%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Trying to install Ubuntu as HVM can't restart

[snowboard789]

I feel like a total idiot here but here is what I am doing:

1) I make an HVM (tried both normal and template) and then assign more disk 
space to it. 
2) I download the ubuntu iso file for desktop.
3) I run qvm-start ubuntu --cdrom=vmpath:/home/user/downloads/xxx.iso
4) I run the installation that surprisingly finishes ultra fast. There are two 
disks one is xvda and xvdb. The first has the space that VM has for "personal 
usage" and the second for "system". I tried installing on both with same result.
5) As the installation finishes when I shutdown the machine it doesn't 
shutdown. A black window keeps on. Then I kill it with Qubes-manager.
6) after that it doesn't start. It says booting from hard drive but nothing 
happens.

I tried many times. What am I doing wrong?

thanks in advance

-- 
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/cc4d7ae2-2fde-4d01-af3d-c2999c07013f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Start VMs on boot before user login (Qubes OS 4.0rc4)

[msgheap]

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.

-- 
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/429151ce-5167-47cd-8474-c4ea94dffa5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] cannot build ubuntu template

[snowboard789]

On Sunday, February 18, 2018 at 5:39:01 PM UTC+1, Unman wrote:
> On Sat, Feb 17, 2018 at 07:54:17AM -0800, snowboard...@gmail.com wrote:
> > running qubes 3.2
> > 
> > I am following default instructions from Archlinux.Tried to build template 
> > for trusty.
> > 
> > I cloned the default repo.
> > 
> > there is a problem with python2 because in fedora 23 there is no such 
> > package. I had to manually edit and put python-sh in Makefile, builder.conf 
> > and setup script. After that everything seems to be working fine but it 
> > crashes during make qubes-vm with this message:
> > 
> > ln -s ../../bin/qrexec-client-vm 
> > /home/user/qubes-src/core-agent-linux/debian/tmp/usr/lib/qubes/qrexec_client_vm
> > install qrexec-fork-server 
> > /home/user/qubes-src/core-agent-linux/debian/tmp/usr/bin
> > install qubes-rpc-multiplexer 
> > /home/user/qubes-src/core-agent-linux/debian/tmp/usr/lib/qubes
> > make[2]: Leaving directory `/home/user/qubes-src/core-agent-linux/qrexec'
> > make[1]: Leaving directory `/home/user/qubes-src/core-agent-linux'
> >dh_install
> > cp: cannot stat 
> > 'debian/tmp/lib/systemd/system/netfilter-persistent.service.d/30_qubes.conf':
> >  No such file or directory
> > dh_install: cp -a 
> > debian/tmp/lib/systemd/system/netfilter-persistent.service.d/30_qubes.conf 
> > debian/qubes-core-agent//lib/systemd/system/netfilter-persistent.service.d/ 
> > returned exit code 1
> > make: *** [binary] Error 2
> > dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit 
> > status 2
> > /home/user/qubes-builder/qubes-src/builder-debian/Makefile.qubuntu:200: 
> > recipe for target 'dist-package' failed
> > make[2]: *** [dist-package] Error 2
> > Makefile.generic:156: recipe for target 'packages' failed
> > make[1]: *** [packages] Error 1
> > Makefile:212: recipe for target 'core-agent-linux-vm' failed
> > 
> > 
> > Why is it so difficult to build a default template? Should be working oob 
> > right?
> > 
> It should indeed work oob.
> Truth is that I only really support 1 LTS and the latest Ubuntu
> version. I havent built Trusty for some time, and it's difficult to keep
> it up to date with the changing code base.The right thing to do would be
> to take it out the build configs.
> If there's some specific reason that you need trusty, and you cant
> install as HVM, I'll take a quick look and see if the build issues can
> be fixed. It may be simple.
> Can you let me know?

I am sorry, new to Qbues here didn't realize I can install anything with HVM. 
cheers

-- 
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/f6f2fbd4-3753-4915-a64e-ed413531beb6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] How to add "nouveau.modeset=0" to boot settings in Qubes 4.x?

[@LeeteqXV (Twitter & Mastodon.technology)]

I am considering Qubes 4.x for an ASUS ROG GL552VW-DM141 laptop with 
NVIDIA graphics and built-in/onboard "fallback" Intel graphics.


In order to get for example Ubuntu Mate installed onto it, to get past 
the installer incompatibilities with NVidia, it is necessary to edit the 
boot menu and add "nouveau.modeset=0" to the startup command. Then 
Ubuntu boots fine.


Can this be done with Qubes 4.x?
How/where to affect such boot commands; can that be done from the boot 
media/USB stick directly, as we do with other Linux live USB sticks?


Thanks,

--
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/9f73691a-7383-e985-4575-8d6e258f66e3%40leeteq.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] How to add "nouveau.modeset=0" to boot settings in Qubes 4.x?

[@LeeteqXV (Twitter & Mastodon.technology)]

I am considering Qubes 4.x for an ASUS ROG GL552VW-DM141 laptop with 
NVIDIA graphics and built-in/onboard "fallback" Intel graphics.


In order to get for example Ubuntu Mate installed onto it, to get past 
the installer incompatibilities with NVidia, it is necessary to edit the 
boot menu and add "nouveau.modeset=0" to the startup command. Then 
Ubuntu boots fine.


Can this be done with Qubes 4.x?
How/where to affect such boot commands; can that be done from the boot 
media/USB stick directly, as we do with other Linux live USB sticks?


Thanks,

--
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/19077588-cfbb-6608-6a1e-0e99df77ab2d%40leeteq.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: QUBES 4 r4 - dom0 UTC time is incorrect - manual change each reboot.

[schnurentwickler]

On Sunday, February 18, 2018 at 5:52:34 PM UTC+1, QUBE-A-LICIOUS wrote:
> On Thursday, February 15, 2018 at 5:42:44 PM UTC-5, schnuren...@gmail.com 
> wrote:
> > On Tuesday, February 13, 2018 at 10:51:12 PM UTC+1, QUBE-A-LICIOUS wrote:
> > > Hi there,
> > > 
> > > I have a fresh install of Qubes 4r4.  However, when I reboot and or login 
> > > I have to manually change dom0 time to UTC.
> > > 
> > > Impact: Whonix/Tor does not work because of the incorrect time.
> > > 
> > > Manual workaround:
> > > 1.  Get the correct UTC from a browser.
> > > 2.  Open Dom0 Terminal and update to UTC such as the following:
> > > 
> > >   sudo date --set "2018-02-13 21:30"
> > > 
> > > 3. Shutdown Service:sys-whonix
> > > 4.  Restart a whonix domain such as Domain:anon-whonix(this restarts the 
> > > sys-whonix service that was just shutdown.
> > > 5.  Then run WhonixCheck to make sure it works.  It usually does and 
> > > Whonix/Tor is functional.
> > > 
> > > =
> > > Qubes cannot be this bad, really.
> > > 
> > > How can I have this Date and time correctly updated on boot up?  Like it 
> > > should.
> > > 
> > > Thanks for all your help.
> > > NSJ
> > 
> > Most times it is easy to point on another guilty one instead looking what 
> > may happen with the own stuff. So far you are the only one with this 
> > misbehavior.
> > Qubes works as expected - at least in this point.
> > But most user already experienced this behavior; qubes-os or any other 
> > distribution.
> > The keyword is hwclock. You always update the software-based time, but if 
> > you restart, all temporary data is gone. (should)
> > So your OS fetches at boot the time from the bios.
> > If you update your time within the qubes-os, you should update your 
> > hardware clock (hc) as well: sudo hwclock --systohc
> > If your time resets when you unplug your device from power supply, your 
> > device's battery is flat.
> 
> --
> I did some analysis this morning.  So at the same point in time the following 
> settings on my Qubes laptop showed the following values.  (Bottom line is 
> that whonix/tor does not work)
> 
> 1.  The hardware BIOS clock is:  1030  (BIOS battery good, removed laptop 
> battery for few hours and date/time stayed same)
> 
> 2.  Dom0 time is: 0530 ( via date command)
> 
> 3.  service:sys-whonix is:  1030 (via date command)
> 
> 4.  Clock on upper right of screen is:  0430
> 
> Tor Boostrap info is:
> 
> Whonixcheck gave up waiting
> clock skew -21635 in directory from DIRSERV
> 
> sudo date --set “2018 -02-18 17:30:00”
> 
> -
> I think that on a normal bootup the clocks should be in sync and Whonix/Tor 
> should work.

bios time differs a lot from dom0 and dom0 time seems in the UTC (timezone), 
while the clock on your desktop should be therefore in the -1 hour timezone. 
There is already something wrong, isn't it?
Could you please set the correct time in dom0 and do a 'sudo hwclock --systohw' 
to get dom0's sys date and bios time in sync.
And reboot pls. After reboot check the time in bios, dom0 and your clockVM 
(probably sys-net) before connecting to any network.
In System Tools -> Qubes Global Settings in dom0 you can check the name of the 
clock VM.
The time of your whonix should, as far as I know, differs in timezone as qubes 
built-in rule randomly each bootup of the VM. (Do not know for sure)

I either do not know whether sys-whonix only changes the timezone and if it is 
an attack surface if someone from the outside could simulate/fake specific 
minutes and seconds your network-time-daemon adapt and your whonix could be 
associated to your isp.

Even there seems to be some misconfiguration I never got, the behavior 
remembers me to an empty hardware battery.

-- 
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/1f50c1eb-5097-4605-8cb5-b6525d3bd2e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.