Re: [qubes-users] Re: A worrisome threat? Kinda...

[Alex]

On 08/29/2017 11:02 PM, Sandy Harris wrote:
> As I probably should have known, Qubes developers are already well
> aware of this. See for example:
> https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf
Exactly.

To give a little more context:
 * Intel ME is a totally independent, totally opaque (officially at
least) stand-alone computer system attached to any recent x86/x86_64
chipset (reminds me of the Cordyceps "zombie fungi" family)
 * It is able to reach various devices deemed "dangerous" in a computer
system (network adapters, ram, input devices) in a way that is both
unnoticeable and uncontrolled by the host system
 * The software it runs can only be updated as a blob by customers, but
is signed and encrypted by Intel, so no insight nor customization is
available beyond some simple "variable-setting" tool
 * While it may be useful for remote/centralized
provisioning/maintenance of large corporate networks (citation needed,
perhaps), it has quickly grown very large and complex (hence, linearly
buggier)
 * The latest versions of ME are absolutely necessary for Intel-based
chipsets to perform basic boot functions (power management, initializations)
 * The dangers of this tool fall into two categories: intentional remote
administration backdoors and unintentional exploitable bugs, both of
which cannot be checked for nor ruled out without considerable effort in
accessing the software (which has already been, partially, done - but
yet, I don't expect anyone decapping a south bridge chip any time soon!)
 * The worst part is that this remote administration engine is
pre-installed into and (as of the latest versions) un-removable from any
recent Intel-chipset-based motherboard, even consumer-grade ones or
mobile-oriented ones (low cost tablets that are extremely unlikely to be
used by large corporations), prompting the question "is it really about
central administration/maintenance for corporate users?"


Because of this context it is usually regarded as a necessary evil, but
any security-minded Intel customer will try its best to disable as much
ME functionality as he/she can, hence the research that produced the
paper you linked to in your first post.

Please also note that any remote administration command can only be
received through networking, so proper firewalling (ipv6 may complicate
things - prepare your studies in advance) and monitoring may help great
lengths. Also, do avoid using x86-based firewalls/routers... ;)

-- 
Alex

-- 
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/c3bcfc1a-15b9-54ab-69e3-4dd98d3d4de7%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

[qubes-users] Qubes 4.0rc1 Bug: adding programs to the VM's quickstart menu not functioning

[cyberian]

[MyHVM] > VM Settings > Applications  no longer will add selected applications 
to the dom0 VM drop down menu in Qubes 4.0

Expected: going into VM preferences and choosing programs to appear in the 
Qubes drop down menu for selected VM should cause the applications to be added 
to the quickstart tray

Result:  selected applications are not added to the quickstart tray.  Reboot 
does not resolve.

-- 
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/82533be2-5869-4f85-9940-d7e20fad286a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 4.0rc1 - Resize HVM disk size

[cyberian]

Solved:

Resizing disks is now done in GUI from the Qubes drop-down menu in dom0 under 
[MyHVM] > VM Settings

-- 
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/a8e3401d-98c3-452f-b2c8-8275ae6061f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Options for securing /boot

[Steve Coleman]

If your laptop contains an active TPM and a TCG Opal 2.0 compliant SED 
(SSD or spinning platter) drive, then you can create a range, install 
the bootstrap/OS, and then mark that range as read-only.


After doing that *nothing* will be able to write to that area without 
the password unlocking that range first, even Dom0 root user, but then 
it will also need to be unlocked using that same password at the 
appropriate moment during any update to the bootstrap/Xen code during 
appropriate Dom0 updates. This same range can also protect the partition 
table, MBR, and boot menu, etc. Multiple ranges can be set with 
different attributes/encryption keys.


The tool you would need for doing this is "msed" (name given in my 
fedora distro) or "sedutil" (from the drive trust alliance) which allows 
you to talk to the drive via sata (not usb afaik) to encrypt or protect 
defined ranges that you set up.


Just be careful to learn/test on a test system, because if you create an 
encrypted range everything previously there disappears instantly, 
including partitions. Its the world fastest way I know to completely 
wipe a drive, flip one bit in the key, poof. Like magic. You can always 
reset back to the factory default erasing everything on the drive.


Calculate your ranges, partition, setup encryption ranges, and install 
stuff, then finally mark your /boot range as read-only. Don't encrypt 
your /boot or you will need to install Pre-Boot-Authentication (PBA) and 
supply a password at boot time.


Sedutil source and docs
https://github.com/Drive-Trust-Alliance


On 08/26/2017 11:39 AM, cyberian@national.shitposting.agency wrote:

Does Qubes offer a method of securing /boot? not just against USB evil maid 
attacks, but from tampering in general?

for example, while a laptop is off, what would stop a malicious user from live 
booting to an arbitrary distro and altering kernel or xen images located on the 
unencrypted /boot partition?

Does qubes offer options for encrypting /boot?



--
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/85467fc2-f40d-163d-1be2-e79604b1430d%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] qvm-block doesn't list/expose dom0 loop devices

[nicholas roveda]

I'm using R4.0 rc1.

I wanted to install a Linux distro inside a disk image located in dom0 home, 
using QEMU in an AppVM.

I've created a new disk image in dom0, set it up (dos partition label and a 
primary ext4 partition) and attached it with `kpartx` to loopX, but `qvm-block` 
doesn't list it in the exposed block devices.

So, in order to understand better how Qubes handles this, I've tried to do the 
same in a VM and see if the dom0 would catch the event, but nothing.
Strangely, when I detached the disk image, both the 'AppVM:loopX - IMG_PATH is 
available' and 'AppVM:loopX - IMG_PATH is removed' notifications appeared on 
the screen.

I've read a lot about it, but I think what I found was all related to a < R4.0 
version, so I don't know if this issue is related to a intended design or a bug.



Procedure:
[user@dom0 ~]$ dd if=/dev/zero of=/home/user/table.raw bs=2048 count=1
[user@dom0 ~]$ dd if=/dev/zero of=/home/user/root.raw  bs=3GB  count=1
[user@dom0 ~]$ mkfs.ext4 /home/user/root.raw
[user@dom0 ~]$ cat /home/user/{table,root}.raw > /home/user/root.img
[user@dom0 ~]$ rm /home/user/{table,root}.raw
[user@dom0 ~]$ truncate -s 3GB /home/user/root.img
[user@dom0 ~]$ fdisk /home/user/root.img
   o  new DOS partition table
   n  new partition
   p  primary
   1  first
   2048   first sector
   \n to the end
[user@dom0 ~] fdisk -l /home/user/root.img
Disk /home/user/root.img: 2.8 GiB, 30 bytes, 5859375 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xda159b44

Device Boot Start End Sectors  Size Id Type
root.img12048 5859374 5857327  2.8G 83 Linux

[user@dom0 ~] sudo kpartx -a /home/user/root.img
[user@dom0 ~] losetup -l
NAMESIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE   
DIO
/dev/loop40 0  0 0  0 /home/user/root.img
  0
[user@dom0 ~] ls /dev/mapper
control loop40p1 ...

-- 
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/35f29cb8-e8d6-4cba-8cc0-ea02517eee46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] qvm-block doesn't list dom0 loop devices

[nicholas roveda]

I'm using R4.0 rc1.

I wanted to install a Linux distro inside a disk image located in dom0 home, 
using QEMU in an AppVM.

I've created a new disk image in dom0, set it up (dos partition label and a 
primary ext4 partition) and attached with `kpartx` to loopX, but `qvm-block` 
doesn't list in the exposed block devices.

So, in order to understand better how this thing is handled by Qubes, I've 
tried to do the same in a VM and see if the dom0 would catch the event, but 
nothing.
Strangely, when I detached the disk image, both the 'AppVM:loopX - IMG_PATH is 
available' and 'AppVM:loopX - IMG_PATH is removed' notifications appeared on 
the screen.

I've read a lot about it, but I think what I found was all related to a < R4.0 
version, so I don't know if this issue is related to a intended design or a bug.



Procedure:
[user@dom0 ~]$ dd if=/dev/zero of=/home/user/table.raw bs=2048 count=1
[user@dom0 ~]$ dd if=/dev/zero of=/home/user/root.raw  bs=3GB  count=1
[user@dom0 ~]$ mkfs.ext4 /home/user/root.raw
[user@dom0 ~]$ cat /home/user/{table,root}.raw > /home/user/root.img
[user@dom0 ~]$ rm /home/user/{table,root}.raw
[user@dom0 ~]$ truncate -s 3GB /home/user/root.img
[user@dom0 ~]$ fdisk /home/user/root.img
   o  new DOS partition table
   n  new partition
   p  primary
   1  first
   2048   first sector
   \n to the end
[user@dom0 ~] fdisk -l /home/user/root.img
Disk /home/user/root.img: 2.8 GiB, 30 bytes, 5859375 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xda159b44

Device Boot Start End Sectors  Size Id Type
root.img12048 5859374 5857327  2.8G 83 Linux

[user@dom0 ~] sudo kpartx -a /home/user/root.img
[user@dom0 ~] losetup -l
NAMESIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE   
DIO
/dev/loop40 0  0 0  0 /home/user/root.img
  0
[user@dom0 ~] ls /dev/mapper
control loop40p1 ...

-- 
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/52961c52-1745-4799-8c29-592853d02953%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 4.0rc1 - Resize HVM disk size

[cyberian]

Just wanted to bump this.

How are HVM disks resized on Qubes 4.0rc1?

-- 
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/ff067ee7-8928-42c9-907c-d75198a64da3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: A worrisome threat?

[Sandy Harris]

As I probably should have known, Qubes developers are already well
aware of this. See for example:
https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf

-- 
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/CACXcFmnXu8uW0p%2BrQFVcMAgr7qYdp-DKFATGPE3TOdzQkwtuVw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] A worrisome threat?

[Sandy Harris]

Does Qubes block this? If not, should it? In either case, how?

-- Forwarded message --
From: Henry Baker 
Date: Tue, Aug 29, 2017 at 7:51 AM
Subject: Re: [Cryptography] How to find hidden/undocumented instructions
To: cryptogra...@metzdowd.com

FYI --

http://blog.ptsecurity.com/2017/08/disabling-intel-me.html

https://www.theregister.co.uk/2017/08/29/intel_management_engine_can_be_disabled/

Intel ME controller chip has secret kill switch

Researchers find undocumented accommodation for government customers

By Thomas Claburn in San Francisco 29 Aug 2017 at 00:12

Security researchers at Moscow-based Positive Technologies have
identified an undocumented configuration setting that disables Intel
Management Engine 11, a CPU control mechanism that has been described
as a security risk.

Intel's ME consists of a microcontroller that works with the Platform
Controller Hub chip, in conjunction with integrated peripherals.  It
handles much of the data travelling between the processor and external
devices, and thus has access to most of the data on the host computer.

If compromised, it becomes a backdoor, giving an attacker control over
the affected device.

That possibility set off alarms in May, with the disclosure of a
vulnerabilityin Intel's Active Management Technology, a firmware
application that runs on the Intel ME.

The revelation prompted calls for a way to disable the poorly
understood hardware.  At the time, the Electronic Frontier Foundation
called it a security hazard.  The tech advocacy group demanded a way
to disable "the undocumented master controller inside our Intel chips"
and details about how the technology works.

An unofficial workaround called ME Cleaner can partially hobble the
technology, but cannot fully eliminate it.  "Intel ME is an
irremovable environment with an obscure signed proprietary firmware,
with full network and memory access, which poses a serious security
threat," the project explains.

On Monday, Positive Technologies researchers Dmitry Sklyarov, Mark
Ermolov, and Maxim Goryachy said they had found a way to turn off the
Intel ME by setting the undocumented HAP bit to 1 in a configuration
file.

HAP stands for high assurance platform.  It's an IT security framework
developed by the US National Security Agency, an organization that
might want a way to disable a feature on Intel chips that presents a
security risk.

The Register asked Intel about this and received the same emailed
statement that was provided to Positive Technologies.

"In response to requests from customers with specialized requirements
we sometimes explore the modification or disabling of certain
features," Intel's spokesperson said.  "In this case, the
modifications were made at the request of equipment manufacturers in
support of their customer's evaluation of the US government's 'High
Assurance Platform' program.  These modifications underwent a limited
validation cycle and are not an officially supported configuration."

Positive Technologies in its blog post acknowledged that it would be
typical for government agencies to want to reduce the possibility of
unauthorized access.  It noted that HAP's affect on Boot Guard,
Intel's boot process verification system, remains unknown, though it
hopes to answer that question soon.

___
The cryptography mailing list
cryptogra...@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

-- 
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/CACXcFmnPK8t38C68o3cETV9aT4gbb0RDa30fVrwYUF6B%2Bra%3Dpw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: python3-dnf-plugins-qubes-hooks-3.2.18-1.fc23.x86_64: checksum doesn't match

[Pete Howell]

I switched to the new FC25 template and now get a checksum doesn't match on 
xen-libs-4.6.6-29.fc25.x86_64.

Anyone have any ideas?

On Wednesday, August 23, 2017 at 2:35:29 PM UTC-6, Pete Howell wrote:
> Running a fresh install of Qubes-R3.2, and when doing an FC23 update, all the 
> packages download until you get to 
> python3-dnf-plugins-qubes-hooks-3.2.18-1.fc23.x86_64, which fails with a 
> checksum doesn't match error.

-- 
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/07f8231d-49c4-4d89-a7fd-f21d5d4ed31e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HOWTO: Compiling Kernels for dom0

[Yethal]

W dniu niedziela, 13 sierpnia 2017 14:17:33 UTC+2 użytkownik Epitre napisał:
> Le dimanche 13 août 2017 09:41:53 UTC+2, Foppe de Haan a écrit :
> > On Sunday, August 13, 2017 at 9:38:06 AM UTC+2, Epitre wrote:
> > > Le dimanche 13 août 2017 09:19:25 UTC+2, Epitre a écrit :
> > > > Le dimanche 13 août 2017 07:24:29 UTC+2, Foppe de Haan a écrit :
> > > > > For any newcomers: can you tell me if this covers all the bases? 
> > > > > https://github.com/0spinboson/qubes-doc/blob/patch-1/managing-os/compiling-your-own-kernel.md
> > > > > (or if not, what's missing?)
> > > > 
> > > > Hi,
> > > > 
> > > > It seems right for me. Just a a comment for the version in devel-4.11, 
> > > > the last working version (at least for me, and need to be confirmed) is 
> > > > 4.11.8:
> > > > 
> > > > The 4.11.12 has a Xen bug which has to be fixed and prevent Xen to work.
> > > > The 4.12.5 has also the same bug but need to have also 3 patches 
> > > > updated.
> > > > 
> > > > In both cases, qubes-core status:
> > > > 
> > > > août 11 21:37:07 dom0 startup-misc.sh[2712]: xenstore-write: xs_open: 
> > > > No such file or directory
> > > > août 11 21:37:07 dom0 startup-misc.sh[2712]: xenstore-write: xs_open: 
> > > > No such file or directory
> > > > août 11 21:37:07 dom0 startup-misc.sh[2712]: xc: error: Could not 
> > > > obtain handle on privileged command interface (2 = No such file or 
> > > > directory): Internal error
> > > > août 11 21:37:07 dom0 startup-misc.sh[2712]: libxl: error: 
> > > > libxl.c:116:libxl_ctx_alloc: cannot open libxc handle: No such file or 
> > > > directory
> > > > août 11 21:37:07 dom0 startup-misc.sh[2712]: cannot init xl context
> > > > 
> > > > I will dig more into the problem in the next week but if someone would 
> > > > like to test to confirm or not, it would help.
> > > > 
> > > > Moreover, for those who have problem with NOUVEAU driver (see my first 
> > > > post asking help: 
> > > > https://groups.google.com/d/msg/qubes-devel/koDHzHJICEs/M5B19MBgCgAJ) 
> > > > and their GTX970 with 4G of VRAM, I patched the qubes kernel 
> > > > (https://github.com/fepitre/qubes-linux-kernel) for version 4.9 and 
> > > > 4.11. The major problem is in the computation of VRAM which has been 
> > > > completely remade and solved in kernel 4.12.
> > > 
> > > Sorry for the quick updates but writing the message it came to mind that 
> > > it would maybe something related to Grub...and yes...I boot the my dev 
> > > machine and I don't know why but the grub conf was badly updated...
> > > 
> > > I can confirm that the lastest working version is 4.11.12. I will also 
> > > update properly my repo for the patches in devel-4.12.
> > 
> > np. I had a look, but didn't see any error messages akin to yours (running 
> > 4.11.12). 4.12.6 indeed only built for me if I disabled 3 kernel patches, 1 
> > related to xsa155.
> 
> Now building and running properly kernel-4.12 is ok. I pushed on my 
> devel-4.12 branch the updated 3 kernel patches who failed at first instance 
> (rewrite in the kernel sources to obtain properly updated lines).
> 
> We can now go on the next releases (especially if someone like has Ryzen or 
> Kaby Lake CPU or latest NVIDIA cards).

Something weird is happening whenever I try to compile this kernel. I have two 
config files (config and .config) in qubes-kernel-linux directory and two 
config files (config and .config) in linux-kernel-* directory, all of them with 
the same settings but whenever I run make rpms make ignores those config files 
and uses a stock one

-- 
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/811ca328-b07b-4c28-aade-c10381977fd2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Options for securing /boot

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/29/2017 07:38 PM, David Hobach wrote:
> On 08/29/2017 06:32 PM, cooloutac wrote:
>> On Tuesday, August 29, 2017 at 12:25:51 PM UTC-4, cooloutac
>> wrote:
>>> On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik Hagara
>>> wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 On 08/29/2017 04:50 PM, cyberian@national.shitposting.agency
 wrote:
> Leo Gaspard,
> 
> I have read about AEM but have never used it, it seems like
> it is geared towards protecting from USB's with malicious
> firmware on them.
> 
> Does AEM actually verify the integrity of /boot before
> using?  This is what I am looking for, either a method of
> encrypting /boot or even better, a secure method to verify
> its integrity during boot
> 
 
 AEM does verify the integrity of /boot using the TPM
 seal/unseal operation. If any of the boot components change,
 AEM falls back to regular, unmeasured boot -- the user is
 expected to notice this and cease using the
 potentially-compromised system (the lack of explicit 
 indication of failed AEM boot is deliberate, see the last FAQ
 item at [1]).
 
 The security provided by AEM is much more stronger than
 encrypted /boot could ever offer, because as already pointed
 out, there is always a little first-stage bootloader stub on
 the disk unencrypted and it would be easy to overwrite it
 with a malicious version that would intercept the encryption
 passphrase and exfiltrate it using eg. unused disk sectors.
 
 If someone did the above with AEM, the TPM would refuse to
 useal the AEM secret as the platform state would be
 different.
> 
> You still have to trust the TPM manufacturer, some closed source
> Intel blob and some ITL code, i.e. I'd definitely test changes to
> /boot & your BIOS to cause the TPM to deny revealing the secret if
> I had to rely on it - the cheapest implementation is an
> "everything's ok" on every request after all...

Well, of course. You always have to trust *something*.

The ultimate goal is to reduce the trusted code base to bare minimum
and provide methods for end-users to verify that the code running
actually *is* the one advertised by vendor (eg. ITL).

> So the strongest method remains OpSec & physical security. This can
> also prevent things.

Layered security is the best approach, yes.

> Moreover the fewest people tend to buy new hardware once they
> detect a change via their TPM even though that would be the only
> reasonable reaction. So if you don't plan to do that, I'd forget
> about AEM.

Reasonable reaction always depends on the sophistication level of
adversary you're trying to defend against (ie. your defense "budget").
Nation states? Burn the laptop. Opportunistic black-hats? You'll be
fine simply reinstalling.


Cheers,
Patrik
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZpakTAAoJEFwecd8DH5rl1ewP/1Ewz/i4wEEAUizlgDzstwlf
41/2PVh6bvhzb+QhK95O7UxtbHhqFF4NttrkAzlQw7Uwsi/l6i0tRuvAZu7tLTqw
KfaQj2F2lGm3GVSNwhuVH2NcZaZ5U3FpBk4/PcP/ONBoLp0blxlIbEvfEfScP9Ly
xW1T7sbINqS76qKh42ds9hf8FYrN8vrHMxRYfLZAlmXNZvTIvMpF1YwiZyHiDdrQ
vprfXU9dPHEjUN63f22G+CaDCYYXdk/Pb7QDAbA0YuN1tQyxgkgZMB2Ks37A0UD7
vDQBiM91ynU703QOVDr8Icn0otshv/RR+GFxfJPugA+3YUjYN+dOY5c1qAaM4bVZ
QoCoe2ApFpEt2HCKq5grm1cge6LEK+d4ym6sjB9PoL4/T4FMq2fnO6s+xoIlvWZZ
1FmQVJtTEmuiaMOHtwxLaM80sD6s/9cq/w7fIMlba86uFlesNOgpkDfm9SoYtQYc
94RT6CAd7CyThn+lhTH3YGNrt320cP/fFPTp4gjHQOf9su7vjtrN7tKVD6o6bD1n
PlbRqw40SQRovtTSR5UPJEMlqbScC91aeL/glDXNuXEcz+Jz+YvmHiAi/UCz79k9
XwEc/2wjD5xMw+hmajaXNQOOnUA5VRNJNLuPBOxrZxxBpZef7SV0lcf5WqDkdhq9
QA8qanASHTTQo3y5r9JA
=cZ7m
-END PGP SIGNATURE-

-- 
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/37ed7d3f-921e-8cac-adb0-df3e0c1897cd%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


0x031F9AE5.asc
Description: application/pgp-keys


0x031F9AE5.asc.sig
Description: PGP signature

Re: [qubes-users] Options for securing /boot

[David Hobach]

On 08/29/2017 06:32 PM, cooloutac wrote:

On Tuesday, August 29, 2017 at 12:25:51 PM UTC-4, cooloutac wrote:

On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik Hagara wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/29/2017 04:50 PM, cyberian@national.shitposting.agency wrote:

Leo Gaspard,

I have read about AEM but have never used it, it seems like it is
geared towards protecting from USB's with malicious firmware on
them.

Does AEM actually verify the integrity of /boot before using?  This
is what I am looking for, either a method of encrypting /boot or
even better, a secure method to verify its integrity during boot



AEM does verify the integrity of /boot using the TPM seal/unseal
operation. If any of the boot components change, AEM falls back to
regular, unmeasured boot -- the user is expected to notice this and
cease using the potentially-compromised system (the lack of explicit
indication of failed AEM boot is deliberate, see the last FAQ item at
[1]).

The security provided by AEM is much more stronger than encrypted
/boot could ever offer, because as already pointed out, there is
always a little first-stage bootloader stub on the disk unencrypted
and it would be easy to overwrite it with a malicious version that
would intercept the encryption passphrase and exfiltrate it using eg.
unused disk sectors.

If someone did the above with AEM, the TPM would refuse to useal the
AEM secret as the platform state would be different.


You still have to trust the TPM manufacturer, some closed source Intel 
blob and some ITL code, i.e. I'd definitely test changes to /boot & your 
BIOS to cause the TPM to deny revealing the secret if I had to rely on 
it - the cheapest implementation is an "everything's ok" on every 
request after all...


So the strongest method remains OpSec & physical security. This can also 
prevent things.


Moreover the fewest people tend to buy new hardware once they detect a 
change via their TPM even though that would be the only reasonable 
reaction. So if you don't plan to do that, I'd forget about AEM.


--
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/e6756da2-fc92-085c-b3ee-df45a2ed1379%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Options for securing /boot

[Leo Gaspard]

On 08/29/2017 04:01 PM, cooloutac wrote:
> On Monday, August 28, 2017 at 6:36:08 PM UTC-4, Leo Gaspard wrote:
>> Just encrypting /boot would bring little, as it would still be possible
>> to modify the unencrypted part of GRUB (that decrypts /boot) to have it
>> overwrite the /boot with malicious kernel images (or even to not use the
>> ones provided).
>>
>> The options I know of are (from IMO strongest to weakest):
>>  * AEM, for knowing when someone tampered with /boot
>>  * SecureBoot, for restricting the allowed-to-boot images (I don't know
>> about its ease of use with qubes, though)
>>  * locking your bootloader with a password and disallow external boot
>>
>> I'd think having all these protections at the same time would be best,
>> using secureboot mostly to avoid having to ditch the laptop after AEM
>> says it's no longer trustworthy (because it may stop the attacker before
>> it can even make the laptop no longer trustworthy).
> 
> secureboot can do more then restricting boot images,  it can restrict 
> unsigned drivers too.  Thats the part Joanna doesn't like because she does 
> not trust who will maintain the list of signed drivers.  I say I'm already 
> putting just as much trust into alot of other things like my banks ssl cert 
> when connecting to my bank account.
> 
> We are already trusting everything coming from upstream when we update...

Well it can, but the issue with secureboot I remember reading about in
the AEM post [1] is that it assumes no security vulnerability in all the
bootchain (which could be used to trick eg. grub to run another image
than the one you expect it to), while AEM only assumes no security
vulnerability in the TPM.

That's why I was putting secureboot forward only as a limited way to
prevent malicious modifications, in parallel with AEM, that would still
be used as a more secure way of checking secureboot worked correctly.

[1] https://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.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 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/7f3bc3ea-d715-5630-bdd5-8eb1d1047086%40gaspard.io.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Options for securing /boot

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/29/2017 06:25 PM, cooloutac wrote:
> On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik Hagara 
> wrote: On 08/29/2017 04:50 PM, cyberian@national.shitposting.agency
> wrote:
 Leo Gaspard,
 
 I have read about AEM but have never used it, it seems like 
 it is geared towards protecting from USB's with malicious 
 firmware on them.
 
 Does AEM actually verify the integrity of /boot before using?
 This is what I am looking for, either a method of encrypting
 /boot or even better, a secure method to verify its integrity
 during boot
 
> 
> AEM does verify the integrity of /boot using the TPM seal/unseal 
> operation. If any of the boot components change, AEM falls back to 
> regular, unmeasured boot -- the user is expected to notice this and
> cease using the potentially-compromised system (the lack of 
> explicit indication of failed AEM boot is deliberate, see the last
>  FAQ item at [1]).
> 
> The security provided by AEM is much more stronger than encrypted 
> /boot could ever offer, because as already pointed out, there is 
> always a little first-stage bootloader stub on the disk
> unencrypted and it would be easy to overwrite it with a malicious
> version that would intercept the encryption passphrase and
> exfiltrate it using eg. unused disk sectors.
> 
> If someone did the above with AEM, the TPM would refuse to useal 
> the AEM secret as the platform state would be different.
> 
> The feature protecting dom0 from malicious USB devices [2] serves
> a different purpose and is not related to AEM. Plus, you always
> need to disconnect all untrusted USB devices while rebooting Qubes,
>  regardless of whether you have USB qube set up or not.
> 
> 
> Cheers, Patrik
> 
> 
> [1]
> https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html [2]
> https://www.qubes-os.org/doc/usb/
> 
> my problem is unfortunately i can't keep buying new pc's. SO maybe
>  its all for naught for me.. Also AEM does not seem as reliable as
>  secureboot. Alot of issues on threads with some people. It seems 
> complicated. even false alarms. But I really do think they are 
> supposed to compliment each other.  trusted boot and measured boot
>  yes? AEM definitely comes in handy for people who would find it 
> nescessary to buy new equipment.

Well, it depends... If you can be reasonably sure that the attacker
did not modify any firmware (eg. the network card), you could simply
reinstall Qubes from a trusted install media and restore VMs from a
backup. This becomes trivial once stateless computers [1] are a thing.

> But I would still want an encrypted boot, if I was going to use 
> aem,  and key on a external usb disk,  which unfortunately means I
>  could not use a sys-usb.  Am I wrong about this?  Does this change
>  in 4.0?

It is possible to use AEM along with USB qube, you just have to
disable the early hiding of USB devices from dom0. But once Qubes is
fully booted and sys-usb started, you get the full USB qubes protecion.

> So this is where the what fits into you "security model"   What are
> you more concered about. I assumed we had to choose between aem vs
> sys-usb?  For people travelling with laptops in strange places 
> where physical compromise is more likely aem is a good option.
> Some people would prolly not just buy a new laptop but know when to
>  destroy theirs too lol.

The only trade-off for AEM regarding USB devices is that the USB stick
you buy to install AEM on could be compromised already (straight from
the factory, or intercepted & infected during shipping). And since you
need to plug it directly into dom0 in order to perform the install, it
could exploit USB or filesystem drivers and gain control of dom0.

So it is kind of a trust-on-first-use scenario for the installation
step only.


Cheers,
Patrik


[1] https://blog.invisiblethings.org/papers/2015/state_harmful.pdf
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZpZpBAAoJEFwecd8DH5rlE4gP/3WFFUmqb8ChECEgfgKeDRlz
VdLWPVuG8mnIr8SWeSCbkmgTA4fz1F6BWCv4puTDpADMc/HyXzrxkl6hxPBnSgdb
Rr01lGXkAda0EcSkhEUcuViCTed+yMf2y7gSJdJJrFnWiomeNft3Bq4KlpqA3t86
r9oofbkH161bGsED8NdTlLFz+uE68gZq7D/ba+xWWJnBM/YT/lWdI29wwZhoJgPn
x6sm4BNE5szbBOwFfV5JXAtCQ8E9K4bF0M8Frvh7DUAa3MsZim3iOmgmavo86Mbm
hLkjN/N4ujxKd3n6YZuA4tqgx4UOxpQWET8jHTMxgHuVd2Dwt6jpl7Uic+3PXoXt
zmoj4BLLhC3vY+8ghPEY7TYNViYCAmAe2LcrNxI4nfUxihLvttR9Nnfut6ENqvDj
oIxRDiDRCWA/ZyC7I9C1ZPiFZ1Jyzy34aFfVF6YCESSvnfI+xGn7XFs+EpVunmiA
jnSxQJTK2Y5Pqh8SLWuMGNPEGr7MF/ekKmIlepn372ftL++2D04kuHvKzn9ZQdun
rC3v7yGuFHHca6Cakj4ks9q4cZ012g2Ch6hE2S8WcTZkEbeequMNEtGYT+9BuWpr
GlLmg5EffaMBxKP6WZuiv6okXyJnVCdBctpxC3qmTeRX4pTn4eaQsr4iXbCkfRnV
ODlfYMpurBuNhFfuwiSw
=ANmo
-END PGP SIGNATURE-

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

Re: [qubes-users] Options for securing /boot

[cooloutac]

On Tuesday, August 29, 2017 at 12:25:51 PM UTC-4, cooloutac wrote:
> On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik Hagara wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > On 08/29/2017 04:50 PM, cyberian@national.shitposting.agency wrote:
> > > Leo Gaspard,
> > > 
> > > I have read about AEM but have never used it, it seems like it is
> > > geared towards protecting from USB's with malicious firmware on
> > > them.
> > > 
> > > Does AEM actually verify the integrity of /boot before using?  This
> > > is what I am looking for, either a method of encrypting /boot or
> > > even better, a secure method to verify its integrity during boot
> > > 
> > 
> > AEM does verify the integrity of /boot using the TPM seal/unseal
> > operation. If any of the boot components change, AEM falls back to
> > regular, unmeasured boot -- the user is expected to notice this and
> > cease using the potentially-compromised system (the lack of explicit
> > indication of failed AEM boot is deliberate, see the last FAQ item at
> > [1]).
> > 
> > The security provided by AEM is much more stronger than encrypted
> > /boot could ever offer, because as already pointed out, there is
> > always a little first-stage bootloader stub on the disk unencrypted
> > and it would be easy to overwrite it with a malicious version that
> > would intercept the encryption passphrase and exfiltrate it using eg.
> > unused disk sectors.
> > 
> > If someone did the above with AEM, the TPM would refuse to useal the
> > AEM secret as the platform state would be different.
> > 
> > The feature protecting dom0 from malicious USB devices [2] serves a
> > different purpose and is not related to AEM. Plus, you always need to
> > disconnect all untrusted USB devices while rebooting Qubes, regardless
> > of whether you have USB qube set up or not.
> > 
> > 
> > Cheers,
> > Patrik
> > 
> > 
> > [1] https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html
> > [2] https://www.qubes-os.org/doc/usb/
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2
> > 
> > iQIcBAEBCAAGBQJZpYp/AAoJEFwecd8DH5rlYLsP/iV4ZHkYPAzWp8aNHMXaZ4sc
> > 1yZaYE4v2jvdnVdOV2Y7Rxny+4wKAhv3W/XDgW+PDc5HkM41+OyA516/rzapZk/t
> > /Qa3og/ciZwT0DTMaB31mJ+1mj6IYyPfxOk0tKfK8zNp6UwzlNPrE0mhkT8nTt32
> > M85Bcju5ighXVPyMD8c1v+y6eRLrFTPN9tsfMTH/PUOP/ogPjNbLByz/W3zAoVyO
> > CvylzRiJM2XfGDdYrAF1qcOQi3bkgxiL29Wy3C8fDbfkBcDMz3Br7NOpYtZSpetH
> > umpEp0RcRybmlXszp2i2GItzRCIdPNAd1QtWCK6lT41CbiNlm+QHwd9Z3mzWZgRN
> > JaikqWN6haLRORZO5r+vhFb5mRrV5y9uWblXFPQrsgkkUCM7UtmK9jfnFqFSQbO2
> > yP6ork3mUuGzHZzt7oc2PfpjYE55CU/wxM6C10QErZvA0+eDYzhkx+Rh/Eaoporz
> > Ad2zF0G0BBUjJ0mt4HPpomL5fTAZoZnoqEFK1Xe7m7VYDklINIgVGYjhi4Ektbma
> > VSW6PfXTUs9Be816pxFSCg9n8GlU0fsdp/1xFitRWCUv69aV7jFs+YsCn+XhuZzF
> > vjqLp97hDDElv8Gzd5/R/tuQmmdmvXmJN3olp++mnjLCceIHq6JTlT3KTAgX/sFB
> > jKp0HqjSdwU7USBWIo7B
> > =nrKy
> > -END PGP SIGNATURE-
> 
> my problem is unfortunately i can't keep buying new pc's. SO maybe its all 
> for naught for me.. Also AEM does not seem as reliable as secureboot. Alot of 
> issues on threads with some people. It seems complicated. even false alarms. 
> But I really do think they are supposed to compliment each other.  trusted 
> boot and measured boot yes? AEM definitely comes in handy for people who 
> would find it nescessary to buy new equipment.  
> 
> But I would still want an encrypted boot, if I was going to use aem,  and key 
> on a external usb disk,  which unfortunately means I could not use a sys-usb. 
>  Am I wrong about this?  Does this change in 4.0?
> 
> So this is where the what fits into you "security model"   What are you more 
> concered about. I assumed we had to choose between aem  vs sys-usb?  For 
> people travelling with laptops in strange places where physical compromise is 
> more likely aem is a good option.  Some people would prolly not just buy a 
> new laptop but know when to destroy theirs too lol.

Doesn't everyone destroy hdd's and phones when they bricked our outdated and 
you done with them like Hillary?  I always tell myself i'm going to and just 
have them stacked in a box,   cause nothing really that sensitive on there.  
But I feel it should be good common practice.

-- 
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/b5421ba2-b301-4851-87f0-4e5ca698c8bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Options for securing /boot

[cooloutac]

On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik Hagara wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 08/29/2017 04:50 PM, cyberian@national.shitposting.agency wrote:
> > Leo Gaspard,
> > 
> > I have read about AEM but have never used it, it seems like it is
> > geared towards protecting from USB's with malicious firmware on
> > them.
> > 
> > Does AEM actually verify the integrity of /boot before using?  This
> > is what I am looking for, either a method of encrypting /boot or
> > even better, a secure method to verify its integrity during boot
> > 
> 
> AEM does verify the integrity of /boot using the TPM seal/unseal
> operation. If any of the boot components change, AEM falls back to
> regular, unmeasured boot -- the user is expected to notice this and
> cease using the potentially-compromised system (the lack of explicit
> indication of failed AEM boot is deliberate, see the last FAQ item at
> [1]).
> 
> The security provided by AEM is much more stronger than encrypted
> /boot could ever offer, because as already pointed out, there is
> always a little first-stage bootloader stub on the disk unencrypted
> and it would be easy to overwrite it with a malicious version that
> would intercept the encryption passphrase and exfiltrate it using eg.
> unused disk sectors.
> 
> If someone did the above with AEM, the TPM would refuse to useal the
> AEM secret as the platform state would be different.
> 
> The feature protecting dom0 from malicious USB devices [2] serves a
> different purpose and is not related to AEM. Plus, you always need to
> disconnect all untrusted USB devices while rebooting Qubes, regardless
> of whether you have USB qube set up or not.
> 
> 
> Cheers,
> Patrik
> 
> 
> [1] https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html
> [2] https://www.qubes-os.org/doc/usb/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQIcBAEBCAAGBQJZpYp/AAoJEFwecd8DH5rlYLsP/iV4ZHkYPAzWp8aNHMXaZ4sc
> 1yZaYE4v2jvdnVdOV2Y7Rxny+4wKAhv3W/XDgW+PDc5HkM41+OyA516/rzapZk/t
> /Qa3og/ciZwT0DTMaB31mJ+1mj6IYyPfxOk0tKfK8zNp6UwzlNPrE0mhkT8nTt32
> M85Bcju5ighXVPyMD8c1v+y6eRLrFTPN9tsfMTH/PUOP/ogPjNbLByz/W3zAoVyO
> CvylzRiJM2XfGDdYrAF1qcOQi3bkgxiL29Wy3C8fDbfkBcDMz3Br7NOpYtZSpetH
> umpEp0RcRybmlXszp2i2GItzRCIdPNAd1QtWCK6lT41CbiNlm+QHwd9Z3mzWZgRN
> JaikqWN6haLRORZO5r+vhFb5mRrV5y9uWblXFPQrsgkkUCM7UtmK9jfnFqFSQbO2
> yP6ork3mUuGzHZzt7oc2PfpjYE55CU/wxM6C10QErZvA0+eDYzhkx+Rh/Eaoporz
> Ad2zF0G0BBUjJ0mt4HPpomL5fTAZoZnoqEFK1Xe7m7VYDklINIgVGYjhi4Ektbma
> VSW6PfXTUs9Be816pxFSCg9n8GlU0fsdp/1xFitRWCUv69aV7jFs+YsCn+XhuZzF
> vjqLp97hDDElv8Gzd5/R/tuQmmdmvXmJN3olp++mnjLCceIHq6JTlT3KTAgX/sFB
> jKp0HqjSdwU7USBWIo7B
> =nrKy
> -END PGP SIGNATURE-

my problem is unfortunately i can't keep buying new pc's. SO maybe its all for 
naught for me.. Also AEM does not seem as reliable as secureboot. Alot of 
issues on threads with some people. It seems complicated. even false alarms. 
But I really do think they are supposed to compliment each other.  trusted boot 
and measured boot yes? AEM definitely comes in handy for people who would find 
it nescessary to buy new equipment.  

But I would still want an encrypted boot, if I was going to use aem,  and key 
on a external usb disk,  which unfortunately means I could not use a sys-usb.  
Am I wrong about this?  Does this change in 4.0?

So this is where the what fits into you "security model"   What are you more 
concered about. I assumed we had to choose between aem  vs sys-usb?  For people 
travelling with laptops in strange places where physical compromise is more 
likely aem is a good option.  Some people would prolly not just buy a new 
laptop but know when to destroy theirs too lol.

-- 
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/5148d2df-885a-4484-862f-93b679fc81b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Options for securing /boot

[cooloutac]

On Tuesday, August 29, 2017 at 12:18:45 PM UTC-4, cooloutac wrote:
> On Tuesday, August 29, 2017 at 10:47:14 AM UTC-4, 
> cybe...@national.shitposting.agency wrote:
> > I dont dual boot, as implied earlier.  I have had suspicious activity 
> > happen before in Qubes3.2 at a certain location several times; errors from 
> > Xen saying that my machine is not returning all of its memory and while 
> > viewing Xen logs I have seen the creation of domains which I surely did not 
> > do myself.
> > 
> > I currently have upgraded to 4.0rc1 and love the choice to use HVM over PV.
> > 
> > The reason I was thinking about is the scenario that I use a disposable, 
> > live-boot linux the next time I go to this location.  If the live-boot 
> > linux session were hijacked somehow, the Qubes /boot volume would be 
> > exposed.
> > 
> > Now with the release of Qubes 4.0 I would probably be better off just using 
> > Qubes, but if I could encrypt /boot I think I would be better off using the 
> > disposable live-boot method.
> > 
> > I like the idea suggested by Unman, this is exactly what I wanted to do 
> > with Grub2, I just did not want to break anything in Qubes by doing so.
> > 
> > Has anyone had any experience using Grub2 to encrypt the /boot partition 
> > and can confirm that it wont break anything with Qubes?
> 
> the vm failed to return all money, I'm not sure of the exact message,  
> happens to all of us in Qubes, its not too suspicious.  You can always just 
> wipe the vm and make another one if you get worried.   I usually keep qubes 
> manager on top at all times so I can see when a yellow triangle appears near 
> a vm.
> 
> Also a common one is if the vm failes to start qrexec or something oh god i'm 
> terrible with the file names.   This can happen cause race conditions like if 
> you start it before another one starts that it needs or loading another vm at 
> same time.  nothing to be too alarmed about unless other things are also 
> happening on that vm.  like other error messages.

don't know what I will do though when they remove qubes-manager in 4.0 lol.

-- 
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/142f412c-b58b-4823-949c-10e2e4450660%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Options for securing /boot

[cooloutac]

On Tuesday, August 29, 2017 at 10:47:14 AM UTC-4, 
cybe...@national.shitposting.agency wrote:
> I dont dual boot, as implied earlier.  I have had suspicious activity happen 
> before in Qubes3.2 at a certain location several times; errors from Xen 
> saying that my machine is not returning all of its memory and while viewing 
> Xen logs I have seen the creation of domains which I surely did not do myself.
> 
> I currently have upgraded to 4.0rc1 and love the choice to use HVM over PV.
> 
> The reason I was thinking about is the scenario that I use a disposable, 
> live-boot linux the next time I go to this location.  If the live-boot linux 
> session were hijacked somehow, the Qubes /boot volume would be exposed.
> 
> Now with the release of Qubes 4.0 I would probably be better off just using 
> Qubes, but if I could encrypt /boot I think I would be better off using the 
> disposable live-boot method.
> 
> I like the idea suggested by Unman, this is exactly what I wanted to do with 
> Grub2, I just did not want to break anything in Qubes by doing so.
> 
> Has anyone had any experience using Grub2 to encrypt the /boot partition and 
> can confirm that it wont break anything with Qubes?

the vm failed to return all money, I'm not sure of the exact message,  happens 
to all of us in Qubes, its not too suspicious.  You can always just wipe the vm 
and make another one if you get worried.   I usually keep qubes manager on top 
at all times so I can see when a yellow triangle appears near a vm.

Also a common one is if the vm failes to start qrexec or something oh god i'm 
terrible with the file names.   This can happen cause race conditions like if 
you start it before another one starts that it needs or loading another vm at 
same time.  nothing to be too alarmed about unless other things are also 
happening on that vm.  like other error messages.

-- 
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/4e1e6c7c-cad5-42dd-b49d-7e3ff9d7da1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Options for securing /boot

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/29/2017 04:50 PM, cyberian@national.shitposting.agency wrote:
> Leo Gaspard,
> 
> I have read about AEM but have never used it, it seems like it is
> geared towards protecting from USB's with malicious firmware on
> them.
> 
> Does AEM actually verify the integrity of /boot before using?  This
> is what I am looking for, either a method of encrypting /boot or
> even better, a secure method to verify its integrity during boot
> 

AEM does verify the integrity of /boot using the TPM seal/unseal
operation. If any of the boot components change, AEM falls back to
regular, unmeasured boot -- the user is expected to notice this and
cease using the potentially-compromised system (the lack of explicit
indication of failed AEM boot is deliberate, see the last FAQ item at
[1]).

The security provided by AEM is much more stronger than encrypted
/boot could ever offer, because as already pointed out, there is
always a little first-stage bootloader stub on the disk unencrypted
and it would be easy to overwrite it with a malicious version that
would intercept the encryption passphrase and exfiltrate it using eg.
unused disk sectors.

If someone did the above with AEM, the TPM would refuse to useal the
AEM secret as the platform state would be different.

The feature protecting dom0 from malicious USB devices [2] serves a
different purpose and is not related to AEM. Plus, you always need to
disconnect all untrusted USB devices while rebooting Qubes, regardless
of whether you have USB qube set up or not.


Cheers,
Patrik


[1] https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html
[2] https://www.qubes-os.org/doc/usb/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZpYp/AAoJEFwecd8DH5rlYLsP/iV4ZHkYPAzWp8aNHMXaZ4sc
1yZaYE4v2jvdnVdOV2Y7Rxny+4wKAhv3W/XDgW+PDc5HkM41+OyA516/rzapZk/t
/Qa3og/ciZwT0DTMaB31mJ+1mj6IYyPfxOk0tKfK8zNp6UwzlNPrE0mhkT8nTt32
M85Bcju5ighXVPyMD8c1v+y6eRLrFTPN9tsfMTH/PUOP/ogPjNbLByz/W3zAoVyO
CvylzRiJM2XfGDdYrAF1qcOQi3bkgxiL29Wy3C8fDbfkBcDMz3Br7NOpYtZSpetH
umpEp0RcRybmlXszp2i2GItzRCIdPNAd1QtWCK6lT41CbiNlm+QHwd9Z3mzWZgRN
JaikqWN6haLRORZO5r+vhFb5mRrV5y9uWblXFPQrsgkkUCM7UtmK9jfnFqFSQbO2
yP6ork3mUuGzHZzt7oc2PfpjYE55CU/wxM6C10QErZvA0+eDYzhkx+Rh/Eaoporz
Ad2zF0G0BBUjJ0mt4HPpomL5fTAZoZnoqEFK1Xe7m7VYDklINIgVGYjhi4Ektbma
VSW6PfXTUs9Be816pxFSCg9n8GlU0fsdp/1xFitRWCUv69aV7jFs+YsCn+XhuZzF
vjqLp97hDDElv8Gzd5/R/tuQmmdmvXmJN3olp++mnjLCceIHq6JTlT3KTAgX/sFB
jKp0HqjSdwU7USBWIo7B
=nrKy
-END PGP SIGNATURE-

-- 
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/38703b18-acec-7c59-d2ec-257a84e9021e%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


0x031F9AE5.asc
Description: application/pgp-keys


0x031F9AE5.asc.sig
Description: PGP signature

Re: [qubes-users] Options for securing /boot

[cyberian]

Leo Gaspard,

I have read about AEM but have never used it, it seems like it is geared 
towards protecting from USB's with malicious firmware on them.

Does AEM actually verify the integrity of /boot before using?  This is what I 
am looking for, either a method of encrypting /boot or even better, a secure 
method to verify its integrity during boot

-- 
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/77614078-04f4-42b1-b57b-b22bd54103d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Options for securing /boot

[cyberian]

I dont dual boot, as implied earlier.  I have had suspicious activity happen 
before in Qubes3.2 at a certain location several times; errors from Xen saying 
that my machine is not returning all of its memory and while viewing Xen logs I 
have seen the creation of domains which I surely did not do myself.

I currently have upgraded to 4.0rc1 and love the choice to use HVM over PV.

The reason I was thinking about is the scenario that I use a disposable, 
live-boot linux the next time I go to this location.  If the live-boot linux 
session were hijacked somehow, the Qubes /boot volume would be exposed.

Now with the release of Qubes 4.0 I would probably be better off just using 
Qubes, but if I could encrypt /boot I think I would be better off using the 
disposable live-boot method.

I like the idea suggested by Unman, this is exactly what I wanted to do with 
Grub2, I just did not want to break anything in Qubes by doing so.

Has anyone had any experience using Grub2 to encrypt the /boot partition and 
can confirm that it wont break anything with Qubes?

-- 
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/8bb2b2a5-38dc-42a1-83b9-0e3c91d920a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Options for securing /boot

[cooloutac]

On Monday, August 28, 2017 at 6:36:08 PM UTC-4, Leo Gaspard wrote:
> Just encrypting /boot would bring little, as it would still be possible
> to modify the unencrypted part of GRUB (that decrypts /boot) to have it
> overwrite the /boot with malicious kernel images (or even to not use the
> ones provided).
> 
> The options I know of are (from IMO strongest to weakest):
>  * AEM, for knowing when someone tampered with /boot
>  * SecureBoot, for restricting the allowed-to-boot images (I don't know
> about its ease of use with qubes, though)
>  * locking your bootloader with a password and disallow external boot
> 
> I'd think having all these protections at the same time would be best,
> using secureboot mostly to avoid having to ditch the laptop after AEM
> says it's no longer trustworthy (because it may stop the attacker before
> it can even make the laptop no longer trustworthy).
> 
> 
> On 08/28/2017 09:48 PM, Unman wrote:
> > On Sat, Aug 26, 2017 at 08:39:23AM -0700, 
> > cyberian@national.shitposting.agency wrote:
> >> Does Qubes offer a method of securing /boot? not just against USB evil 
> >> maid attacks, but from tampering in general?
> >>
> >> for example, while a laptop is off, what would stop a malicious user from 
> >> live booting to an arbitrary distro and altering kernel or xen images 
> >> located on the unencrypted /boot partition?
> >>
> >> Does qubes offer options for encrypting /boot?
> >>
> > 
> > The Fedora installer wont allow an encrypted boot partition, but there's
> > nothing stopping you from encrypting /boot after installation. You will,
> > of course, have to reconfigure grub to decrypt the new /boot, but that's
> > straightforward.
> > 
> > 
> >

secureboot can do more then restricting boot images,  it can restrict unsigned 
drivers too.  Thats the part Joanna doesn't like because she does not trust who 
will maintain the list of signed drivers.  I say I'm already putting just as 
much trust into alot of other things like my banks ssl cert when connecting to 
my bank account.

We are already trusting everything coming from upstream when we update...

-- 
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/17709195-8382-493a-abe0-3fe3d5b5c713%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ubuntu template

[kushaldas]

On Wednesday, June 28, 2017 at 6:14:07 AM UTC+5:30, Unman wrote:
> 
> I think you need to work on your search skills :-) 
> The same question was asked on this list 3 days ago.
> The mount error arises because 'mount' isn't on the path - copy the
> export PATH statement from template_debian/vars.sh to
> template_qubuntu/vars.sh, and you should be good to go.
> 
> The build on master is crocked for the moment.
> Note that the PRs are all merged to 3.2, and you can therefore build on
> 3.2 without any problem. 
> The simplest way to do this is to set RELEASE := 3.2 , and then 'make
> switch-branch'.
> 
Can we build Trusty on a 4.0rc1 box now? Trying to figure out this
mount related error from early morning. Less than 24 hours of Qubes
experiene this side though.


Kushal

-- 
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/8d1c9d1e-96ed-4aa0-9044-1d7f0680d022%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: to firejail or not to firejail

[pixelfairy]

just remembered, a couple other ssh exploits, and googled for them, found a
couple others. so that does come up once in a while.

On Tue, Aug 29, 2017 at 12:54 AM pixel fairy  wrote:

> On Monday, August 28, 2017 at 10:46:22 PM UTC-7, Eric wrote:
> > The question as always is, what are you protecting? If it's your user
> data, compartmentalize differently. If it's some kind of root privilege
> escalation, that's a lost cause, as the vm sudo page explains. If it's some
> kind of malware that could get written with root privileges, well, that
> gets erased by rebooting the VM, unless it's persistent in your user data,
> but if it is, it's incredibly unlikely to be runable (at least not without
> explicit user action).
> >
> > I raise these questions because the answer to many of the "OMGWTFBBQ
> passwordless sudo" threads that appear every so often, come back down to
> either "whatever you're proposing wouldn't make a difference read the doc
> again" and "are you sure you read the doc and understood why the decision
> was made the way it was?"
>
> this wasnt specifically because of the passwordless sudo. its a general
> access control and hardening thing. i see firejail as complementary to
> qubes-os. ssh shouldnt access the x server. firefox shouldnt write outside
> of its own folder and Downloads. neither should shell out and call sudo.
> when they do, or try to, id really like to know about it. firejail can log
> such access, and you can have another process follow that log to alert you.
>
> but having firejail do that, and watching that log, are more processes,
> more attack surface.
>
> to add to extremely unlikely, ive only known of one ssh client exploit in
> the wild, and i think it was over 10 years ago.
>
> >
> > I don't disagree that hardening VMs in general is good practice; I am
> very sad that Subgraph is MIA and grsecurity patches are no longer
> available, since they were a great way to harden Linux VMs.
>
> subgraph was a neat idea. looked at it for a friend whos laptop lacked
> hypervisor extensions, but couldnt get it to work.
>
> >
> > In your particular situation, a good compromise might be the dom0
> escalation prompt, described at the end of the VM Sudo documenation (no
> additional code, really, and at least *some* peace of mind that...it would
> take a few more seconds of extra work to find a root privilege escalation
> that would get around the prompt requirement?)
>
> looked over that out of curiosity since it seemed like a neat idea, but
> never tried it.
>
> >
> >
> > On Monday, August 28, 2017 at 9:22:48 PM UTC-7, pixel fairy wrote:
> > > firejail , https://firejail.wordpress.com/
> > >
> > > can be used to restrict and/or contexualize a process with namespaces.
> i was thinking of restricting ssh connections with it to prevent the free
> privilege escalation qubes gives malicious apps in case of an exploitable
> hole in ssh. but, firejail itself is more code to exploit, and though it
> matters less in qubes, setuid.
> > >
> > > so what thinks all of you? worth the extra attack surface?
> > >
> > > was also thinking of using firejails logging to flag attempts at sudo
> etc as another means to flag a host with problems. this again, means extra
> code that itself could be exploited.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "qubes-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/qubes-users/RnKRH0lIP_c/unsubscribe.
> To unsubscribe from this group and all its topics, 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/ab05b325-683f-417d-9862-1833fe867678%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CACr%3DtZdi_du%3D82Ym0wwqVSLg5Hzw8PwzsVHXKdV23Nd3RJDgjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: to firejail or not to firejail

[pixel fairy]

On Monday, August 28, 2017 at 10:46:22 PM UTC-7, Eric wrote:
> The question as always is, what are you protecting? If it's your user data, 
> compartmentalize differently. If it's some kind of root privilege escalation, 
> that's a lost cause, as the vm sudo page explains. If it's some kind of 
> malware that could get written with root privileges, well, that gets erased 
> by rebooting the VM, unless it's persistent in your user data, but if it is, 
> it's incredibly unlikely to be runable (at least not without explicit user 
> action).
> 
> I raise these questions because the answer to many of the "OMGWTFBBQ 
> passwordless sudo" threads that appear every so often, come back down to 
> either "whatever you're proposing wouldn't make a difference read the doc 
> again" and "are you sure you read the doc and understood why the decision was 
> made the way it was?"

this wasnt specifically because of the passwordless sudo. its a general access 
control and hardening thing. i see firejail as complementary to qubes-os. ssh 
shouldnt access the x server. firefox shouldnt write outside of its own folder 
and Downloads. neither should shell out and call sudo. when they do, or try to, 
id really like to know about it. firejail can log such access, and you can have 
another process follow that log to alert you. 

but having firejail do that, and watching that log, are more processes, more 
attack surface.

to add to extremely unlikely, ive only known of one ssh client exploit in the 
wild, and i think it was over 10 years ago.

> 
> I don't disagree that hardening VMs in general is good practice; I am very 
> sad that Subgraph is MIA and grsecurity patches are no longer available, 
> since they were a great way to harden Linux VMs.

subgraph was a neat idea. looked at it for a friend whos laptop lacked 
hypervisor extensions, but couldnt get it to work.

> 
> In your particular situation, a good compromise might be the dom0 escalation 
> prompt, described at the end of the VM Sudo documenation (no additional code, 
> really, and at least *some* peace of mind that...it would take a few more 
> seconds of extra work to find a root privilege escalation that would get 
> around the prompt requirement?)

looked over that out of curiosity since it seemed like a neat idea, but never 
tried it.

> 
> 
> On Monday, August 28, 2017 at 9:22:48 PM UTC-7, pixel fairy wrote:
> > firejail , https://firejail.wordpress.com/
> > 
> > can be used to restrict and/or contexualize a process with namespaces. i 
> > was thinking of restricting ssh connections with it to prevent the free 
> > privilege escalation qubes gives malicious apps in case of an exploitable 
> > hole in ssh. but, firejail itself is more code to exploit, and though it 
> > matters less in qubes, setuid. 
> > 
> > so what thinks all of you? worth the extra attack surface?
> > 
> > was also thinking of using firejails logging to flag attempts at sudo etc 
> > as another means to flag a host with problems. this again, means extra code 
> > that itself could 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/ab05b325-683f-417d-9862-1833fe867678%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: qubes-devel Google Group Web Interface: Banned Content Warning

[Andrew Morgan]

On 08/29/2017 12:22 AM, Andrew Morgan wrote:
> On 08/28/2017 10:27 PM, Reg Tiangha wrote:
>> FYI, trying to view the qubes-devel Google Group on a web browser
>> currently displays this message:
>>
>> Banned Content Warning
>> The group that you are attempting to view (qubes-devel) has been
>> identified as containing spam, malware or other malicious content.
>> Content in this group is now limited to view-only mode for those with
>> access.
>> Group owners can request an appeal after they have taken steps to clean
>> up potentially offensive content in the forum. For more information
>> about content policies on Google Groups, please see our Help Centre
>> article on abuse and our Terms of Service.
>>
>> If you click on "Continue to the group," it shows no messages.
>>
> 
> FYI this doesn't affect reading the news groups from any other client
> such as Thunderbird.
> 
> If people need, the instructions for adding Qubes' mailing lists to
> Thunderbird are here: https://www.qubes-os.org/mailing-lists/
> 
> Andrew Morgan
> 

I don't seem to be able to post to the list, however. I continue getting
the following message:

We're writing to let you know that the group you tried to contact
(qubes-devel) may not exist, or you may not have permission to post
messages to the group. A few more details on why you weren't able to post:

 * You might have spelled or formatted the group name incorrectly.
 * The owner of the group may have removed this group.
 * You may need to join the group before receiving permission to post.
 * This group may not be open to posting.

Andrew Morgan

-- 
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/oo3504%246u0%244%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature