-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, Nov 25, 2016 at 12:19:14AM +0300, Eva Star wrote:
> On 11/19/2016 10:31 PM, Marek Marczykowski-Górecki wrote:
>
> > Yes, exactly
>
> Is it possible to check non encrypted boot part of the disk for checksums
> after OS was loaded and warn us
On 11/19/2016 10:31 PM, Marek Marczykowski-Górecki wrote:
Yes, exactly
Is it possible to check non encrypted boot part of the disk for
checksums after OS was loaded and warn user about some changes? ( or
check some files on boot part)
Is it a good idea?
Or maybe some USB disk with loader w
On 11/19/2016 02:31 PM, Marek Marczykowski-Górecki wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sat, Nov 19, 2016 at 07:20:56PM +, Fred wrote:
On 2016-11-19 11:54, Andrew David Wong wrote:
On 2016-11-16 13:31, Fred wrote:
A good time to ask if Qubes encrypts /boot in it's LU
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sat, Nov 19, 2016 at 07:20:56PM +, Fred wrote:
> On 2016-11-19 11:54, Andrew David Wong wrote:
> > On 2016-11-16 13:31, Fred wrote:
> > > A good time to ask if Qubes encrypts /boot in it's LUKS setup. I've
> > > not
> > > checked myself.
> > >
On 2016-11-19 11:54, Andrew David Wong wrote:
On 2016-11-16 13:31, Fred wrote:
A good time to ask if Qubes encrypts /boot in it's LUKS setup. I've
not
checked myself.
By default, Qubes does not encrypt /boot. Traditionally, that's
because doing so would render the
system unbootable. However,
Am 19.11.2016 um 12:54 schrieb Andrew David Wong:
> By default, Qubes does not encrypt /boot. Traditionally, that's
> because doing so would render the
> system unbootable. However, that's no longer true with newer versions
> of GRUB, which are now capable
> of booting from encrypted block devices.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2016-11-16 13:31, Fred wrote:
> A good time to ask if Qubes encrypts /boot in it's LUKS setup. I've not
> checked myself.
>
By default, Qubes does not encrypt /boot. Traditionally, that's because doing
so would render the
system unbootable. How
Setting a boot password in the BIOS should mitigate adequately since
initrd does not execute until after boot password entry.
On 11/17/2016 12:20 AM, Vít Šesták wrote:
According to the description, it looks likely to affect Qubes.
According to my experience, I remember getting in the shell (fr
According to the description, it looks likely to affect Qubes.
According to my experience, I remember getting in the shell (from a different
reason) and it asked for a password. I believe this happened when upgrading to
3.2 due to a mountpoint issue. This suggests that Qubes is not affected, but
On 16/11/2016 19:10, berthold_...@web.de wrote:
> Does this affect QubesOS?
>
> https://threatpost.com/cryptsetup-vulnerability-grants-root-shell-access-on-some-linux-systems/121963/
>
Looks like a fairly low priority to me. You can get initramfs shell in a
Busybox and have access to /boot (on s
Does this affect QubesOS?
https://threatpost.com/cryptsetup-vulnerability-grants-root-shell-access-on-some-linux-systems/121963/
--
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, se
11 matches
Mail list logo
