Hello!

I have an idea about how modern linux should work with encrypted LUKS partitions.

Right now on a system encrypted with LUKS, the first prompt you'll see is a grub passphrase to unlock the device, after OS boot you see a second prompt
for login/password. This looks redundant.

How about bypassing the second prompt and allowing grub to handle all
security prompts including the login/password and unlocking the LUKS at the same time? It can be done with few steps:

1) grub can ask for a login/password, then MD5 the text and unlock the LUKS device using this MD5 passphrase: md5(login+password) or using a simple plain(login+password) string.

2) grub passing this information (login/password) to the kernel.

3) Kernel boots and passing (or password manager service, which can be part
of systemd) reads that data from kernel (/proc/cmdline) and rewrites it
(hide for security reasons).

4) password manager (systemd service) makes login manager (gdm) auto login
with provided data and unlocking session (gnome) keyring.

5) if the user updates the password (passwd, chpasswd), then the password manager updates LUKS corresponding slot with md5(login+password) or plain(login+password) passphrase.

Since LUKS1 supports 8 keys, we can support only 8 logins which can open a drive and automatically login to the system. Also password manager has to associate every user (UID) with LUKS device UUID and slot number for simple
key updates.Another option: we can use one SLOT0 or masterkey with a
different technique for encrypting keys and storing all users in the
encrypted list on ESP partition, this option has no user count limits.

I'm using full disk encryption (including /boot), except the ESP
(/boot/efi) partition for grub.img and other EFI binaries).

Theoretically it can work with legacy grub (stage2 compiled using modules
and grub.cfg (right?) which can be used to specify how we should unlock the device using passphrase or login/password) and the EFI option can read all configs from grub.cfg.

This is major changes to the linux password management. Can it be improved
and proposed as standard?

-- AK

<div dir="ltr">Hello!<br>

I have an idea about how modern linux should work with encrypted LUKS partitions.<br>

Right now on a system encrypted with LUKS, the first prompt you&#39;ll see is a grub
passphrase to unlock the device, after OS boot you see a second prompt
for login/password. This looks redundant.<br>

How about bypassing the second prompt and allowing grub to handle all security prompts including the login/password and unlocking the LUKS at the same time? It can be done with few steps:<br>

1) grub can ask for a login/password, then MD5 the text and unlock the LUKS device using this MD5 passphrase: md5(login+password) or
using a simple plain(login+password) string.<br>

2) grub passing this information (login/password) to the kernel.<br>

3) Kernel boots and passing (or password manager service, which can be part of systemd)
reads that data from kernel (/proc/cmdline) and rewrites it (hide for security reasons).<br>

4) password manager (systemd service) makes login manager (gdm) auto login with provided data and unlocking session (gnome) keyring.<br>

5) if the user updates the password (passwd, chpasswd), then the password manager updates LUKS
corresponding slot with md5(login+password) or plain(login+password) passphrase.<br>
<br><div>
Since LUKS1 supports 8 keys, we can support only 8 logins which can
open a drive and automatically login to the system. Also password manager has to associate every
user (UID) with LUKS device UUID and slot number for simple key updates.Another option: we can use one SLOT0 or masterkey with a different technique for encrypting keys
and storing all users in the encrypted list on ESP partition, this option has no user count limits.<br></div><div><br></div><div>I&#39;m using full disk encryption (including /boot), except the ESP (/boot/efi) partition for grub.img and other EFI
binaries).<br></div><div><br></div><div>Theoretically it can work with legacy grub (stage2 compiled using modules and grub.cfg (right?) which can be used to specify how we should unlock the device using passphrase or login/password) and the EFI option
can read all configs from grub.cfg.<br></div>
<br><div>
This is major changes to the linux password management. Can it be improved and proposed as standard?</div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">-- AK</div></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit :

Hello!

I have an idea about how modern linux should work with encrypted LUKS partitions.

Hi,

I'm using LUKS for a long time on both my personal (desktop) and
professional (laptop) computers. Since they are single user (me), I use autologin in the display manager, lightdm in my case. Because there is
only one slot configured in LUKS, I'm sure this is me, so lightdm can
autologin safely.

However, you are proposing to solve the case for multiple user
computers. In that case, I would think about a much simpler design:

- Remember which slot was used to unlock the LUKS root partition

- Make a map with slot -> user to autologin

- Autologin that user on boot

No more passing password, no more password update headache. But only a
root user can update the map "slot -> user".

Adrien

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Le 08/03/2023 à 16:28, Alexey Kuznetsov
a écrit :<br>
</div>
<blockquote type="cite" cite="mid:CAO1Zr+rqjpp75qm5U2JYM9uqffa6LHzqZWGrNMpbpAgrFWx1xw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hello!<br>
<br>
I have an idea about how modern linux should work with encrypted
LUKS partitions.<br>
</div>
</blockquote>
<p>Hi,</p>
<p>I'm using LUKS for a long time on both my personal (desktop) and
professional (laptop) computers. Since they are single user (me),
I use autologin in the display manager, lightdm in my case.
Because there is only one slot configured in LUKS, I'm sure this
is me, so lightdm can autologin safely.</p>
<p>However, you are proposing to solve the case for multiple user
computers. In that case, I would think about a much simpler
design:</p>
<p>- Remember which slot was used to unlock the LUKS root partition</p>
<p>- Make a map with slot -&gt; user to autologin</p>
<p>- Autologin that user on boot<br>
</p>
<p>No more passing password, no more password update headache. But
only a root user can update the map "slot -&gt; user".</p>
<p>Adrien<br>
</p>
<div id="grammalecte_menu_main_button_shadow_host" style="width:
0px; height: 0px;"></div>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 08/03/2023 à 17:11, Adrien CLERC a écrit :

Hello,

Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit :

Hello!

I have an idea about how modern linux should work with encrypted LUKS
partitions.

Hi,

I'm using LUKS for a long time on both my personal (desktop) and
professional (laptop) computers. Since they are single user (me), I
use autologin in the display manager, lightdm in my case. Because
there is only one slot configured in LUKS, I'm sure this is me, so
lightdm can autologin safely.

However, you are proposing to solve the case for multiple user
computers. In that case, I would think about a much simpler design:

- Remember which slot was used to unlock the LUKS root partition

- Make a map with slot -> user to autologin

- Autologin that user on boot

No more passing password, no more password update headache. But only a
root user can update the map "slot -> user".

The issue with this approach is that you still need to enter a password
for session keyrings (such as gnome-keyring).
Ideally, the LUKS password would be forwarded to PAM (and automatically
reused for logging in *and* unlocking the session keyring)

The issue is that the system (often plymouth on desktop/laptop setups)
would then need to:
* unlock the filesystem
* initialize PAM straight away
* check the user password
* raise an error if either of the above fails, potentially locking the filesystem again if the password/encryption key is valid but does not
match the selected user

Overall a nice idea, but not so simple to implement properly ;)

Cheers,
Arnaud

Adrien

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Alexey,

2023-03-08 16:45 CET, Alexey Kuznetsov:

Right now on a system encrypted with LUKS, the first prompt you'll see is a grub passphrase to unlock the device, after OS boot you see a second prompt for login/password. This looks redundant.

How about bypassing the second prompt and allowing grub to handle all security prompts including the login/password and unlocking the LUKS at the same time?

I disable the login password by connecting my user automatically on my
LUKS setup. It is a few clicks away in most DEs I would guess.

Did you consider this instead of implementing what you propose?

Bests,

Agathe.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Mar 8, 2023 at 7:08 PM Agathe Porte <debian@microjoe.org> wrote:

Hi Alexey,

2023-03-08 16:45 CET, Alexey Kuznetsov:

Right now on a system encrypted with LUKS, the first prompt you'll see

is a

grub passphrase to unlock the device, after OS boot you see a second

prompt

for login/password. This looks redundant.

How about bypassing the second prompt and allowing grub to handle all security prompts including the login/password and unlocking the LUKS at

the

same time?

I disable the login password by connecting my user automatically on my
LUKS setup. It is a few clicks away in most DEs I would guess.

Did you consider this instead of implementing what you propose?

Bests,

Agathe.

Yes I did. I did the same on my machine. I only type passpharse and initrd
have luks-key script, and gdm has autologin. But another notebook with LUKS setup has multiple users, so autologin will not work. This is not about autologin. This is about unlocking your machine LUKS with only
login/password without having an additional passphrase to remember.

<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 8, 2023 at 7:08 PM Agathe Porte &lt;<a href="mailto:debian@microjoe.org">debian@microjoe.org</a>&gt; wrote:<br></div><blockquote class="
gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Alexey,<br>

2023-03-08 16:45 CET, Alexey Kuznetsov:<br>
&gt; Right now on a system encrypted with LUKS, the first prompt you&#39;ll see is a<br>
&gt; grub passphrase to unlock the device, after OS boot you see a second prompt<br>
&gt; for login/password. This looks redundant.<br>
&gt;<br>
&gt; How about bypassing the second prompt and allowing grub to handle all<br> &gt; security prompts including the login/password and unlocking the LUKS at the<br>
&gt; same time?<br>

I disable the login password by connecting my user automatically on my<br>
LUKS setup. It is a few clicks away in most DEs I would guess.<br>

Did you consider this instead of implementing what you propose?<br>

Bests,<br>

Agathe.<br></blockquote><div><br></div><div>Yes I did. I did the same on my machine. I only type passpharse and initrd have luks-key script, and gdm has autologin. But another notebook with LUKS setup has multiple users, so autologin will not work. This
is not about autologin. This is about unlocking your machine LUKS with only login/password without having an additional passphrase to remember.</div><div><br></div></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Mar 8, 2023 at 7:11 PM Adrien CLERC <adrien@antipoul.fr> wrote:

Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit :

Hello!

I have an idea about how modern linux should work with encrypted LUKS partitions.

Hi,

I'm using LUKS for a long time on both my personal (desktop) and
professional (laptop) computers. Since they are single user (me), I use autologin in the display manager, lightdm in my case. Because there is only one slot configured in LUKS, I'm sure this is me, so lightdm can autologin safely.

However, you are proposing to solve the case for multiple user computers.
In that case, I would think about a much simpler design:

- Remember which slot was used to unlock the LUKS root partition

- Make a map with slot -> user to autologin

- Autologin that user on boot

No more passing password, no more password update headache. But only a
root user can update the map "slot -> user".

Adrien

Right. But you still have to remember passpharse and your main account password. This is not about autologin. This is about unlocking your machine LUKS with only login/password without having an additional passphrase to remember.

<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 8, 2023 at 7:11 PM Adrien CLERC &lt;<a href="mailto:adrien@antipoul.fr">adrien@antipoul.fr</a>&gt; wrote:<br></div><blockquote class="
gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>
<div>Le 08/03/2023 à 16:28, Alexey Kuznetsov
a écrit :<br>
</div>
<blockquote type="cite">

<div dir="ltr">Hello!<br>
<br>
I have an idea about how modern linux should work with encrypted
LUKS partitions.<br>
</div>
</blockquote>
<p>Hi,</p>
<p>I&#39;m using LUKS for a long time on both my personal (desktop) and
professional (laptop) computers. Since they are single user (me),
I use autologin in the display manager, lightdm in my case.
Because there is only one slot configured in LUKS, I&#39;m sure this
is me, so lightdm can autologin safely.</p>
<p>However, you are proposing to solve the case for multiple user
computers. In that case, I would think about a much simpler
design:</p>
<p>- Remember which slot was used to unlock the LUKS root partition</p>
<p>- Make a map with slot -&gt; user to autologin</p>
<p>- Autologin that user on boot<br>
</p>
<p>No more passing password, no more password update headache. But
only a root user can update the map &quot;slot -&gt; user&quot;.</p>
<p>Adrien<br></p></div></blockquote><div>Right. But you still have to remember passpharse and your main account password. This is not about autologin. This is about unlocking your machine
LUKS with only login/password without having an additional passphrase to
remember.<div class="gmail-yj6qo"></div><div class="gmail-adL"><br><br></div></div><div> <br></div></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mar 08, Alexey Kuznetsov <kuznetsov.alexey@gmail.com> wrote:

1) grub can ask for a login/password, then MD5 the text and unlock the LUKS

Forget about this part: encrypted /boot/ is pointless from a security
point of view and this complexity does not belong in the boot loader.

Once you accept this then you will end up with a design very similar to https://www.freedesktop.org/wiki/Specifications/login-unlock/ .

So you would need to implement having Plymouth or whatever else storing
the credentials in the kernel keyring and then probably a PAM module
that will make them available to the rest of the stack (notably pam_gnome_keyring).

--
ciao,
Marco

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQnKUXNg20437dCfobLPsM64d7XgQUCZAjYagAKCRDLPsM64d7X gR16AP9tVFKyU2p29zerIV1jdmDHxGlSZRu5CIMQD4WoklAhigEAp1pxpEtU1XxM xMoQkwYuVgKPoCnhObwzVJqhFNpdWQU=
=Kr7W
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

That is also the main reason why I do not use automatic login. I need
to enter the password anyway.

Unfortunately, the same is true for smartcard login. An OpenPGP
smartcard would be perfect for both login (including SSH public key
auth) and unlocking the keyring, even better than a password, but that
has not been implemented.

Regards

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Can you explain or refer to literature why encrypted /boot is
pointless?

Regards

PS: Let's for now ignore non-security benefits, e.g. that encrypted
/boot means that you do not have to decide on the size of your /boot
partition.

-----BEGIN PGP SIGNATURE-----

iIwEABYIADQWIQRB1rjSpCJd8a7h6mNgNUJZCjx8YgUCZAl61hYcdmVyYnVlY2hl bG5AcG9zdGVvLmRlAAoJEGA1QlkKPHxiscsA/1SlGmsCFqvyrVwojHPgBbhG/R/J 3KEcF2qGkA9Vd2rmAP9G0Esq9+PViNMyC4lji2uQuhjrdKVDJWQTbfTozVFhCA==
=DUz0
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-03-09 06:21:10 +0000 (+0000), Stephan Verbücheln wrote:

Can you explain or refer to literature why encrypted /boot is
pointless?

[...]

Doesn't really need literature, just some rational thought.

People often confuse encryption with attestation. Try to explain
what security benefits you gain from keeping the contents of /boot
secret.

Sure, you don't want someone with physical access to the machine
changing the files in /boot in order to backdoor the system startup
process, but you don't need to encrypt the contents to gain that
property. Attestation (a.k.a. "secure boot") relies on cryptographic
signatures to avoid using files which have been altered, regardless
of whether /boot has been encrypted:

https://wiki.debian.org/SecureBoot

But take it a step further, if someone has extended physical access
to your machine, it's pretty easy to (depending on the device) add
a hardware keylogger, packet sniffer, other circuits which can even
supply the attacker with reverse-tunneled remote access once you've
unlocked and booted the machine.

Disk encryption is great (when properly implemented) to protect
sensitive information on your machine from prying eyes if it gets
stolen, but unless you're putting sensitive data in /boot why go to
the added trouble of encrypting it?
--
Jeremy Stanley

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmQJ3PZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCla3Q//f+fyVxUj8yWbCWTvYHx3vKib393R8sY/59DZPzoFZCl1QLwQ/IeK2KEb bRgs2Cq12PW0WsGRpYUfCJYmxJW0pO8+JnjkLcxdhb1jCz6kg5ud3aadW/htSlaM ih3KZumCl2jvQS7hlygU1c+6cPuym0j9gndDwvqmLyJJHj9Gq5MAYRw1KEc3B2At 8Hd7VvJDCpRaeCyq9RdM9zNG27hJrJT5b0ggZe2xKFneVvDDvbEWY+E6xaBB0jli jLyhQ59E/F7z3Zw/gzh8Rn6m3gCrXAckufyaV2yFAELc2yzVengmKtpWUT641H7/ DMfSozivyikPlfbuODxDwheTj3saLbXn0HMg2TPmr5HDrn7D28F9z4JKXHzXrt+U nVDrmERJHq+AfKiDR9IaMXoKR3q/PyIu7M4O5LVsv2OK3lQyFUXZmezF41vGaFc/ +fWFOmP9tZssuqiRz2E2VeaOUsTNlElLzB7rc0k0Hm56fNxg4mYImhaxzpkpMROm Xhn9ZzT4McFdWcU1oIswv/6d8NsKLFgObTRe24MDAh5bVB59qcvrTqMY+NaCjz2f Iw2hpShDWcAJwfvbRnY+ywusDFTNRSXUuHwYo/VImSciTu3ADOpKrfsWdimyY9VE mbcNcGpSasRvpZeu5E0MJvlLyIZOTGwG/5u+zigAMkpr7SfqdT0=
=uQQY
-----END PGP SIGNATURE-----

--- SoupGate-Win32

Jeremy Stanley <fungi@yuggoth.org> writes:

Disk encryption is great (when properly implemented) to protect
sensitive information on your machine from prying eyes if it gets
stolen, but unless you're putting sensitive data in /boot why go to the
added trouble of encrypting it?

I think this is the key point: you should not be putting sensitive data in /boot, and this is generally always avoidable (and architecturally better
to put it elsewhere).

I have put sensitive data in /boot in the past because reasons, so it's
not strictly true there is *never* a benefit, but I agree that this wasn't
a great architecture and there were better ways to do it.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Encryption per se does not protect against modification, I am aware of
that. That is even more true for disk encryption where the encrypted
data block has to fit into the physical disk block, so there is no room
for a MAC or signature. However, in combination with a filesystem like
btrfs which checksums everything, it is providing some protection, even
though it was not designed for that purpose.

Apart from the fact that UEFI Secure Boot is an overly complex monster
which is basically broken[1] by design, my understanding of it is also
that it does not protect configs, initramfs etc. in /boot. It only
protects the kernel image and loaded modules.

[1] https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/

In addition, files in /boot like the initrd are generated individually
and may contain files not limited to what someone puts into /boot intentionally. In contrast to /boot/efi, /boot does not only contain
static files delivered by the distribution.

Regards
Stephan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-03-10 13:48:21 +0000 (+0000), Stephan Verbücheln wrote:

Encryption per se does not protect against modification, I am aware of
that. That is even more true for disk encryption where the encrypted
data block has to fit into the physical disk block, so there is no room
for a MAC or signature. However, in combination with a filesystem like
btrfs which checksums everything, it is providing some protection, even though it was not designed for that purpose.

Okay, so you're wanting to rely on encrypted /boot as an incomplete
alternative to checking file signatures, because the current
attestation solutions are also imperfect. Keep in mind that
checksumming isn't providing protection from coherent modification
of the decrypted filesystem and checksums, it's just protecting
against someone blindly modifying the encrypted blocks. If they have
physical access to your system sufficient to modify firmware or add
hardware without you noticing, then encrypted /boot is pretty
pointless against such an actor.

Apart from the fact that UEFI Secure Boot is an overly complex monster
which is basically broken[1] by design, my understanding of it is also
that it does not protect configs, initramfs etc. in /boot. It only
protects the kernel image and loaded modules.

[1] https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/

Well, it's not as if encrypted /boot is protecting you from the
attacks described in that article either. Someone with that level of
access to your system can quite easily record/copy your decryption
keys, or simply wait until you've unlocked your sensitive data.

In addition, files in /boot like the initrd are generated individually
and may contain files not limited to what someone puts into /boot intentionally. In contrast to /boot/efi, /boot does not only contain
static files delivered by the distribution.

Sure, if you're concerned that sensitive information is being put in
/boot sufficient to warrant the additional work of protecting it
from disclosure when someone steals the device or gets their hands
on the drive after disposal, then by all means go ahead. It's just
not usually worth that amount of additional complexity.

It comes down to basic cost/benefit analysis, and deciding what
threats you reasonably want to invest in defending against. I'm
certainly not saying there's *never* a reason to encrypt /boot, but
people who feel they need to do so aren't involved in improving
tools and automation sufficiently to make it convenient to set up
either.
--
Jeremy Stanley

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmQLPphfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCmYDA//bR9SMiQVDqy7+syUa4/GVAh0PHvRsZujcsYP27klY9W7HCL4PraT1tfW Q3DnSz/aKD97+tN0CYKEk5ZANisen0DfyJ4H4TS1o/adb2IWL9tTyWxwuXK7ox+l kjrD7DZD0zRu7/uCRDBJc0haai6BnsNSQPyZax9rFjNP6INgPgNfyxmKroZFzmIJ 6iL75TS8CUGLhsYlya+sHn2Lb70tbu0LT0CCV4YPevyELlxhkpxh9U5HhY8E3Upt b5rmd7pJRdQanMZnAOtk3U0DyDUQPv9XH+9hjxPgdLDbEihEkyoXZvxQJiExCEFo QFva6jwaCbc7YbR2ZSbRlLQJPtYQXShGhhQxSh3YbIrnAE2C4PnrfegB0EJ0jEzb wipcPsC6AISuT1QWNEHrpSyVzGcViynU99ADWN7FDDYisM0MTF++LB5JEayxZowu Yl5jeT2NIdUyWFgpF83ImNqoknOMViqbwDS8ZxkBv9x5+nwZWkrv+TO3Bgr/WhL4 GqA9A+WMdFs9kOLkZUXRveyMku3gBTpdJS0vAC3tkFPLqkHs2RfSg0n7LozzaIEc Iq0kAh60qZS1CCuKXPxawOLnmpJFjOqu1GR0S8syEKH17A7TTChPYp0CBzOYEjVB lD5CQemOuUDCCtqup89JaCh/YEVJe5IJLsPPeOFvSbT+oHj+v9I=
=wrvQ
-----END PGP SIGNATURE-----

--- SoupGate-Win32

On Mar 10, Stephan Verbücheln <verbuecheln@posteo.de> wrote:

Apart from the fact that UEFI Secure Boot is an overly complex monster
which is basically broken[1] by design, my understanding of it is also
that it does not protect configs, initramfs etc. in /boot. It only
protects the kernel image and loaded modules.

It can, with an appropriate configuration.

In addition, files in /boot like the initrd are generated individually
and may contain files not limited to what someone puts into /boot intentionally. In contrast to /boot/efi, /boot does not only contain
static files delivered by the distribution.

In the future the initramfs will (usually) be static as well.

--
ciao,
Marco

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQnKUXNg20437dCfobLPsM64d7XgQUCZAs6xQAKCRDLPsM64d7X gSzqAQCFeJB/0z+d6txdB2rjlyYsvlu5RfkYyGNK5V/2GSTg6QEAoqoajwAr09JJ 2kuZVDuX/0cVLH9BplAubFZihRUGTgQ=
=tTWa
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 2023-03-10 at 14:28 +0000, Jeremy Stanley wrote:

Okay, so you're wanting to rely on encrypted /boot as an incomplete alternative to checking file signatures, because the current
attestation solutions are also imperfect. Keep in mind that
checksumming isn't providing protection from coherent modification
of the decrypted filesystem and checksums, it's just protecting
against someone blindly modifying the encrypted blocks.

No, this is not about blind modification. There are relevant attacks in
this area.

https://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/

If they have
physical access to your system sufficient to modify firmware or add
hardware without you noticing, then encrypted /boot is pretty
pointless against such an actor.

The only thing an attacker can modify in software is the GRUB binary in /boot/efi. The GRUB binary can be more easily verified by Secure Boot
and it is where I enter my LUKS passphrase.

Well, it's not as if encrypted /boot is protecting you from the
attacks described in that article either. Someone with that level of
access to your system can quite easily record/copy your decryption
keys, or simply wait until you've unlocked your sensitive data.

Hardware modifications are not a fair comparison. Hardware
modifications can always replace anything with anything that looks
alike.

Sure, if you're concerned that sensitive information is being put in
/boot sufficient to warrant the additional work of protecting it

What additional work? The installer did it automatically without me
even noticing for years.
Having a separate /boot partition is actually more work. You need to
decide on the required size, choose an appropriate filesystem etc.

from disclosure when someone steals the device or gets their hands
on the drive after disposal, then by all means go ahead. It's just
not usually worth that amount of additional complexity.

Any installed program that is not in the essential setup should be
considered sensitive information.

It comes down to basic cost/benefit analysis, and deciding what
threats you reasonably want to invest in defending against. I'm
certainly not saying there's *never* a reason to encrypt /boot, but
people who feel they need to do so aren't involved in improving
tools and automation sufficiently to make it convenient to set up
either.

There is nothing inconvenient about it.

Regards

-----BEGIN PGP SIGNATURE-----

iIwEABYIADQWIQRB1rjSpCJd8a7h6mNgNUJZCjx8YgUCZAtH2RYcdmVyYnVlY2hl bG5AcG9zdGVvLmRlAAoJEGA1QlkKPHxibJIBALr7Cmwa7UZtv9htTV07eJmilWvh RJUmHfdJBR8N4LG2AP9Nvtmkvvjx9btLonObEneRsIFfmhI17l2v9V6uxIogBQ==
=KW7G
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 2023-03-10 at 15:12 +0100, Marco d'Itri wrote:

In the future the initramfs will (usually) be static as well.

Can you provide more information on that?

Thanks and regards
Stephan


-----BEGIN PGP SIGNATURE-----

iIwEABYIADQWIQRB1rjSpCJd8a7h6mNgNUJZCjx8YgUCZAtNFRYcdmVyYnVlY2hl bG5AcG9zdGVvLmRlAAoJEGA1QlkKPHxijLABAPOQ6qHF4xpVoktRsMLHX6T2MiPc Zjj/VR1KUk2KTwNsAP9Urm4OCvLOPcrunfCgDoiu8fy5u9zjuFZ/vJOI85TECA==
=/BHc
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mar 10, Stephan Verbücheln <verbuecheln@posteo.de> wrote:

On Fri, 2023-03-10 at 15:12 +0100, Marco d'Itri wrote:

In the future the initramfs will (usually) be static as well.

Can you provide more information on that?

Due to multiple reasons, mostly related to secure boot and boot
attestation, there is significant interest by distributions in providing static and signed initrds.
BTW, I have been informed that "initramfs" is an obsolete term and that
we are back to "initrd" like in the '90s.

Some people in Debian are interested in working on https://github.com/systemd/mkosi-initrd, which will provide a static
initrd built from system binaries and extensible using the
systemd-sysext and future systemd-sysconf mechanisms for things like
SAN boot or sshd in the initrd.
Do not look too hard at it at this point: the upstream developers are
going to make soon a new release with significant changes.

I expect that people interested in working on initramfs-tools can
probably extend it with little work to generate static images suitable
for the most common deployments.
People with uncommon ones will have to do without the modern boot
attestation features or else sign their own images (which will be very
easy once I, or somebody else, will have packaged sbctl).
Obviously there are no new requirements for the systems without secure
boot.

--
ciao,
Marco

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQnKUXNg20437dCfobLPsM64d7XgQUCZAthhAAKCRDLPsM64d7X gU2QAQD4ZJIdhyPmBA1cyMdfeTGdTmj1SagcZAKfU6KdEUytrQD/eWvepLDJvhlv fU/oPaGPtl27zg5Gv0/STqDP33rmFQk=
=0tPX
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Mar 8, 2023 at 11:33 AM Alexey Kuznetsov <kuznetsov.alexey@gmail.com> wrote:

On Wed, Mar 8, 2023 at 7:11 PM Adrien CLERC <adrien@antipoul.fr> wrote:

Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit :

Hello!

I have an idea about how modern linux should work with encrypted LUKS
partitions.

Hi,

I'm using LUKS for a long time on both my personal (desktop) and
professional (laptop) computers. Since they are single user (me), I use
autologin in the display manager, lightdm in my case. Because there is only >> one slot configured in LUKS, I'm sure this is me, so lightdm can autologin >> safely.

However, you are proposing to solve the case for multiple user computers.
In that case, I would think about a much simpler design:

- Remember which slot was used to unlock the LUKS root partition

- Make a map with slot -> user to autologin

- Autologin that user on boot

No more passing password, no more password update headache. But only a
root user can update the map "slot -> user".

Adrien

Right. But you still have to remember passpharse and your main account password. This is not about autologin. This is about unlocking your machine LUKS with only login/password without having an additional passphrase to remember.

The reason you can not use Login/Password as the LUKS passphrase is because
The Passphrase can not be different for different users. The passphrase is
not simply a password but instead it is part of the key material used to decrypt and encrypt.

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 8, 2023 at 11:33 AM Alexey Kuznetsov &lt;<a href="mailto:kuznetsov.alexey@gmail.com">kuznetsov.alexey@gmail.com</a>&gt; wrote:<br></div><
blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 8, 2023 at 7:11 
PM Adrien CLERC &lt;<a href="mailto:adrien@antipoul.fr" target="_blank">adrien@antipoul.fr</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>
<div>Le 08/03/2023 à 16:28, Alexey Kuznetsov
a écrit :<br>
</div>
<bloc

On 2023-03-11 12:57:56 -0500 (-0500), Timothy M Butterworth wrote:
[...]

The reason you can not use Login/Password as the LUKS passphrase
is because The Passphrase can not be different for different
users. The passphrase is not simply a password but instead it is
part of the key material used to decrypt and encrypt.

Not that I'm a fan of the proposed use case, but see the manpage for cryptsetup-luksAddKey(8): "Adds a keyslot protected by a new
passphrase." So while there is only one passphrase for a key, a
device can be accessed by an arbitrary number of keys.
--
Jeremy Stanley

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmQM1XZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCngHg//eKKwdi8N/r0oW/TtSpRa47pERVxLdOIwutDz4dpRCipNB7nP4Ej4T8zD ksUwFvHZen9hDZiOqxrOoY2K9qi5c6RU/YY0liOxIMD9Sp6oJ9964OsuzF6bEPne uc0gvsja8Isvm56g51Y57xn6d/TzOuV58bLcrL0XgpAvD1yKGuDBMI69MFB4r+Qo pEX1NNSS7qQVh1DEWGrr9UnPayRmTcrQ5AOGk3O2/UFQvuK213rr35ZH/93TBeS4 FqiafcSZ1JkyLbbdTib5DXeaxkeIHEo2GgTT4bbiZPCbkoXbsN7X3UW67NSUYYUI T5S+j6c07315F8ZLy3R2G4Na4GY17/BnEZULQz8lva8qLxa1sL0jx1Q9idar1+3m ggmj8xIElgbcMSx1bpCw6nJuCtknWJPwBYDocnmZBEzCVRFjp9hho94vx0/BjFbU 5jnl6C3Jg5EId+vTi/5Cspq+QdRx5M6qXYBnbYq7jAcZSDb4UFTtAGuk46+I+kTg Ruu5Kab5aBP48HO/jJN0pbeQuY5+/AVHkolS2OaPm6eJDhLam0OShj2JKdFceW5r 33wgkFxbcQQdxAbxBgs2zo77CQxmimf4dtKH7hTgLMYec5XGVAktC+yY//tgpC+M OBZeOxxkXlab08E+vEm0cYPZYU10TKN5ysCJtykIEmbaCVpX4a4=
=ZzUL
-----END PGP SIGNATURE-----

--- SoupGate-Win32