[qubes-users] Re: Workaround for salt issue 31531

[Emma Borhanian]

Here's my sls code for patching these issues run against dom0 if anyone 
wants it:


# WORKAROUND: https://github.com/saltstack/salt/issues/31531
'patch salt issue 31531':
  cmd.run:
    - name: |
    if [[ ! -f /root/.config/patched-salt-31531 ]]; then
    cat <    sudo sed -i'' "s#if fn_.strip() and fn_.startswith(path):#if 
fn_.strip() and (fn_.startswith(path) or path == '/'):#" 
/usr/lib/python2.7/site-packages/salt/fileclient.py && \
    if ! grep extra-filerefs /etc/qubes-rpc/qubes.SaltLinuxVM 
>/dev/null; then sudo sed -i'' "s#salt-ssh#salt-ssh --extra-filerefs 
salt:///#" /etc/qubes-rpc/qubes.SaltLinuxVM; fi

    CMD
    fi
    sudo mkdir -p /root/.config
    sudo touch /root/.config/patched-salt-31531

# Fix for no error message except "Execute a packaged state run, the 
packaged state run will exist in..."


qubessalt-errors-fix1:
  file.replace:
    - name: /usr/lib/python2.7/site-packages/qubessalt/__init__.py
    - pattern: {{ "(untrusted_stdout, _) = p.communicate" | regex_escape }}
    - repl: '(untrusted_stdout, untrusted_stderr) = p.communicate'

qubessalt-errors-fix2:
  file.replace:
    - name: /usr/lib/python2.7/site-packages/qubessalt/__init__.py
    - pattern: {{ "untrusted_stdout = untrusted_stdout.decode('ascii', 
errors='ignore')" | regex_escape }}$
    - repl: "untrusted_stdout = untrusted_stdout.decode('ascii', 
errors='ignore') + untrusted_stderr.decode('ascii', errors='ignore')"


On 6/11/20 12:24 PM, Emma Borhanian wrote:
Workaround is to patch 
https://github.com/saltstack/salt/issues/31531#issuecomment-615253644


In the template vm from which salt-ssh will be called from via 
qubes-rpc from dom0.


On 6/10/20 9:43 PM, Emma Borhanian wrote:
So I seem to be running into this issue with salt+qubes: 
https://github.com/saltstack/salt/issues/31531


I want to run use a managed file jinja template in a non-dom0 domain.

Does anyone have a workaround?

I think maybe not many people use the salt integration given the 
amount of troubles I've had and inability to find documentation. e.g. 
in an unrelated issue I spend hours debugging before I realized I 
just wasn't getting an error message because Qubes is throwing away 
stderr here:
https://github.com/QubesOS/qubes-mgmt-salt/blob/master/qubessalt/__init__.py#L166 





--
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/ab65754c-f3a3-6591-6c86-acfe6f01e3d5%40gmail.com.

[qubes-users] Re: Workaround for salt issue 31531

[Emma Borhanian]

Workaround is to patch 
https://github.com/saltstack/salt/issues/31531#issuecomment-615253644


In the template vm from which salt-ssh will be called from via qubes-rpc 
from dom0.


On 6/10/20 9:43 PM, Emma Borhanian wrote:
So I seem to be running into this issue with salt+qubes: 
https://github.com/saltstack/salt/issues/31531


I want to run use a managed file jinja template in a non-dom0 domain.

Does anyone have a workaround?

I think maybe not many people use the salt integration given the 
amount of troubles I've had and inability to find documentation. e.g. 
in an unrelated issue I spend hours debugging before I realized I just 
wasn't getting an error message because Qubes is throwing away stderr 
here:
https://github.com/QubesOS/qubes-mgmt-salt/blob/master/qubessalt/__init__.py#L166 





--
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/f8431164-7d7f-1232-6f33-d1cdc9564c23%40gmail.com.

[qubes-users] how to extend/revert root size templtae on the fly?

[0rb via qubes-users]

Hi, Qubes Commnuity!

TASK : rebuild gcc on gentoo template

i need to extend root for gcc compiling (from 10g to 20g)
i need to revert root back (from 20g to 10g, default)
If i use extend/revert next vm start is fails. And template is unusable.

How to do it correctly?

-- 
 

-- 
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/M9ZhQUn--3-2%40tuta.io.

[qubes-users] QSB #057: Special Register Buffer speculative side channel (XSA-320)

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) #057: Special
Register Buffer speculative side channel (XSA-320). 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 #057 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-057-2020.txt

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

https://www.qubes-os.org/security/pack/

View all past QSBs:

https://www.qubes-os.org/security/bulletins/

View XSA-320 in the XSA Tracker:

https://www.qubes-os.org/security/xsa/#320

```


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

 2020-06-11


  Special Register Buffer speculative side channel (XSA-320)

Summary


On 2020-06-09, the Xen Security Team published Xen Security Advisory
320 (CVE-2020-0543 / XSA-320) [1] with the following description:

| This issue is related to the MDS and TAA vulnerabilities.  Please see
| https://xenbits.xen.org/xsa/advisory-297.html (MDS) and
| https://xenbits.xen.org/xsa/advisory-305.html (TAA) for details.
| 
| Certain processor operations microarchitecturally need to read data
| from outside the physical core (e.g. to communicate with the random
| number generator).  In some implementations, this operation is called
| a Special Register Read.
| 
| In some implementations, data are staged in a single shared buffer,
| and a full cache line at a time is returned to the core which made the
| Special Register Read.  On parts vulnerable to MFBDS or TAA, an
| attacker may be able to access stale data requested by other cores in
| the system.
| 
| For more details, see:
| 
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00320.html
| 
| 
| An attacker, which could include a malicious untrusted user process on
| a trusted guest, or an untrusted guest, can sample the contents of
| certain off-core accesses by other cores in the system.
| 
| This can include data whose use may depend on the secrecy of the
| value, such as data from the Random Number Generator (e.g.
| RDRAND/RDSEED instructions).

This is yet another CPU hardware bug related to speculative execution.

Only Intel processors are affected. The RDRAND instruction became
available in Intel processors starting with Ivy Bridge (3rd gen Intel
Core). See Intel's advisory for a full list of affected CPUs. (Short
version: Most mobile/desktop CPUs are affected, while most Atoms and
server Xeons are not.)

Impact
===

An attacker can obtain data returned by RDRAND/RDSEED instructions on
another core on the system (including another VM). In practice, Linux
does use RDRAND/RDSEED to seed its random number generator
(/dev/urandom, getrandom(2) etc.), but RDRAND/RDSEED is not the only
source of entropy. So, as long as other sources of entropy are not
compromised, the overall security of the random number generator is
still preserved. In Qubes OS, the situation is further improved by
seeding the random number generator at VM startup using a random seed
provided from dom0. This means that using Linux's random number
generator is still safe in Qubes.

Aside from the Linux kernel using RDRAND/RDSEED as one of its entropy
sources, userspace applications can also issue RDRAND/RDSEED
instructions on their own. Such software is also affected by the bug
described here. The specific impact on such software depends on what the
application does with the random data obtained in this manner.

Patching
=

Intel has provided a microcode update that mitigates the issue. Please
note that Ivy Bridge processors are considered retired by Intel and no
longer receive microcode updates. This means that Ivy Bridge processors
will remain vulnerable to this issue. To mitigate the problem, we are
masking out RDRAND availability to VMs on those affected platforms.

The specific packages that resolve the problems discussed in this
bulletin are as follows:

  For Qubes 4.0:
  - microcode_ctl 2.1-30.qubes1
  - qubes-core-dom0 4.0.51 (needed for Ivy Bridge platforms only)

The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:

  For updates from the stable repository (not immediately available):
  $ sudo qubes-dom0-update

  For updates from the security-testing repository:
  $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing

A system restart will be required afterwards.

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.

If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
microcode binaries.

Credits


See the original Xen Security Advisory.

References
===

[1] htt

[qubes-users] Ho to do a fully automatic 4.0.3 installation

[didier . pelligra]

Hi,

I've been playing around for a while now with Qubes R4.0.3 and while i 
managed to start the installation from a PXE server and with a kickstart 
file, I cant get the installation to be fully automatic.

I followed mainly this page :
https://github.com/Qubes-Community/Contents/blob/master/docs/hardware/Autonomous%20Qubes-install%20(kickstart).md

A few problems i'm running into :
- In the ks.cfg file i ca'nt find how to specify an encrypted LUKS 
passphrase, for now i have to put it in clear text
- The installation first stage won't reboot automatically after the files 
copy and installation
- I can't automate the first boot configuration (which I need to do the 
default settings, no change needed)

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4af005c0-9d30-4cf3-b6ae-f86293513e29o%40googlegroups.com.

Re: [qubes-users] What Intrusion Detection system should I use?

[Peter Funk]

Hello Joo,

Joo Nasss schrieb am Mittwoch, den 10.06.2020 um 13:39:
> What Intrusion Detection system should I use?
> 
> And what Kind of Network IDS is good?
> 
> https://en.m.wikipedia.org/wiki/Intrusion_detection_system

A similar question has been asked in qubes-users before in 2016:
https://groups.google.com/forum/#!topic/qubes-users/Rqod1Mcf_ws

Before I started to migrate to QubesOS I have used the host based IDS
https://www.la-samhna.de/samhain/index.html on Debian and
other systems.  But I did not tried it in QubesOS yet.

Best regards, Peter Funk
-- 
Peter Funk ✉:Oldenburger Str.86, 2 Ganderkesee, Germany; 📱:+49-179-640-8878 
✉office: ArtCom GmbH, Haferwende 2, D-28357 Bremen, Germany
☎office:+49-421-20419-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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200611143121.GB30712%40pfmaster-P170EM.

Re: [qubes-users] Dell Latitude E5470 running Qubes 4.0.3 - no web cam...

[Andrew Sullivan]

On Tuesday, 9 June 2020 13:13:52 UTC+1, haaber wrote:
>
> On 6/9/20 2:07 PM, Andrew Sullivan wrote: 
> > As per the Subject, I have installed 4.0.3 on my Latitude E5470. 
> > Everything seems to work, except the webcam.  If I fire up Cheese, it 
> > just says "No device found". The camera works fine in Windows 10 and 
> > Linux Mint.  Running lsusb in a Dom0 terminal shows the following entry: 
> > 
> > Bus 001 Device 002: ID 1bcf:28b8 Sunplus Innovation Technology Inc. 
> > 
> > So Qubes can sort of see it.  What am I missing? 
>
> You use sys-usb (->make sure it is started, otherwise you don not see 
> usb devices). Since you see your cam, I presume that is OK. 
> Then you only need to attach the webcam to your cheese-running VM !! Use 
> the widget on right top corner of your screen for that. 
>

Well, you were both correct, I am missing sys-usb.  I also now know one way 
to break a Qubes installation!  In the absence of this being installed at 
the start, I attempted to do it manually, as per the Documentation.  The 
qube got created OK, but when I went to open it the whole system froze...  
I did a "hard" powerdown and tried to restart; wasn't asked for a 
passphrase to decrypt the system and eventually I got a lot of 
incomprehensible (to me) messages.  Time for a re-install (not a big deal, 
I'm still learning Qubes rather than using it for real).  I then noticed 
that the option to create sys-usb was greyed out, because I was installing 
to a USB flash drive (and have a wireless USB mouse) so that's one mystery 
solved.  All more-or-less working again, and I have a "proper" SSD on order.

Thanks again for your help.

Andrew

-- 
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/cb3bdd9f-9004-423e-a518-e86ea564a00co%40googlegroups.com.

Re: [qubes-users] How to add multiple virtual hard drive to a StandaloneHVM

[dhorf-hfref . 4a288f10]

On Wed, Jun 10, 2020 at 10:28:22PM -0700, ramboman...@gmail.com wrote:

please dont top-post here.

> The reason I was specifying virtual hard drives and not partitions, is 
... 
> functionalities it offers, I am trying to reproduce a virtual file server 
> containing many hard drives so I can play around with different layouts and 
> learn from it.

for the purpose of "learning zfs" it should not matter where the block
devices come from. 
anything from physical devices, partitions, logical volumes or even 
loopbacks should be the same for most practical purposes.


> In VirtualBox, it is fairly straightforward to add new virtual hard drives 
> to a VM when needed. I'm trying to do the same thing for a StandaloneHVM, 
> but I have not found how to do that yet.

just add them with qvm-block (or the device widget).

if the actual question is how to create/manage devices under linux,
consult the manpages for "losetup" and/or "lvcreate" and/or "fdisk".



-- 
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/20200611091809.GA998%40priv-mua.