Re: [qubes-users] ThinkPad W530

[Simon Newton]

Sounds like you have not enabled VT-d (intel virtualisation) in the bios.
That CPU does support VT-d, so it just needs to be enabled in the bios for
qubesOS to work properly.


S

On Thu, 4 May 2023 at 10:40, T. I. N. Comp-E  wrote:

> I hope this finds you well... I have a thinkpad W530. I was able to
> upgrade it to upgrade the ram to 16 Gigs I have met all the
> requirements and specs(I7 3740QM)... it still say my pc is not
> supported what else do i need to do... Ive tried many combination on
> the bios I dont know how to unlock the advanced tab, I dont understand
> what im doing wrong... please help
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/CAAMOyp0zzDXGh%3DNMqAgXLAdcpO5v9KkxrJN9bmLh4h1%2BgEd1oA%40mail.gmail.com
> <https://groups.google.com/d/msgid/qubes-users/CAAMOyp0zzDXGh%3DNMqAgXLAdcpO5v9KkxrJN9bmLh4h1%2BgEd1oA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>


-- 
Kind Regards,

Simon Newton

E: simon.new...@gmail.com

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CADLktjC7OOm0fCnnzS%3D6f3U6w4R%2BZE_nQN7K1opUvEsuUXZ9Gw%40mail.gmail.com.

Re: [qubes-users] [UPDATE] Re: NitroPad T430 passes hardware certification for Qubes 4.0!

[Simon Newton]

 On Sun, 3 Apr 2022 at 16:46, Franz <169...@gmail.com> wrote:

>
> Many thanks Simon,
> I do not have a T430, I have a W520 with coreboot, but the problem is just
> the same.  I was wondering why VT-d is not working and your email explained
> it. So many thanks.
> Now I suppose I should buy some other Ivy Bridge CPU that fully supports
> virtualization. But if Intel gave the same name to CPUs having different
> features I am very afraid to go wrong again. May you please give me some
> hints to find a compatible CPU?
> Best
> Franz
>
>
Sure -

On the intel ark pages, just check the 'package size' section and make sure
that its rPGA988. Make sure the cpu has VT-d.

I havent done any work on the w520 so I cant really advise on which would
be the best CPU. On the t430 I run 3740QM but this requires changing the
heatsink as the CPU is 45w TDP where the original CPU was 35w TDP.  Sven
runs the 3840QM on his laptop. Both CPUs are the top end of what you can
get with both VTd and staying at 45w TDP for heat.

This page
https://forums.lenovo.com/t5/ThinkPad-P-and-W-Series-Mobile/w520-cpu-upgrade/m-p/1559926
over at lenovo forums seems to imply that some fan assemblies for the w520
can handle 55wTDP (they have part numbers on the page too). This means that
the best performing CPU you could use with Qubes in the w520 is i7 3940XM
but its going to throw out some heat when its under load. Its a small gain
over the 3840QM, so if burning your legs is a concern then maybe just go
for the 3740/3840 .. just make sure your existing fan assembly can handle
45w TDP (or 55w TDP if you chose 3940).

-- 
Kind Regards,

Simon Newton

E: simon.new...@gmail.com

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CADLktjDS4CnePM8kPAzTxs97ZpJAVVQT7U686sdqj%2B-NBQ9N6A%40mail.gmail.com.

Re: [qubes-users] [UPDATE] Re: NitroPad T430 passes hardware certification for Qubes 4.0!

[Simon Newton]

>Are you sure? Intel tells that i7-3632QM supports VT-d

Yes. You have made the same mistake nitrokey did. There are two versions of
the CPU, one is BGA which supports VT-d, but does not fit the rPGA T430
motherboard. The other is the rPGA version, which does fit the T430 but
does not have VT-d
https://www.intel.com/content/www/us/en/products/sku/71458/intel-core-i73632qm-processor-6m-cache-up-to-3-20-ghz-rpga/specifications.html

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CADLktjA65Oe-eXw030-X68UR%2BYmgCSsPhQYvDQ1SanYGZXUwEg%40mail.gmail.com.

Re: [qubes-users] Nitropad X230 with Qubes 4.1

[Simon Newton]

On Wed, 19 Jan 2022 at 12:51, 'taran1s' via qubes-users <
qubes-users@googlegroups.com> wrote:

> Hello everyone, I am using the Nitropad X230 with the latest 4.0 Qubes
> installed.
>
> In the conversation with Thierry Laurion here
> https://groups.google.com/g/qubes-users/c/KsY46D55UQM/m/F3cQ-89KBQAJ it
> seemed that at that time the Nitropad X230 was not ready to transit to
> Qubes 4.1.
>
> This part of the conversation actually: Heads will need to be reflashed
> with a ROM supporting cryptsetup2 to reinstall. Heada will also need to
> be based on coreboot 4.13+ as per pending Heads pull request 1015.
>
> Consider this as a beta testing ROM.
>
> Is the situation different now with rc4, or is it advisable to wait till
> the transition will be ready?
>
> Thank you!
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/01457a0b-9ac2-c4f4-7678-56e25de0374b%40mailbox.org
> .
>

Nitropad will need to provide you an upgrade path that supports Cryptsetup2
in order to move to QubesOs 4.1

Alternatively, you could flash a current version of the X230 heads firmware
(which uses 4.13 and cryptsetup2) by building this yourself from source, or
grabbing a prebuilt bin from the Heads CircleCI
https://app.circleci.com/pipelines/github/osresearch/heads - the hardware
is still an X230.

However you need to consider if Nitropad would support your product were
you to do this.

-- 
Kind Regards,

Simon Newton

E: simon.new...@gmail.com

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CADLktjANHT7xUMP2xbUqd7cQf3hCVJUb0FGMdAPZT6SDkns5Bw%40mail.gmail.com.

Re: [qubes-users] Re: [HCL] ThinkPad T430

[Simon Newton]

Coreboot comes as part of heads - so you just build heads and flash that to
the 4mb and 8mb chips inside.

On Sat, 11 Sept 2021 at 14:23, Will Lewis 
wrote:

> I have to compliment your taste in hardware, I’m building almost exactly
> the same machine as we speak except for the SSD, I'm using a 1TB 870 Pro.
>
>
>
> Although, I’m entirely new to coreboot and am trying to gather as much
> info as possible, I’m at the last stage before flashing but I am struggling
> to understand some of the config options.
>
> If at all possible, could I have a look at your config file Sven as our
> builds are almost identical.
>
>
>
> Also did you flash Coreboot with seabios and then internally flash heads?
>
>
>
> Thanks,
>
> Stacey
>
>
> On Saturday, June 12, 2021 at 10:48:01 PM UTC+1 sv...@svensemmler.org
> wrote:
>
>> On 6/10/21 3:12 PM, Sven Semmler wrote:
>> > The one I've used is the i7-3740QM which was recommended by @Plexus.
>> > It's a tiny bit less powerful than the i7-3840QM but about half the
>> > price (if you shop right and not just go for the first listing on
>> Amazon
>> > as I did).
>>
>> Actually at least in the US the price difference is basically
>> non-existent and I can't stand the fact that I *could* have a faster
>> CPU. So I ordered the i7-3840QM and will pop it in / resubmit the HCL
>> when it arrives.
>>
>> /Sven
>>
>> --
>> public key: https://www.svensemmler.org/2A632C537D744BC7.asc
>> fingerprint: DA59 75C9 ABC4 0C83 3B2F 620B 2A63 2C53 7D74 4BC7
>>
>> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/672ae672-3d5f-421b-90dd-cdea3c1888b3n%40googlegroups.com
> <https://groups.google.com/d/msgid/qubes-users/672ae672-3d5f-421b-90dd-cdea3c1888b3n%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Kind Regards,

Simon Newton

E: simon.new...@gmail.com

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CADLktjDuuhVbnHU7PAaXS4tosokbxeBXp6%2B1G9_%3DE%2Bx2CW7U6Q%40mail.gmail.com.

[qubes-users] Re: service VMs not auto starting

[simon . newton]

On Saturday, May 11, 2019 at 1:47:05 PM UTC+1, simon...@gmail.com wrote:
> Ive not had this problem on any other machine I run qubes on, and its a bit 
> perplexing
> 
> service VMs will not start automatically during the boot process. systemctl 
> status returns "libxenlight failed to create new domain"
> 
> libxl-driver.log shows "domcreate_attached_devices: unable to add PCI 
> devices" and "Backend /local/domain/0/backend/pci/X/0 not ready" as well asl 
> "/dev/loop0 no such device or address"
> 
> I thought maybe some IOMMU issue, but xl dmesg reports that the IOMMU is 
> inited correctly. 
> 
> I found I could not manually start any qube from the command line. While 
> trying to figure it out, i notied xl list showed dom0 had all the avialable 
> RAM allocated to it. So I did xl mem-set 0 1536 
> 
> at this point, systemctl will happily start all service qubes. no problem 
> whatsoever. So its something to do with dom0 and handing out ram.
> 
> the boot command line contains dom0_mem=min:1024M and dom0_mem=max:1536M but 
> these are seemingly ignored. 
> 
> Any suggestions?

and just when you post up asking for help, you find the solution. Its a 
heads issue, and the branch im using is a 4.9 branch without the fix in it. 

https://github.com/osresearch/heads/issues/536

-- 
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/6ae6f1fe-7023-473b-81e7-8154913ac218%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] service VMs not auto starting

[simon . newton]

Ive not had this problem on any other machine I run qubes on, and its a bit 
perplexing

service VMs will not start automatically during the boot process. systemctl 
status returns "libxenlight failed to create new domain"

libxl-driver.log shows "domcreate_attached_devices: unable to add PCI devices" 
and "Backend /local/domain/0/backend/pci/X/0 not ready" as well asl "/dev/loop0 
no such device or address"

I thought maybe some IOMMU issue, but xl dmesg reports that the IOMMU is inited 
correctly. 

I found I could not manually start any qube from the command line. While trying 
to figure it out, i notied xl list showed dom0 had all the avialable RAM 
allocated to it. So I did xl mem-set 0 1536 

at this point, systemctl will happily start all service qubes. no problem 
whatsoever. So its something to do with dom0 and handing out ram.

the boot command line contains dom0_mem=min:1024M and dom0_mem=max:1536M but 
these are seemingly ignored. 

Any suggestions? 

-- 
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/8c4125c2-b339-47be-8694-935f0e52c632%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] why was DNS/ICMP removed from Qubes manager/firewall in R4?

[simon . newton]

On Thursday, February 14, 2019 at 3:35:27 PM UTC, unman wrote:
> On Thu, Feb 14, 2019 at 03:13:50PM +0100, ashleybrown...@tutanota.com wrote:
> > Hopefully one day they revert it back to how it was in 3.2. A very common 
> > use-case for the firewall is likely to ensure things like DNS requests do 
> > not happen through the normal means (and instead go over something like Tor 
> > or a VPN). Unfortunately, the current config does not make it very obvious 
> > that someone should block DNS ports. Making it very easy for someone to 
> > shoot themselves in the foot because the interface is not intuitive (it 
> > says it blocks all traffic other than what is specified and then later 
> > modifies this saying "just kidding, we let DNS through")
> > 
> > Feb 14, 2019, 11:59 AM by simon.new...@gmail.com:
> > 
> > > On Thursday, February 14, 2019 at 11:54:28 AM UTC, simon@gmail.com 
> > > wrote:
> > >
> > >> > On Wed, Feb 13, 2019 at 08:42:10AM -0800, >> simon.new...@gmail.com 
> > >> > >>  wrote:
> > >> > > In 3, if i clicked on "block connections" in the Qubes manager 
> > >> > > firewall section, there was (if memory serves me) an option to block 
> > >> > > DNS and ICMP. 
> > >> > > 
> > >> > > That is not present in R4 (though docs say you can disable DNS and 
> > >> > > ICMP manually)
> > >> > > 
> > >> > > I'm just wondering what the logic behind the removal was? I would 
> > >> > > have thought that a general user who clicks "block connections" on 
> > >> > > Qube would not expect the qube to be able to actually send out and 
> > >> > > receive network packets such as DNS or ICMP. This presents 
> > >> > > information leakage scenarios (default DNS lookups of given qube) 
> > >> > > and also potential egress vectors if a qube is ever compromised (DNS 
> > >> > > tunnelling, ICMP tunnelling). 
> > >> > 
> > >> As I said, I understand the documentation is correct. thats not my 
> > >> question. My question is why was it removed as an option when the 
> > >> firewall box itself in network manager says "Deny network access 
> > >> except..." 
> > >>
> > >> My point is it is counter intuitive. If it says "deny network access 
> > >> exccept..." then there is an expectation that it will deny network 
> > >> access except for what is specified. There used to be tick buttons 
> > >> (allow updates/allow ICMP/allow DNS), which made it clear on the 
> > >> granular control there - but were removed in R4. The underlying 
> > >> subsytems you can still do that, sure. 
> > >>
> > >> Can I suggest that the wording "deny network access except..." is 
> > >> changed to "Deny TCP and UDP access except ..." for the avoidance of any 
> > >> doubt.
> > >>
> > >
> > >
> > > https://github.com/QubesOS/qubes-manager/pull/153 
> > > 
> > >
> 
> Please dont top post - it breaks the thread of the conversation.
> 
> I dont find the current position confusing, since the DNS and ICMP
> position is clearly stated in the NOTE at the bottom of the window.
> 
> Simon, to answer your original question, there are many features in 4.0
> which are aimed at simplifying use of Qubes. I think this is one of
> them.
> The underlying issue is this: if you want to set a firewall rule using a
> named site, then you must not only  set the rule, (and the resolution
> will be set at the upstream firewall), but you must also enable DNS -
> otherwise your qube will not be able to resolve the address, even
> though you have correctly set the firewall rule.
> This adds a layer of complexity which a naive user would not understand.
> 
> The decision was made to keep DNS open in a trade off between usability
> and security.
> There's also an underlying assumption that users who want more will be
> able to negotiate command line tools. This assumption may be misplaced.
> There are many users (not only of Qubes) who consider themselves "power
> users" (never understood what that meant), but dont seem able to
> understand iptables or use anything except a GUI. (Just to be clear, I'm
> not aiming at any contributor here.)
> 
> As for ICMP, it's a moot point whether you should ever block ICMP at
> firewall level. Again, the benefit of having ICMP enabled is that basic
> network mechanisms are enabled, and basic diagnostic tools are
> available. It's a trade off between security and usability.
> 
> As with *all* parts of Qubes, if you dont like the defaults change them
> on your system.
> If you like, propose a change by submitting a PR.
> There's an open issue on exactly this, where Marta outlined the issue and
> invited contributions that would allow the change and also keep clarity
> for naive users (my gloss). No one has yet stepped up.
> 
> unman

Thanks Unman, thats a detailed and logical explanation as to where its gone. It 
makes a bit more sense now. As I said, it wasn't anything to do with 
documentation, more around managing a users expectations. If I have some time 

Re: [qubes-users] why was DNS/ICMP removed from Qubes manager/firewall in R4?

[simon . newton]

On Thursday, February 14, 2019 at 11:54:28 AM UTC, simon@gmail.com wrote:
> On Thursday, February 14, 2019 at 3:54:04 AM UTC, Marek Marczykowski-Górecki 
> wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > On Wed, Feb 13, 2019 at 08:42:10AM -0800, simon.new...@gmail.com wrote:
> > > In 3, if i clicked on "block connections" in the Qubes manager firewall 
> > > section, there was (if memory serves me) an option to block DNS and ICMP. 
> > > 
> > > That is not present in R4 (though docs say you can disable DNS and ICMP 
> > > manually)
> > > 
> > > I'm just wondering what the logic behind the removal was? I would have 
> > > thought that a general user who clicks "block connections" on Qube would 
> > > not expect the qube to be able to actually send out and receive network 
> > > packets such as DNS or ICMP. This presents information leakage scenarios 
> > > (default DNS lookups of given qube) and also potential egress vectors if 
> > > a qube is ever compromised (DNS tunnelling, ICMP tunnelling). 
> > 
> > Let me quote full text you can find on firewall tab there:
> > 
> > NOTE: To block all network access, set Networking to (none) on the
> > Basic settings tab. This tab provides a very simplified firewall
> > configuration. All DNS requests and ICMP (pings) will be allowed. For
> > more granular control, use the command line tool qvm-firewall.
> > 
> > There is clear message what to do if you want to cut the qube from the
> > network.
> > 
> > - -- 
> > Best Regards,
> > Marek Marczykowski-Górecki
> > Invisible Things Lab
> > A: Because it messes up the order in which people normally read text.
> > Q: Why is top-posting such a bad thing?
> > -BEGIN PGP SIGNATURE-
> > 
> > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxk5lQACgkQ24/THMrX
> > 1yzyBQf+ID5V7ema8i77kmTCnsWfNeSPUQnlTjuQbF1oNZJFNeAwAaqp3FLO+Ljt
> > Slj7e9KjbPYrxxuW40LIL05G78Yqs/MpZ1mA6/Yfy6J2tvoluucTFvatiHqiodO3
> > HLqyRSehMXqqzKTHNrLrfLWWyz6ykbP/MmIw1zsxjcXj8RCNuEMc5F4qC6npluWN
> > cahMNcZLELo4PsrjzhqTrSr0BmlVLDQ5QLwoJGi8wSDGMEIDX3qvwq56wh6O0MgR
> > J780J043BcrIiAfZorrG+WfpLebkU9uSjmOENxcZQQwz2JmEdod9dU1vUEPSdBY1
> > EKOq9FhCjMI6De6nNgiMf63Y47CxuQ==
> > =9dvG
> > -END PGP SIGNATURE-
> 
> As I said, I understand the documentation is correct. thats not my question. 
> My question is why was it removed as an option when the firewall box itself 
> in network manager says "Deny network access except..." 
> 
> My point is it is counter intuitive. If it says "deny network access 
> exccept..." then there is an expectation that it will deny network access 
> except for what is specified. There used to be tick buttons (allow 
> updates/allow ICMP/allow DNS), which made it clear on the granular control 
> there - but were removed in R4. The underlying subsytems you can still do 
> that, sure. 
> 
> Can I suggest that the wording "deny network access except..." is changed to 
> "Deny TCP and UDP access except ..." for the avoidance of any doubt.


https://github.com/QubesOS/qubes-manager/pull/153

-- 
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/39615092-155b-4f93-a418-95f7ff95c71f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] why was DNS/ICMP removed from Qubes manager/firewall in R4?

[simon . newton]

On Thursday, February 14, 2019 at 3:54:04 AM UTC, Marek Marczykowski-Górecki 
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Wed, Feb 13, 2019 at 08:42:10AM -0800, simon.new...@gmail.com wrote:
> > In 3, if i clicked on "block connections" in the Qubes manager firewall 
> > section, there was (if memory serves me) an option to block DNS and ICMP. 
> > 
> > That is not present in R4 (though docs say you can disable DNS and ICMP 
> > manually)
> > 
> > I'm just wondering what the logic behind the removal was? I would have 
> > thought that a general user who clicks "block connections" on Qube would 
> > not expect the qube to be able to actually send out and receive network 
> > packets such as DNS or ICMP. This presents information leakage scenarios 
> > (default DNS lookups of given qube) and also potential egress vectors if a 
> > qube is ever compromised (DNS tunnelling, ICMP tunnelling). 
> 
> Let me quote full text you can find on firewall tab there:
> 
> NOTE: To block all network access, set Networking to (none) on the
> Basic settings tab. This tab provides a very simplified firewall
> configuration. All DNS requests and ICMP (pings) will be allowed. For
> more granular control, use the command line tool qvm-firewall.
> 
> There is clear message what to do if you want to cut the qube from the
> network.
> 
> - -- 
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> -BEGIN PGP SIGNATURE-
> 
> iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxk5lQACgkQ24/THMrX
> 1yzyBQf+ID5V7ema8i77kmTCnsWfNeSPUQnlTjuQbF1oNZJFNeAwAaqp3FLO+Ljt
> Slj7e9KjbPYrxxuW40LIL05G78Yqs/MpZ1mA6/Yfy6J2tvoluucTFvatiHqiodO3
> HLqyRSehMXqqzKTHNrLrfLWWyz6ykbP/MmIw1zsxjcXj8RCNuEMc5F4qC6npluWN
> cahMNcZLELo4PsrjzhqTrSr0BmlVLDQ5QLwoJGi8wSDGMEIDX3qvwq56wh6O0MgR
> J780J043BcrIiAfZorrG+WfpLebkU9uSjmOENxcZQQwz2JmEdod9dU1vUEPSdBY1
> EKOq9FhCjMI6De6nNgiMf63Y47CxuQ==
> =9dvG
> -END PGP SIGNATURE-

As I said, I understand the documentation is correct. thats not my question. My 
question is why was it removed as an option when the firewall box itself in 
network manager says "Deny network access except..." 

My point is it is counter intuitive. If it says "deny network access 
exccept..." then there is an expectation that it will deny network access 
except for what is specified. There used to be tick buttons (allow 
updates/allow ICMP/allow DNS), which made it clear on the granular control 
there - but were removed in R4. The underlying subsytems you can still do that, 
sure. 

Can I suggest that the wording "deny network access except..." is changed to 
"Deny TCP and UDP access except ..." for the avoidance of any doubt. 

-- 
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/3ef9e1e3-47f3-4062-adbc-69c5ba5d109d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] why was DNS/ICMP removed from Qubes manager/firewall in R4?

[simon . newton]

In 3, if i clicked on "block connections" in the Qubes manager firewall 
section, there was (if memory serves me) an option to block DNS and ICMP. 

That is not present in R4 (though docs say you can disable DNS and ICMP 
manually)

I'm just wondering what the logic behind the removal was? I would have thought 
that a general user who clicks "block connections" on Qube would not expect the 
qube to be able to actually send out and receive network packets such as DNS or 
ICMP. This presents information leakage scenarios (default DNS lookups of given 
qube) and also potential egress vectors if a qube is ever compromised (DNS 
tunnelling, ICMP tunnelling). 

TIA

-- 
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/8dc8dbdf-251b-47dc-94fb-6aaa04d133ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Does anyone use any integrity checking in Dom0

[simon . newton]

As per subject, does anyone use things such as AIDE (or other file integrity 
IDS) ?

I understand the security model is "if dom0 is compromised, you are fscked" but 
it would be at least nice to have something that gave me a heads up if such an 
event happens.

-- 
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/d932843f-43db-4e5d-b4e5-c754f043f0e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qube max storage size

[simon . newton]

On Monday, January 7, 2019 at 3:03:00 PM UTC, unman wrote:
> On Mon, Jan 07, 2019 at 07:52:25AM -0600, Stuart Perkins wrote:
> > 
> > 
> > On Sun, 6 Jan 2019 07:41:35 -0800 (PST)
> > Plex  wrote:
> > 
> > >On Sunday, January 6, 2019 at 3:20:08 PM UTC, Plex wrote:
> > >> Is there a technical limitation/reason why a qube private max storage 
> > >> size can only go to 1048576MiB in qube manager? Is this a limitation 
> > >> with the qube itself or qube manager?
> > >> 
> > >> TIA  
> > >
> > >I should RTFM
> > >
> > >https://www.qubes-os.org/doc/resize-disk-image/
> > >
> > 
> > but..asking questions introduces the topic to the rest of the mailing list, 
> > and does indeed serve a purpose.  :)
> > 
> 
> And I had assumed you *had* RTFM and it was that that raised the
> question. Why IS there this limitation in the manager?

Hmm good point - its not in the underlying so its likely in the manager code 
itself I would imagine. 

-- 
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/795f9465-c233-41d7-82e8-85db0eada001%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: my dom0 is not updating since before 4.01

[simon . newton]

On Sunday, January 6, 2019 at 1:32:45 PM UTC, Sergio Matta wrote:
> I think I have a problem with yum file configuration. Fedora 25 looks like ok 
> but Qubes never finds data:
> 
> Fedora 25 - x86_64 - Updates 1.0 MB/s |   24 MB   00:24
> Fedora 25 - x86_64   2.0 MB/s |   50 MB   00:25
> Qubes Dom0 Repository (updates)   86  B/s |  169  B   00:01
> Qubes Community Templates repository  84  B/s |  169  B   00:02
> Qubes Templates repository   116  B/s |  169  B   00:01
> Qubes Templates repository   116  B/s |  169  B   00:01
> Failed to synchronize cache for repo 'qubes-dom0-current', ignoring this repo.
> Failed to synchronize cache for repo 'qubes-templates-sommunity', ignoring 
> this
> repo.
> Failed to synchronize cache for repo 'qubes-templates-itl', ignoring this 
> repo.
> Failed to synchronize cache for repo 'qubes-templates-itl-testing', ignoring 
> this repo.
> Last metadata expiration check: 0:00:09 ago on Sun Jan  6 10:12:44 2019.
> Dependencies resolved.
> Nothing to do.
> Complete!
> No packages downloaded

https://github.com/QubesOS/qubes-issues/issues/3737

https://www.qubes-os.org/doc/releases/4.0/release-notes/#upgrading

change your repo from http to https 

-- 
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/c37e3968-c088-4c5f-9467-7e37946f1ec1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.