On Tuesday, April 3, 2018 at 4:24:21 AM UTC-4, tai...@gmx.com wrote:
> On 04/02/2018 09:32 PM, cooloutac wrote:
>
> > On Monday, April 2, 2018 at 3:43:50 PM UTC-4, tai...@gmx.com wrote:
> >> On 09/08/2017 07:12 AM, Leo Gaspard wrote:
> >>
> >>> Just a datapoint: secure boot is *not* microsoft-cont
On 04/02/2018 09:32 PM, cooloutac wrote:
> On Monday, April 2, 2018 at 3:43:50 PM UTC-4, tai...@gmx.com wrote:
>> On 09/08/2017 07:12 AM, Leo Gaspard wrote:
>>
>>> Just a datapoint: secure boot is *not* microsoft-controlled (unless you
>>> assume the manufacturer put in some kind of backdoor, in w
On Monday, April 2, 2018 at 3:43:50 PM UTC-4, tai...@gmx.com wrote:
> On 09/08/2017 07:12 AM, Leo Gaspard wrote:
>
> > Just a datapoint: secure boot is *not* microsoft-controlled (unless you
> > assume the manufacturer put in some kind of backdoor, in which case
> > you're screwed anyway).
> Yes i
On 09/08/2017 07:12 AM, Leo Gaspard wrote:
> Just a datapoint: secure boot is *not* microsoft-controlled (unless you
> assume the manufacturer put in some kind of backdoor, in which case
> you're screwed anyway).
Yes it is microsoft controlled, they're the ones who made the standard
and convenient
On 09/08/2017 04:51 AM, taii...@gmx.com wrote:
> One can use coreboot with grub's kernel signing features on an owner
> controlled non PSP/ME PC such as the Lenovo G505 (laptop) or KCMA-D8
> (workstation), then after coreboot is working you enable the flash write
> restriction so that it can't be f
One can use coreboot with grub's kernel signing features on an owner
controlled non PSP/ME PC such as the Lenovo G505 (laptop) or KCMA-D8
(workstation), then after coreboot is working you enable the flash write
restriction so that it can't be flashed internally (an attacker would
have to have p
On Thursday, September 7, 2017 at 12:49:05 PM UTC-4, cooloutac wrote:
> On Thursday, September 7, 2017 at 9:40:47 AM UTC-4, Patrik Hagara wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > On 09/07/2017 03:21 PM, cooloutac wrote:
> > > On Tuesday, August 29, 2017 at 12:46:04 PM
On Thursday, September 7, 2017 at 9:40:47 AM UTC-4, Patrik Hagara wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 09/07/2017 03:21 PM, cooloutac wrote:
> > On Tuesday, August 29, 2017 at 12:46:04 PM UTC-4, Patrik Hagara
> > wrote: On 08/29/2017 06:25 PM, cooloutac wrote:
> O
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/07/2017 03:21 PM, cooloutac wrote:
> On Tuesday, August 29, 2017 at 12:46:04 PM UTC-4, Patrik Hagara
> wrote: 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/201
On Tuesday, August 29, 2017 at 12:46:04 PM UTC-4, Patrik Hagara wrote:
> -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.shitpost
On Thursday, September 7, 2017 at 9:15:31 AM UTC-4, cooloutac wrote:
> On Tuesday, August 29, 2017 at 1:09:36 PM UTC-4, Leo Gaspard wrote:
> > 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 l
On Tuesday, August 29, 2017 at 1:09:36 PM UTC-4, Leo Gaspard wrote:
> 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 G
On 08/30/2017 11:49 AM, wordswithn...@gmail.com wrote:
On Tuesday, August 29, 2017 at 7:16:16 PM UTC-4, steve.coleman wrote:
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 mar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/30/2017 05:46 PM, wordswithn...@gmail.com wrote:
>> Plus, you always need to disconnect all untrusted USB devices
>> while rebooting Qubes, regardless of whether you have USB qube
>> set up or not.
>>
>
> I just want to make sure that this is
On Tuesday, August 29, 2017 at 7:16:16 PM UTC-4, steve.coleman wrote:
> 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 *
> Plus, you always need to
> disconnect all untrusted USB devices while rebooting Qubes, regardless
> of whether you have USB qube set up or not.
>
I just want to make sure that this is not always the case - according to
https://www.qubes-os.org/doc/usb/, if you create the USB VM automatically
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 tha
-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:
-B
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:
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 k
-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 nev
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,
> > >
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
Thank you for the detailed description, Patrik. That sounds like exactly what
I am looking for.
Much appreciated.
--
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
-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
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,
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 pr
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
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 boot
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 pa
30 matches
Mail list logo
