Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #199972 > unrolled thread
| Started by | Mimiko <vbvbrj@gmail.com> |
|---|---|
| First post | 2018-09-11 10:50 +0200 |
| Last post | 2018-09-13 05:00 +0200 |
| Articles | 20 on this page of 91 — 29 participants |
Back to article view | Back to linux.debian.user
root on ZFS Mimiko <vbvbrj@gmail.com> - 2018-09-11 10:50 +0200
Re: root on ZFS <tomas@tuxteam.de> - 2018-09-11 11:10 +0200
Re: root on ZFS Mimiko <vbvbrj@gmail.com> - 2018-09-11 14:20 +0200
Re: root on ZFS <tomas@tuxteam.de> - 2018-09-11 14:50 +0200
Re: root on ZFS Matthew Crews <mailinglists@mattcrews.com> - 2018-09-11 15:00 +0200
Re: root on ZFS Matthew Crews <mailinglists@mattcrews.com> - 2018-09-11 14:50 +0200
ext2 for /boot ??? -- WAS: Re: root on ZFS Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-09-11 20:10 +0200
Re: ext2 for /boot ??? -- WAS: Re: root on ZFS Matthew Crews <mailinglists@mattcrews.com> - 2018-09-11 20:30 +0200
Re: ext2 for /boot ??? -- WAS: Re: root on ZFS Michael Stone <mstone@debian.org> - 2018-09-11 20:40 +0200
Re: ext2 for /boot ??? Felix Miata <mrmazda@earthlink.net> - 2018-09-12 01:40 +0200
Re: ext2 for /boot ??? Lee <ler762@gmail.com> - 2018-09-12 05:40 +0200
Re: ext2 for /boot ??? Mimiko <vbvbrj@gmail.com> - 2018-09-12 07:50 +0200
Re: ext2 for /boot ??? Jonathan Dowland <jmtd@debian.org> - 2018-09-12 11:20 +0200
Re: ext2 for /boot ??? Sven Joachim <svenjoac@gmx.de> - 2018-09-12 11:40 +0200
Re: ext2 for /boot ??? David Wright <deblis@lionunicorn.co.uk> - 2018-09-12 21:00 +0200
Re: ext2 for /boot ??? Sven Joachim <svenjoac@gmx.de> - 2018-09-12 21:40 +0200
Re: ext2 for /boot ??? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-12 23:00 +0200
Re: ext2 for /boot ??? Michael Stone <mstone@debian.org> - 2018-09-13 00:00 +0200
Re: ext2 for /boot ??? David Wright <deblis@lionunicorn.co.uk> - 2018-09-14 05:30 +0200
Re: ext2 for /boot ??? Zenaan Harkness <zenaan@freedbms.net> - 2018-09-14 06:10 +0200
Re: ext2 for /boot ??? Stefan Monnier <monnier@iro.umontreal.ca> - 2018-09-14 14:40 +0200
Re: ext2 for /boot ??? Michael Stone <mstone@debian.org> - 2018-09-14 14:50 +0200
Re: ext2 for /boot ??? Matthew Crews <mailinglists@mattcrews.com> - 2018-09-14 17:10 +0200
Re: ext2 for /boot ??? deloptes <deloptes@gmail.com> - 2018-09-14 18:30 +0200
Re: ext2 for /boot ??? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-14 20:00 +0200
Re: ext2 for /boot ??? Matthew Crews <mailinglists@mattcrews.com> - 2018-09-15 00:50 +0200
Re: ext2 for /boot ??? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-15 08:50 +0200
Re: ext2 for /boot ??? Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-09-15 18:00 +0200
Re: ext2 for /boot ??? deloptes <deloptes@gmail.com> - 2018-09-16 00:00 +0200
Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? Andy Smith <andy@strugglers.net> - 2018-09-16 00:50 +0200
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-17 20:10 +0200
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? deloptes <deloptes@gmail.com> - 2018-09-17 20:20 +0200
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-09-18 20:10 +0200
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? Andy Smith <andy@strugglers.net> - 2018-09-19 05:00 +0200
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-09-19 17:50 +0200
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? Igor Cicimov <icicimov@gmail.com> - 2018-09-26 01:10 +0200
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? deloptes <deloptes@gmail.com> - 2018-09-26 18:20 +0200
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? Jonathan Dowland <jmtd@debian.org> - 2018-09-26 19:20 +0200
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? deloptes <deloptes@gmail.com> - 2018-09-26 20:20 +0200
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-09-27 10:00 +0200
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? deloptes <deloptes@gmail.com> - 2018-09-27 17:40 +0200
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? Igor Cicimov <icicimov@gmail.com> - 2018-09-28 13:10 +0200
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? Celejar <celejar@gmail.com> - 2018-09-30 03:20 +0200
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? deloptes <deloptes@gmail.com> - 2018-09-30 08:50 +0200
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-09-30 12:10 +0200
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? Celejar <celejar@gmail.com> - 2018-09-30 23:40 +0200
Re: ext2 for /boot ??? Jonathan Dowland <jmtd@debian.org> - 2018-09-26 11:20 +0200
Re: ext2 for /boot ??? Dan Ritter <dsr@randomstring.org> - 2018-09-14 15:10 +0200
Re: ext2 for /boot ??? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-14 20:50 +0200
Re: ext2 for /boot ??? David Wright <deblis@lionunicorn.co.uk> - 2018-09-15 00:10 +0200
Re: ext2 for /boot ??? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-15 09:20 +0200
Re: ext2 for /boot ??? Celejar <celejar@gmail.com> - 2018-09-16 16:40 +0200
Re: ext2 for /boot ??? David Wright <deblis@lionunicorn.co.uk> - 2018-10-10 00:00 +0200
Re: ext2 for /boot ??? Zenaan Harkness <zenaan@freedbms.net> - 2018-09-15 01:30 +0200
Re: ext2 for /boot ??? deloptes <deloptes@gmail.com> - 2018-09-14 15:20 +0200
Re: ext2 for /boot ??? Brad Rogers <brad@fineby.me.uk> - 2018-09-14 16:50 +0200
Re: ext2 for /boot ??? Stefan Monnier <monnier@iro.umontreal.ca> - 2018-09-14 19:30 +0200
Re: ext2 for /boot ??? Michael Stone <mstone@debian.org> - 2018-09-14 22:20 +0200
Re: ext2 for /boot ??? Erik Christiansen <dvalin@internode.on.net> - 2018-09-15 08:50 +0200
Re: ext2 for /boot ??? Gene Heskett <gheskett@shentel.net> - 2018-09-15 10:10 +0200
The big, the bloated and the hungry (Was: ext2 for /boot ???) Étienne Mollier <etienne.mollier@mailoo.org> - 2018-09-15 10:20 +0200
Re: The big, the bloated and the hungry Felix Miata <mrmazda@earthlink.net> - 2018-09-15 10:50 +0200
Re: The big, the bloated and the hungry Étienne Mollier <etienne.mollier@mailoo.org> - 2018-09-15 11:30 +0200
Re: The big, the bloated and the hungry Celejar <celejar@gmail.com> - 2018-09-16 16:50 +0200
Re: The big, the bloated and the hungry Nicholas Geovanis <nickgeovanis@gmail.com> - 2018-09-18 19:00 +0200
Re: The big, the bloated and the hungry Étienne Mollier <etienne.mollier@mailoo.org> - 2018-09-18 21:10 +0200
Re: The big, the bloated and the hungry (Was: ext2 for /boot ???) Thakur Mahashaya <thmsh@yandex.ru> - 2018-09-15 12:50 +0200
Re: The big, the bloated and the hungry (Was: ext2 for /boot ???) Thakur Mahashaya <thmsh@yandex.ru> - 2018-09-15 12:50 +0200
Re: The big, the bloated and the hungry (Was: ext2 for /boot ???) Thakur Mahashaya <thmsh@yandex.ru> - 2018-09-15 13:00 +0200
Re: The big, the bloated and the hungry etienne.mollier@mailoo.org - 2018-09-16 12:20 +0200
Re: ext2 for /boot ??? Jonathan Dowland <jmtd@debian.org> - 2018-09-26 11:10 +0200
Re: ext2 for /boot ??? Stefan Monnier <monnier@iro.umontreal.ca> - 2018-09-14 14:50 +0200
Re: ext2 for /boot ??? Kenneth Parker <sea7kenp@gmail.com> - 2018-09-14 06:40 +0200
Re: ext2 for /boot ??? David Wright <deblis@lionunicorn.co.uk> - 2018-09-14 17:40 +0200
Re: ext2 for /boot ??? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-14 21:00 +0200
Re: ext2 for /boot ??? Jonathan Dowland <jmtd@debian.org> - 2018-09-26 11:10 +0200
Re: ext2 for /boot ??? deloptes <deloptes@gmail.com> - 2018-09-12 08:10 +0200
Re: ext2 for /boot ??? Felix Miata <mrmazda@earthlink.net> - 2018-09-12 08:20 +0200
Re: ext2 for /boot ??? deloptes <deloptes@gmail.com> - 2018-09-12 09:00 +0200
Re: ext2 for /boot ??? Brad Rogers <brad@fineby.me.uk> - 2018-09-12 11:20 +0200
Re: ext2 for /boot ??? Felix Miata <mrmazda@earthlink.net> - 2018-09-12 12:30 +0200
Re: ext2 for /boot ??? Michael Stone <mstone@debian.org> - 2018-09-12 15:50 +0200
Re: ext2 for /boot ??? Glenn English <ghe2001@gmail.com> - 2018-09-12 17:40 +0200
Re: ext2 for /boot ??? Brad Rogers <brad@fineby.me.uk> - 2018-09-12 18:00 +0200
Re: ext2 for /boot ??? Felix Miata <mrmazda@earthlink.net> - 2018-09-12 18:30 +0200
Re: ext2 for /boot ??? -- WAS: Re: root on ZFS <tomas@tuxteam.de> - 2018-09-12 09:50 +0200
Re: root on ZFS Mimiko <vbvbrj@gmail.com> - 2018-09-12 08:00 +0200
Re: root on ZFS David Christensen <dpchrist@holgerdanske.com> - 2018-09-12 02:40 +0200
Re: root on ZFS Matthew Crews <mailinglists@mattcrews.com> - 2018-09-12 16:00 +0200
Re: root on ZFS David Christensen <dpchrist@holgerdanske.com> - 2018-09-13 04:30 +0200
Re: root on ZFS Matthew Crews <mattcrews@mattcrews.com> - 2018-09-13 05:00 +0200
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2018-09-14 14:40 +0200 |
| Subject | Re: ext2 for /boot ??? |
| Message-ID | <wxVya-7R-17@gated-at.bofh.it> |
| In reply to | #200112 |
> So, make /boot a big larger, say couple GiBs, and set data=journalled
BTW, am I the only one here bothered that his 250MB /boot partition
tends to fill up, even though a 500MB HDD was plenty to hold the whole
OS plus lots and lots of free space, on a 64bit workstation like the
original DEC Alphas?
Stefan "is that what they call a senior moment?"
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2018-09-14 14:50 +0200 |
| Subject | Re: ext2 for /boot ??? |
| Message-ID | <wxVHP-b4-1@gated-at.bofh.it> |
| In reply to | #200125 |
On Fri, Sep 14, 2018 at 08:37:45AM -0400, Stefan Monnier wrote: >BTW, am I the only one here bothered that his 250MB /boot partition >tends to fill up, even though a 500MB HDD was plenty to hold the whole >OS plus lots and lots of free space, on a 64bit workstation like the >original DEC Alphas? You can solve that issue by not insisting on having a /boot partition...
[toc] | [prev] | [next] | [standalone]
| From | Matthew Crews <mailinglists@mattcrews.com> |
|---|---|
| Date | 2018-09-14 17:10 +0200 |
| Subject | Re: ext2 for /boot ??? |
| Message-ID | <wxXTj-1DX-9@gated-at.bofh.it> |
| In reply to | #200126 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, Sep 14, 2018 at 08:37:45AM -0400, Stefan Monnier wrote: >You can solve that issue by not insisting on having a /boot partition... Not an option if you want / root on LUKS.
[toc] | [prev] | [next] | [standalone]
| From | deloptes <deloptes@gmail.com> |
|---|---|
| Date | 2018-09-14 18:30 +0200 |
| Subject | Re: ext2 for /boot ??? |
| Message-ID | <wxZ8J-2hs-1@gated-at.bofh.it> |
| In reply to | #200132 |
Matthew Crews wrote: > Not an option if you want / root on LUKS. +1
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2018-09-14 20:00 +0200 |
| Subject | Re: ext2 for /boot ??? |
| Message-ID | <wy0xQ-2Ys-13@gated-at.bofh.it> |
| In reply to | #200132 |
Le 14/09/2018 à 17:06, Matthew Crews a écrit : > On Fri, Sep 14, 2018 at 08:37:45AM -0400, Stefan Monnier wrote: >> You can solve that issue by not insisting on having a /boot partition... > > Not an option if you want / root on LUKS. Actually you can have / including /boot on LUKS with GRUB. It is just not natively supported by the Debian installer.
[toc] | [prev] | [next] | [standalone]
| From | Matthew Crews <mailinglists@mattcrews.com> |
|---|---|
| Date | 2018-09-15 00:50 +0200 |
| Subject | Re: ext2 for /boot ??? |
| Message-ID | <wy54t-5E2-9@gated-at.bofh.it> |
| In reply to | #200138 |
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, September 14, 2018 10:58 AM, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote: > Le 14/09/2018 à 17:06, Matthew Crews a écrit : > > > On Fri, Sep 14, 2018 at 08:37:45AM -0400, Stefan Monnier wrote: > > > > > You can solve that issue by not insisting on having a /boot partition... > > > > Not an option if you want / root on LUKS. > > Actually you can have / including /boot on LUKS with GRUB. It is just > not natively supported by the Debian installer. Oh really? I might need to look into that. Where can I learn more?
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2018-09-15 08:50 +0200 |
| Subject | Re: ext2 for /boot ??? |
| Message-ID | <wycyZ-1Kv-19@gated-at.bofh.it> |
| In reply to | #200149 |
Le 15/09/2018 à 00:45, Matthew Crews a écrit :
> On Friday, September 14, 2018 10:58 AM, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>
>> Actually you can have / including /boot on LUKS with GRUB. It is just
>> not natively supported by the Debian installer.
>
> Oh really? I might need to look into that. Where can I learn more?
You must add GRUB_ENABLE_CRYPTODISK=y into /etc/default/grub before
running grub-install and update-grub/grub-mkconfig.
Quote from https://www.gnu.org/software/grub/manual/grub/grub.html :
‘GRUB_ENABLE_CRYPTODISK’
If set to ‘y’, grub-mkconfig and grub-install will check for
encrypted disks and generate additional commands needed to access them
during boot. Note that in this case unattended boot is not possible
because GRUB will wait for passphrase to unlock encrypted container.
[toc] | [prev] | [next] | [standalone]
| From | Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> |
|---|---|
| Date | 2018-09-15 18:00 +0200 |
| Subject | Re: ext2 for /boot ??? |
| Message-ID | <wyl9f-6FI-11@gated-at.bofh.it> |
| In reply to | #200156 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 15/09/18 16:48, Pascal Hambourg wrote: > Le 15/09/2018 à 00:45, Matthew Crews a écrit : >> On Friday, September 14, 2018 10:58 AM, Pascal Hambourg >> <pascal@plouf.fr.eu.org> wrote: >> >>> Actually you can have / including /boot on LUKS with GRUB. It >>> is just not natively supported by the Debian installer. >> >> Oh really? I might need to look into that. Where can I learn >> more? > > You must add GRUB_ENABLE_CRYPTODISK=y into /etc/default/grub > before running grub-install and update-grub/grub-mkconfig. Quote > from https://www.gnu.org/software/grub/manual/grub/grub.html : > > ‘GRUB_ENABLE_CRYPTODISK’ > > If set to ‘y’, grub-mkconfig and grub-install will check for > encrypted disks and generate additional commands needed to access > them during boot. Note that in this case unattended boot is not > possible because GRUB will wait for passphrase to unlock encrypted > container. Interesting, when does grub get dropbear ssh equivalent, so that it can be headless and have the crypted volume unlocked at boot using ssh? Cheers A. -----BEGIN PGP SIGNATURE----- iF0EAREIAAYFAludKqoACgkQqBZry7fv4vsUgQD/YVK+GOY5aJg0QhY0ezi57U5P H8WUvi8rl1FwxGWk8ZEA92KOb9I5BdSNaIEg00zPcLY6CVBjbQ9snUF/52pPWkQ= =xM38 -----END PGP SIGNATURE-----
[toc] | [prev] | [next] | [standalone]
| From | deloptes <deloptes@gmail.com> |
|---|---|
| Date | 2018-09-16 00:00 +0200 |
| Subject | Re: ext2 for /boot ??? |
| Message-ID | <wyqLD-1vo-5@gated-at.bofh.it> |
| In reply to | #200176 |
Andrew McGlashan wrote: > Interesting, when does grub get dropbear ssh equivalent, so that it > can be headless and have the crypted volume unlocked at boot using ssh? I also wish I knew how to get ssh into initrd and the whole networking, so that I could do it remotely when needed.
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2018-09-16 00:50 +0200 |
| Subject | Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? |
| Message-ID | <wyry2-1ZP-9@gated-at.bofh.it> |
| In reply to | #200185 |
Hello,
On Sat, Sep 15, 2018 at 11:52:01PM +0200, deloptes wrote:
> I also wish I knew how to get ssh into initrd and the whole networking, so
> that I could do it remotely when needed.
I've never done it myself, as I have IPMI access to anything I care
about, but it appears to be as simple as installing and configuring
the dropbear-initramfs package. This guide is for Ubuntu but looks
like it would translate to Debian well:
https://hamy.io/post/0009/how-to-install-luks-encrypted-ubuntu-18.04.x-server-and-enable-remote-unlocking/
Also:
https://wiki.debian.org/RescueInitramfs
I've also heard of people who use key/value stores or software
password safes or whatever to request the passphrase at boot time in
order to do completely automated boots.
The obvious problem there is an attacker who gets hold of the
initramfs in order to be able to use the credentials to request the
passphrase themselves. For those who wanted to get more elaborate
(and more likely to mess up and leave their server a useless
encrypted brick), there are things like Mandos:
https://wiki.recompile.se/wiki/Mandos
https://www.recompile.se/mandos/man/intro.8mandos
"This is the the Mandos system, which allows computers to have
encrypted root file systems and at the same time be capable of
remote and/or unattended reboots.
The computers run a small client program in the initial RAM disk
environment which will communicate with a server over a network.
All network communication is encrypted using TLS. The clients
are identified by the server using an OpenPGP key; each client
has one unique to it. The server sends the clients an encrypted
password. The encrypted password is decrypted by the clients
using the same OpenPGP key, and the password is then used to
unlock the root file system, whereupon the computers can
continue booting normally."
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Please consider the environment before reading this e-mail.
— John Levine
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2018-09-17 20:10 +0200 |
| Subject | Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? |
| Message-ID | <wz68a-v1-7@gated-at.bofh.it> |
| In reply to | #200186 |
Le 16/09/2018 à 00:39, Andy Smith a écrit : > > The obvious problem there is an attacker who gets hold of the > initramfs in order to be able to use the credentials to request the > passphrase themselves. For those who wanted to get more elaborate > (and more likely to mess up and leave their server a useless > encrypted brick), there are things like Mandos: > > https://wiki.recompile.se/wiki/Mandos > > https://www.recompile.se/mandos/man/intro.8mandos > > "This is the the Mandos system, which allows computers to have > encrypted root file systems and at the same time be capable of > remote and/or unattended reboots. > > The computers run a small client program in the initial RAM disk > environment which will communicate with a server over a network. > All network communication is encrypted using TLS. The clients > are identified by the server using an OpenPGP key; each client > has one unique to it. The server sends the clients an encrypted > password. The encrypted password is decrypted by the clients > using the same OpenPGP key, and the password is then used to > unlock the root file system, whereupon the computers can > continue booting normally." How dos this address the above concern ?
[toc] | [prev] | [next] | [standalone]
| From | deloptes <deloptes@gmail.com> |
|---|---|
| Date | 2018-09-17 20:20 +0200 |
| Subject | Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? |
| Message-ID | <wz6hP-yg-1@gated-at.bofh.it> |
| In reply to | #200233 |
Pascal Hambourg wrote: > How dos this address the above concern ? IMO this is not applicable when my server has to use encrypted root, which I would be able to decrypt via SSH at boot. The question is what do I gain when boot is not encrypted and I have there my SSH key and password and so on. I wanted to have a look at this link, that someone mentioned: https://hamy.io/post/0009/how-to-install-luks-encrypted-ubuntu-18.04.x-server-and-enable-remote-unlocking/ It seems to address the question above and it looks promising regards
[toc] | [prev] | [next] | [standalone]
| From | Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> |
|---|---|
| Date | 2018-09-18 20:10 +0200 |
| Subject | Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? |
| Message-ID | <wzsBI-5m3-7@gated-at.bofh.it> |
| In reply to | #200234 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 18/09/18 04:15, deloptes wrote: > I wanted to have a look at this link, that someone mentioned: > https://hamy.io/post/0009/how-to-install-luks-encrypted-ubuntu-18.04.x - -server-and-enable-remote-unlocking/ > > It seems to address the question above and it looks promising That link does, essentially, what I have been doing for a while -- NO ENCRYPTION of /boot .... I was hoping for a grub option to include dropbear ssh .... not included in initramfs Thanks anyway Cheers -----BEGIN PGP SIGNATURE----- iF4EAREIAAYFAluhPSoACgkQqBZry7fv4vujZAD+Nw/iemd8YwI13YnSxxYV8X2M +FTHl+Th4rXs83vmM6ABAM8r5dBRRbnHHFZXFM/jF76WNMc1/Z/fdd1ukrnHbBBX =cxZD -----END PGP SIGNATURE-----
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2018-09-19 05:00 +0200 |
| Subject | Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? |
| Message-ID | <wzASB-1ID-1@gated-at.bofh.it> |
| In reply to | #200233 |
Hello,
On Mon, Sep 17, 2018 at 08:00:50PM +0200, Pascal Hambourg wrote:
> Le 16/09/2018 à 00:39, Andy Smith a écrit :
> >
> >The obvious problem there is an attacker who gets hold of the
> >initramfs in order to be able to use the credentials to request the
> >passphrase themselves.
[…]
> > https://wiki.recompile.se/wiki/Mandos
> How dos this address the above concern ?
It is of course impossible to have both entirely automated unlocking
and perfect protection against someone taking the credentials from
the unencrypted bootstrap environment.
Having a script in your initramfs that unlocks your encrypted
filesystem provides no protection at all from someone who obtains a
copy of your initramfs and your encrypted filesystem.
You could add some more protection by using an online key/value
store instead of hard-coded credentials, since the key/value server
could also enforce things other than simple access to a file. For
example, it could require the request to come from a certain IP
address.
Using something like Mandos is another step along this path, by
requiring the unlock attempt to come within some short time period
since the last time your server checked in. It has shifted the
requirements from "have a copy of the encrypted filesystem and a
copy of the initramfs" to "have a copy of the encrypted filesystem
and the initramfs and be able to talk to the Mandos server from the
correct IP address within the required time interval". All it can do
is make the attack harder, not make it impossible.
It also clearly adds a lot of opportunities for you to permanently
lock yourself out of the encrypted filesystem by accident, unless
you take the precaution of having another set of credentials for
"emergency manual unlock" that you keep elsewhere.
An attacker who is aware of requirements such as where the secrets
server is, how to interact with it, where requests must come from,
time window in which requests must be made, etc is not going to be
defeated. Mandos's argument seems to be that such attackers are rare
and will probably just use the law or techniques like memory dumping
in preference to all that anyway.
https://www.recompile.se/mandos/man/intro.8mandos
"FREQUENTLY ASKED QUESTIONS
Couldn't the security be defeated by…
Grabbing the Mandos client key from the initrd really quickly?
This, as mentioned above, is the only real weak point. But if
you set the timing values tight enough, this will be really
difficult to do. An attacker would have to physically
disassemble the client computer, extract the key from the
initial RAM disk image, and then connect to a still online
Mandos server to get the encrypted key, and do all this before
the Mandos server timeout kicks in and the Mandos server refuses
to give out the key to anyone.
Now, as the typical procedure seems to be to barge in and turn
off and grab all computers, to maybe look at them months later,
this is not likely. If someone does that, the whole system will
lock itself up completely, since Mandos servers are no longer
running.
For sophisticated attackers who could do the clever thing, and
had physical access to the server for enough time, it would be
simpler to get a key for an encrypted file system by using
hardware memory scanners and reading it right off the memory
bus."
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
[toc] | [prev] | [next] | [standalone]
| From | Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> |
|---|---|
| Date | 2018-09-19 17:50 +0200 |
| Subject | Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? |
| Message-ID | <wzMTL-m6-1@gated-at.bofh.it> |
| In reply to | #200290 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/19/2018 02:57 AM, Andy Smith wrote: > For sophisticated attackers who could do the clever thing, and had > physical access to the server for enough time, it would be simpler > to get a key for an encrypted file system by using hardware memory > scanners and reading it right off the memory bus." Another attack would be to note the exact time that you removed the servers, then when you wish to talk with them again, set up an NTP server to provide the old time (intercepting any requests trying to get the time from another server of course). Mandos does sound interesting though, but I don't think I'll be using it. Especially if it is possible to easily lock yourself out! Cheers AbndrewM -----BEGIN PGP SIGNATURE----- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCW6JvcgAKCRCoFmvLt+/i ++WrAPsFm6b0dUqtHGh3S4Nhyyc5nL2M6vyi880aAJwF3wHXIgEAxxtdKZAdePqQ aGe8EMYKDRsjhkP9Mxd74qtxVZ8S58E= =2TGh -----END PGP SIGNATURE-----
[toc] | [prev] | [next] | [standalone]
| From | Igor Cicimov <icicimov@gmail.com> |
|---|---|
| Date | 2018-09-26 01:10 +0200 |
| Subject | Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? |
| Message-ID | <wC4CR-852-5@gated-at.bofh.it> |
| In reply to | #200290 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, 19 Sep 2018 12:58 pm Andy Smith <andy@strugglers.net> wrote: > Hello, > > On Mon, Sep 17, 2018 at 08:00:50PM +0200, Pascal Hambourg wrote: > > Le 16/09/2018 à 00:39, Andy Smith a écrit : > > > > > >The obvious problem there is an attacker who gets hold of the > > >initramfs in order to be able to use the credentials to request the > > >passphrase themselves. > > […] > > > > https://wiki.recompile.se/wiki/Mandos > > > How dos this address the above concern ? > > It is of course impossible to have both entirely automated unlocking > and perfect protection against someone taking the credentials from > the unencrypted bootstrap environment. > > Having a script in your initramfs that unlocks your encrypted > filesystem provides no protection at all from someone who obtains a > copy of your initramfs and your encrypted filesystem. > > You could add some more protection by using an online key/value > store instead of hard-coded credentials, since the key/value server > could also enforce things other than simple access to a file. For > example, it could require the request to come from a certain IP > address. > > Using something like Mandos is another step along this path, by > requiring the unlock attempt to come within some short time period > since the last time your server checked in. It has shifted the > requirements from "have a copy of the encrypted filesystem and a > copy of the initramfs" to "have a copy of the encrypted filesystem > and the initramfs and be able to talk to the Mandos server from the > correct IP address within the required time interval". All it can do > is make the attack harder, not make it impossible. > > It also clearly adds a lot of opportunities for you to permanently > lock yourself out of the encrypted filesystem by accident, unless > you take the precaution of having another set of credentials for > "emergency manual unlock" that you keep elsewhere. > > An attacker who is aware of requirements such as where the secrets > server is, how to interact with it, where requests must come from, > time window in which requests must be made, etc is not going to be > defeated. Mandos's argument seems to be that such attackers are rare > and will probably just use the law or techniques like memory dumping > in preference to all that anyway. > > https://www.recompile.se/mandos/man/intro.8mandos > > "FREQUENTLY ASKED QUESTIONS > > Couldn't the security be defeated by… > > Grabbing the Mandos client key from the initrd really quickly? > > This, as mentioned above, is the only real weak point. But if > you set the timing values tight enough, this will be really > difficult to do. An attacker would have to physically > disassemble the client computer, extract the key from the > initial RAM disk image, and then connect to a still online > Mandos server to get the encrypted key, and do all this before > the Mandos server timeout kicks in and the Mandos server refuses > to give out the key to anyone. > > Now, as the typical procedure seems to be to barge in and turn > off and grab all computers, to maybe look at them months later, > this is not likely. If someone does that, the whole system will > lock itself up completely, since Mandos servers are no longer > running. > > For sophisticated attackers who could do the clever thing, and > had physical access to the server for enough time, it would be > simpler to get a key for an encrypted file system by using > hardware memory scanners and reading it right off the memory > bus." > > Cheers, > Andy > > -- > https://bitfolk.com/ -- No-nonsense VPS hosting > An example for automation with AWS using SSM and KMS services https://icicimov.github.io/blog/server/LUKS-with-AWS-SSM-and-KMS-in-Systemd/ It can be modified for initramfs. >
[toc] | [prev] | [next] | [standalone]
| From | deloptes <deloptes@gmail.com> |
|---|---|
| Date | 2018-09-26 18:20 +0200 |
| Subject | Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? |
| Message-ID | <wCkHE-CU-5@gated-at.bofh.it> |
| In reply to | #200621 |
Igor Cicimov wrote: > An example for automation with AWS using SSM and KMS services > https://icicimov.github.io/blog/server/LUKS-with-AWS-SSM-and-KMS-in-Systemd/ > It can be modified for initramfs. so how can we do it with initram and without some external key server? Imagine I have only boot not encrypted on the server. I want to boot the machine and get a prompt via SSH or something like SSH, where I can type in the password and decrypt root and all other volumes. I do not want to store password or anything sensitive in the boot directory. I can imagine one time ssh created when you try to login, but it is still not secure enough. Can you help with some thoughts on how to implement it? thanks
[toc] | [prev] | [next] | [standalone]
| From | Jonathan Dowland <jmtd@debian.org> |
|---|---|
| Date | 2018-09-26 19:20 +0200 |
| Subject | Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? |
| Message-ID | <wClDH-1aa-1@gated-at.bofh.it> |
| In reply to | #200658 |
On Wed, Sep 26, 2018 at 06:14:42PM +0200, deloptes wrote: >so how can we do it with initram and without some external key server? >Imagine I have only boot not encrypted on the server. >I want to boot the machine and get a prompt via SSH or something like SSH, >where I can type in the password and decrypt root and all other volumes. >I do not want to store password or anything sensitive in the boot directory. >I can imagine one time ssh created when you try to login, but it is still >not secure enough. What you describe is exactly how the dropbear/initramfs integration works. The data stored in /boot is the initramfs, and within that, the only material you might consider sensitive is an SSH server keypair (public&private) for the SSHD instance in the initramfs environment - this does not need to be the same as for your running system; and an authorized_keys file, containing your SSH *public* key. Are those too sensitive for you? I suspect you could probably do without the SSHD public/private keypair and have the initramfs environment generate a new pair each time, but then you'd have no chain of trust for connecting to it; so you have to weigh up those two scenarios. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.
[toc] | [prev] | [next] | [standalone]
| From | deloptes <deloptes@gmail.com> |
|---|---|
| Date | 2018-09-26 20:20 +0200 |
| Subject | Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? |
| Message-ID | <wCmzL-1IH-1@gated-at.bofh.it> |
| In reply to | #200660 |
Jonathan Dowland wrote: > What you describe is exactly how the dropbear/initramfs integration > works. The data stored in /boot is the initramfs, and within that, the > only material you might consider sensitive is an SSH server keypair > (public&private) for the SSHD instance in the initramfs environment - > this does not need to be the same as for your running system; and an > authorized_keys file, containing your SSH *public* key. Are those too > sensitive for you? > thanks I read and this is what I think. I wanted to know how the other project can be adapted. I think dropbear is very close to what I wanted to have. > I suspect you could probably do without the SSHD public/private keypair > and have the initramfs environment generate a new pair each time, but > then you'd have no chain of trust for connecting to it; so you have to > weigh up those two scenarios. Yes it is two faces of same evil, but I would trust the guys behind dropbear and adopt what they suggest. regards
[toc] | [prev] | [next] | [standalone]
| From | Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> |
|---|---|
| Date | 2018-09-27 10:00 +0200 |
| Subject | Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ??? |
| Message-ID | <wCznj-EB-1@gated-at.bofh.it> |
| In reply to | #200660 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 27/09/18 03:17, Jonathan Dowland wrote: > On Wed, Sep 26, 2018 at 06:14:42PM +0200, deloptes wrote: >> so how can we do it with initram and without some external key >> server? Imagine I have only boot not encrypted on the server. I >> want to boot the machine and get a prompt via SSH or something >> like SSH, where I can type in the password and decrypt root and >> all other volumes. I do not want to store password or anything >> sensitive in the boot directory. I can imagine one time ssh >> created when you try to login, but it is still not secure >> enough. > > What you describe is exactly how the dropbear/initramfs > integration works. The data stored in /boot is the initramfs, and > within that, the only material you might consider sensitive is an > SSH server keypair (public&private) for the SSHD instance in the > initramfs environment - this does not need to be the same as for > your running system; and an authorized_keys file, containing your > SSH *public* key. Are those too sensitive for you? The biggest weakness with the Dropbear setup is that the initramfs is stored on an unencrypted partition (no matter which file system is used). That means that someone with physical access can rebuild the initramfs and include their own key as well as other stuff to compromise the security of the server. Aside from the fact that the IME is suspect, it would be great if grub can be, somehow, given a method that allows for full disk encryption which will include everything in /boot -- especially initramfs. Even so, then grub might have another attack vector of itself. But it would at least allow for encrypted /boot ... Kind Regards AndrewM -----BEGIN PGP SIGNATURE----- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCW6yMrQAKCRCoFmvLt+/i +xPvAQCW/jz4Iq50mRaz4hJrUWIKqbJ/iUpCCcMXntPfcZDwRwD/SuPsHGGVjMCi 1Vk/BfTPN27cRE3CtHIntxItupUqzJ0= =7lcL -----END PGP SIGNATURE-----
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | linux.debian.user
csiph-web