Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/DisallowEmptyPasswordsByDefault

== Summary ==
Remove ''nullok'' parameter from pam_unix module in default PAM
configuration in order to disallow authentication with empty password.

== Owner ==
* Name: [[User:pbrezina| Pavel Březina]]
* Email: <pbrezina(a)redhat.com&gt;

== Detailed Description ==

Current default configuration allows users to login with an empty
password by setting nullok parameter to pam_unix module. This affects
only logins to local machine, it does not affect ssh logins as this
must be explicitly allowed in sshd_config. We want to disallow empty
password by default for local logins as well to improve system
hardening.

Note: It is possible to disallow empty passwords with authselect call
(authselect enable-feature without-nullok) or by removing nullok
manually, however it creates possible issues in other components that
must be addressed.

=== Affected Components ===
* '''passwd''' - calling passwd -d to remove users password must
be
denied if empty passwords are disallowed otherwise the user will be
locked out of the system
* '''AccountService''' - D-Bus methods
''SetPassword'' and
''SetPasswordMode'' on ''org.freedesktop.Accounts.User''
interface can
remove user’s password and lock the user out of the system if empty
password is disallowed. These calls must be denied in this case.
Additionally, these methods can be run by normal users as opposed to
''passwd -d'' and ''chage -d 0'' which can be run only by
root.
Therefore only root should be able to call these methods.
* '''Gnome’s Control Center''' - when creating new users, it
provides
an option to “require password to be set on first login” which creates
user with expired empty password. This would again lock the user out
of the system.
* '''Other Desktop Environments''' - may have the same issue as
Gnome
Control Center

=== Solution Step by Step ===

==== Step 1) Provide a unified way to read if nullok is enabled or not ====

We will create an authselect library call that would parse existing
PAM configuration (not necessarily generated by authselect) and return
list of enabled/disabled features. We will implement only ''nullok''
feature in the scope of this change but if needed it can be extended
in the future.

==== Step 2) Fix passwd -d ====
Calling ''passwd -d'' to remove user's password will fail if
''nullok'' is disabled.

==== Step 3) Fix AccountService ====
These methods on ''org.freedesktop.Accounts.User'' D-Bus interface
will be callable only by ''root'' and must return an error if
''nullok'' is disabled.

  SetPasswordMode
  SetPassword(“”, hint)

==== Step 4) Fix Desktop Environments ====
“Require password change on next login” must keep working. This
feature currently relies on setting an empty password. A new option
''nullresetok'' will be implemented for ''pam_unix''
module that will
allow user to authenticate with empty password only if a password
change for this user is enforced upon login. Authentication with empty
passwords which are not expired will be prohibited (unless ''nullok''
is set).

==== Step 5) Update PAM configuration to disable nullok by default ====
In authselect and pam components for new installations. Upgrading from
older systems will keep nullok present.

== Benefit to Fedora ==

Changes in described components (Step 1 - Step 4) are necessary to
implement in order to make sure that user accounts and tools works
correctly when authentication with empty password is disabled by
system administrator. Changing system default to disallow
authentication with empty passwords (Step 5) improves system
hardening.

== Scope ==
* Proposal owners: Coordinate the work. Make sure all required changes
are implemented.
* Other developers: All affected component must be fixed. Changes are
described in ''Detailed Description''
* Release engineering: [https://pagure.io/releng/issue/9038 #9038] (a
check of an impact with Release Engineering is needed) <!-- REQUIRED
FOR SYSTEM WIDE CHANGES -->
<!-- Does this feature require coordination with release engineering
(e.g. changes to installer image generation or update package
delivery)?  Is a mass rebuild required?  include a link to the releng
issue.
The issue is required to be filed prior to feature submission, to
ensure that someone is on board to do any process development work and
testing, and that all changes make it into the pipeline; a bullet
point in a change is not sufficient communication -->

* Policies and guidelines: No updates needed.
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
This does not affect system upgrades because only new installation
will have changed default.

== How To Test ==

* Calling ''passwd -d user'' as root must fail with default
configuration.
* Calling ''org.freedesktop.Accounts.User.SetPassword("",
hint)'' and
''org.freedesktop.Accounts.User.SetPasswordMode(x)'' must fail with
default configuration.
* "require password reset on first login" must keep working when
creating users from Desktop Environment's GUI tools

== User Experience ==
Users will no longer be able to use empty passwords by default.

== Dependencies ==
None.

== Contingency Plan ==
* Contingency mechanism: Default behavior will not be changed.
* Contingency deadline: Beta
* Blocks release? No
* Blocks product? No

== Documentation ==


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Samuel Sieb]

On 11/25/19 1:25 PM, Ben Cotton wrote:
>  == Benefit to Fedora ==
>  
>  Changes in described components (Step 1 - Step 4) are necessary to
>  implement in order to make sure that user accounts and tools works
>  correctly when authentication with empty password is disabled by
>  system administrator. Changing system default to disallow
>  authentication with empty passwords (Step 5) improves system
>  hardening. 
Steps 1 - 4 are not benefits, they are workarounds to critical system 
utilities required by this change.  I don't understand why this change 
is necessary at all.  It only affects local logins and if someone wants 
to have an empty password, why make it so difficult?  It's their choice. 
  It's not like Fedora has any default logins with empty passwords, the 
user has to make their own.

[John M. Harris Jr]

On Monday, November 25, 2019 2:59:18 PM MST Samuel Sieb wrote:
>  On 11/25/19 1:25 PM, Ben Cotton wrote:
>  
>  > == Benefit to Fedora ==
>  > 
>  > Changes in described components (Step 1 - Step 4) are necessary to
>  > implement in order to make sure that user accounts and tools works
>  > correctly when authentication with empty password is disabled by
>  > system administrator. Changing system default to disallow
>  > authentication with empty passwords (Step 5) improves system
>  > hardening.
>  
>  
>  Steps 1 - 4 are not benefits, they are workarounds to critical system 
>  utilities required by this change.  I don't understand why this change 
>  is necessary at all.  It only affects local logins and if someone wants 
>  to have an empty password, why make it so difficult?  It's their choice. 
>    It's not like Fedora has any default logins with empty passwords, the 
>  user has to make their own.
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
>  Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
>  Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail] 
I would have to agree. It's one thing to warn non-technical users when setting 
empty passwords, another entirely to prevent them. Many non-technical users 
just don't want a password set on their system.

-- 
John M. Harris, Jr.
Splentity

[Martin Kolman]

On Mon, 2019-11-25 at 16:25 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/DisallowEmptyPasswordsByDefault
>  
>  == Summary ==
>  Remove ''nullok'' parameter from pam_unix module in default PAM
>  configuration in order to disallow authentication with empty password.
>  
>  == Owner ==
>  * Name: [[User:pbrezina| Pavel Březina]]
>  * Email: <pbrezina(a)redhat.com&gt;
>  
>  == Detailed Description ==
>  
>  Current default configuration allows users to login with an empty
>  password by setting nullok parameter to pam_unix module. This affects
>  only logins to local machine, it does not affect ssh logins as this
>  must be explicitly allowed in sshd_config. We want to disallow empty
>  password by default for local logins as well to improve system
>  hardening.
>  
>  Note: It is possible to disallow empty passwords with authselect call
>  (authselect enable-feature without-nullok) or by removing nullok
>  manually, however it creates possible issues in other components that
>  must be addressed.
>  
>  === Affected Components ===
>  * '''passwd''' - calling passwd -d to remove users password must
> be
>  denied if empty passwords are disallowed otherwise the user will be
>  locked out of the system
>  * '''AccountService''' - D-Bus methods
> ''SetPassword'' and
>  ''SetPasswordMode'' on ''org.freedesktop.Accounts.User''
> interface can
>  remove user’s password and lock the user out of the system if empty
>  password is disallowed. These calls must be denied in this case.
>  Additionally, these methods can be run by normal users as opposed to
>  ''passwd -d'' and ''chage -d 0'' which can be run only by
> root.
>  Therefore only root should be able to call these methods.
>  * '''Gnome’s Control Center''' - when creating new users, it
> provides
>  an option to “require password to be set on first login” which creates
>  user with expired empty password. This would again lock the user out
>  of the system.
>  * '''Other Desktop Environments''' - may have the same issue as
> Gnome
>  Control Center 
This would definitely also affect the installation, unless we want
to create user accounts
that can't log in.

So the list of affected components should include also Anaconda and Gnome Initial Setup.

>  
>  === Solution Step by Step ===
>  
>  ==== Step 1) Provide a unified way to read if nullok is enabled or not ====
>  
>  We will create an authselect library call that would parse existing
>  PAM configuration (not necessarily generated by authselect) and return
>  list of enabled/disabled features. We will implement only ''nullok''
>  feature in the scope of this change but if needed it can be extended
>  in the future.
>  
>  ==== Step 2) Fix passwd -d ====
>  Calling ''passwd -d'' to remove user's password will fail if
>  ''nullok'' is disabled.
>  
>  ==== Step 3) Fix AccountService ====
>  These methods on ''org.freedesktop.Accounts.User'' D-Bus interface
>  will be callable only by ''root'' and must return an error if
>  ''nullok'' is disabled.
>  
>    SetPasswordMode
>    SetPassword(“”, hint)
>  
>  ==== Step 4) Fix Desktop Environments ====
>  “Require password change on next login” must keep working. This
>  feature currently relies on setting an empty password. A new option
>  ''nullresetok'' will be implemented for ''pam_unix''
> module that will
>  allow user to authenticate with empty password only if a password
>  change for this user is enforced upon login. Authentication with empty
>  passwords which are not expired will be prohibited (unless ''nullok''
>  is set).
>  
>  ==== Step 5) Update PAM configuration to disable nullok by default ====
>  In authselect and pam components for new installations. Upgrading from
>  older systems will keep nullok present.
>  
>  == Benefit to Fedora ==
>  
>  Changes in described components (Step 1 - Step 4) are necessary to
>  implement in order to make sure that user accounts and tools works
>  correctly when authentication with empty password is disabled by
>  system administrator. Changing system default to disallow
>  authentication with empty passwords (Step 5) improves system
>  hardening.
>  
>  == Scope ==
>  * Proposal owners: Coordinate the work. Make sure all required changes
>  are implemented.
>  * Other developers: All affected component must be fixed. Changes are
>  described in ''Detailed Description''
>  * Release engineering: [https://pagure.io/releng/issue/9038 #9038] (a
>  check of an impact with Release Engineering is needed) <!-- REQUIRED
>  FOR SYSTEM WIDE CHANGES -->
>  <!-- Does this feature require coordination with release engineering
>  (e.g. changes to installer image generation or update package
>  delivery)?  Is a mass rebuild required?  include a link to the releng
>  issue.
>  The issue is required to be filed prior to feature submission, to
>  ensure that someone is on board to do any process development work and
>  testing, and that all changes make it into the pipeline; a bullet
>  point in a change is not sufficient communication -->
>  
>  * Policies and guidelines: No updates needed.
>  * Trademark approval: N/A (not needed for this Change)
>  
>  == Upgrade/compatibility impact ==
>  This does not affect system upgrades because only new installation
>  will have changed default.
>  
>  == How To Test ==
>  
>  * Calling ''passwd -d user'' as root must fail with default
> configuration.
>  * Calling ''org.freedesktop.Accounts.User.SetPassword("",
> hint)'' and
>  ''org.freedesktop.Accounts.User.SetPasswordMode(x)'' must fail with
>  default configuration.
>  * "require password reset on first login" must keep working when
>  creating users from Desktop Environment's GUI tools
>  
>  == User Experience ==
>  Users will no longer be able to use empty passwords by default.
>  
>  == Dependencies ==
>  None.
>  
>  == Contingency Plan ==
>  * Contingency mechanism: Default behavior will not be changed.
>  * Contingency deadline: Beta
>  * Blocks release? No
>  * Blocks product? No
>  
>  == Documentation ==
>  
>  
>  -- 
>  Ben Cotton
>  He / Him / His
>  Fedora Program Manager
>  Red Hat
>  TZ=America/Indiana/Indianapolis
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

[Kevin Kofler]

Samuel Sieb wrote:
>  Steps 1 - 4 are not benefits, they are workarounds to critical
> system
>  utilities required by this change.  I don't understand why this change
>  is necessary at all.  It only affects local logins and if someone wants
>  to have an empty password, why make it so difficult?  It's their choice. 
+1, I do not see the point of patronizing our users that way (and it is only 
an extra hoop to jump through because they can still readd the nullok), and 
find it particularly pointless to make all those error-prone changes to core 
system utilities just to make that work.

>    It's not like Fedora has any default logins with empty
> passwords, the
>  user has to make their own. 
That part is actually not entirely true: the live images have no password 
set on the liveuser and root accounts. Hence, this change will also break 
the live images, unless we add yet another hack to the scriptlets in the 
live kickstarts, one that readds the nullok option. IMHO, we already have 
too many hacks in the kickstart scriptlets.

        Kevin Kofler

[Adam Williamson]

On Tue, 2019-11-26 at 00:34 +0100, Kevin Kofler wrote:
>  Samuel Sieb wrote:
>  > Steps 1 - 4 are not benefits, they are workarounds to critical system
>  > utilities required by this change.  I don't understand why this change
>  > is necessary at all.  It only affects local logins and if someone wants
>  > to have an empty password, why make it so difficult?  It's their choice.
>  
>  +1, I do not see the point of patronizing our users that way (and it is only 
>  an extra hoop to jump through because they can still readd the nullok), and 
>  find it particularly pointless to make all those error-prone changes to core 
>  system utilities just to make that work.
>  
>  >   It's not like Fedora has any default logins with empty passwords, the
>  > user has to make their own.
>  
>  That part is actually not entirely true: the live images have no password 
>  set on the liveuser and root accounts. Hence, this change will also break 
>  the live images, unless we add yet another hack to the scriptlets in the 
>  live kickstarts, one that readds the nullok option. IMHO, we already have 
>  too many hacks in the kickstart scriptlets. 
I gotta say +1 too. I don't buy that there's a significant 'hardening'
benefit worth all the effort mentioned in the Change *plus* the
additional consequences Kevin and Martin pointed out. At minimum I'd
like to see a much more convincing case that people are creating users
without passwords without understanding what they're doing.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Michael Catanzaro]

Hi,

Setting aside the question of how anaconda, gnome-initial-setup, and 
the liveuser sessions would work, I have a question about the complaint 
regarding accountsservice.

On Mon, Nov 25, 2019 at 4:25 pm, Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  * '''AccountService''' - D-Bus methods
> ''SetPassword'' and
>  ''SetPasswordMode'' on ''org.freedesktop.Accounts.User''
> interface can
>  remove user’s password and lock the user out of the system if empty
>  password is disallowed. These calls must be denied in this case. 
OK, makes sense. But:

>  Additionally, these methods can be run by normal users as opposed to
>  ''passwd -d'' and ''chage -d 0'' which can be run only by
> root.
>  Therefore only root should be able to call these methods. 
So... then users can't change their own passwords?

We don't enable root account in Workstation anyway, it would become 
impossible to ever change any password via accountsservice.

Let's assume you meant "only admin users should be able to call these 
methods" instead of "only root". Even then, I still don't understand 
the problem. I just tested using D-Feet to manually change my password 
using org.freedesktop.Accounts SetPassword, and it required that I 
authenticate via polkit. polkit is good; let it do its thing. It's 
checking the org.freedesktop.accounts.change-own-password action, which 
requires auth_admin authentication. So what is the problem here?

Michael

[Jan Kratochvil]

On Mon, 25 Nov 2019 22:59:18 +0100, Samuel Sieb wrote:
>  I don't understand why this change is
>  necessary at all.  It only affects local logins and if someone wants to have
>  an empty password, why make it so difficult?  It's their choice.  It's not
>  like Fedora has any default logins with empty passwords, the user has to
>  make their own. 
Yes, what about firewalled virtual machines for development testing purposes?
There any password makes no sense.


Jan

[Dominique Martinet]

Adam Williamson wrote on Mon, Nov 25, 2019 at 03:55:28PM -0800:
>  I gotta say +1 too. I don't buy that there's a significant
> 'hardening'
>  benefit worth all the effort mentioned in the Change *plus* the
>  additional consequences Kevin and Martin pointed out. At minimum I'd
>  like to see a much more convincing case that people are creating users
>  without passwords without understanding what they're doing. 
FWIW this has happened at an association I help at -- they had VMs with
no root password set, and users created by puppet some of whom have
sudo.
They just expected no root password = no login possible, but it turns
out 'su' just gave out a root shell with no password entered...

It's easy to fix once I realized that, but it had been that way for
quite a while until then; I'd definitely support removing nullok on the
default install.


-- 
Dominique

[Samuel Sieb]

On 11/26/19 12:45 AM, Dominique Martinet wrote:
>  Adam Williamson wrote on Mon, Nov 25, 2019 at 03:55:28PM -0800:
> > I gotta say +1 too. I don't buy that there's a significant
> 'hardening'
> > benefit worth all the effort mentioned in the Change *plus* the
> > additional consequences Kevin and Martin pointed out. At minimum I'd
> > like to see a much more convincing case that people are creating users
> > without passwords without understanding what they're doing.
>  
>  FWIW this has happened at an association I help at -- they had VMs with
>  no root password set, and users created by puppet some of whom have
>  sudo.
>  They just expected no root password = no login possible, but it turns
>  out 'su' just gave out a root shell with no password entered... 
"su" or "sudo"?  Your scenario is unclear.

>  It's easy to fix once I realized that, but it had been that way
> for
>  quite a while until then; I'd definitely support removing nullok on the
>  default install. 
I don't think that this proposal would even help with that situation. 
This is about user passwords, not root.  How were those VMs created?  If 
you're creating users with sudo access, how can you not expect to have 
root be accessible?

[Dominique Martinet]

Samuel Sieb wrote on Tue, Nov 26, 2019 at 01:38:51AM -0800:
>  >FWIW this has happened at an association I help at -- they had
> VMs with
>  >no root password set, and users created by puppet some of whom have
>  >sudo.
>  >They just expected no root password = no login possible, but it turns
>  >out 'su' just gave out a root shell with no password entered...
>  
>  "su" or "sudo"?  Your scenario is unclear. 
both worked -- that is the point, su should not have worked here.

They basically gave root access to everyone, regardless of sudoer
settings.



>  >It's easy to fix once I realized that, but it had been that
> way for
>  >quite a while until then; I'd definitely support removing nullok on the
>  >default install.
>  
>  I don't think that this proposal would even help with that situation. This
>  is about user passwords, not root.  How were those VMs created? 
Whatever the virtualization solution they use to create VMs, it just had
an empty root password.
I haven't checked what is used, I agree it also is a bug in their setup
script (fixed since then), but there are plenty of scenarii where an
empty root password makes sense for VMs/containers e.g. allow logins
from the console by default, so I believe these will continue to do
that.

>  If you're creating users with sudo access, how can you not expect
> to
>  have root be accessible? 
It sure would... I didn't say root user should be locked out to sudoers,
just 'su' shouldn't work.

An alternative might be to go back to securetty settings allowing
console login but not non-interactive su or su over ssh. That does sound
harder to setup/easier to miss, though, and if someone does set a root
password up they would be doubly surprised... I don't think we can tell
it to only look at securetty if the password was empty?

-- 
Dominique

[David Kaufmann]

On Tue, Nov 26, 2019 at 09:45:44AM +0100, Dominique Martinet wrote:
>  FWIW this has happened at an association I help at -- they had VMs
> with
>  no root password set, and users created by puppet some of whom have
>  sudo.
>  They just expected no root password = no login possible, but it turns
>  out 'su' just gave out a root shell with no password entered...
>  
>  It's easy to fix once I realized that, but it had been that way for
>  quite a while until then; I'd definitely support removing nullok on the
>  default install. 
At least with Fedora 31 the root-Password is invalid by default, so I
guess it has been set to an empty password explicitely.
I'd classify this more as a bug in the puppet-scripts, as it sounds like
it touched security relevant stuff on installation, without admins being
aware of it.

All the best,
David

[Dominique Martinet]

David Kaufmann wrote on Tue, Nov 26, 2019 at 11:13:15AM +0100:
>  On Tue, Nov 26, 2019 at 09:45:44AM +0100, Dominique Martinet wrote:
>  > FWIW this has happened at an association I help at -- they had VMs with
>  > no root password set, and users created by puppet some of whom have
>  > sudo.
>  > They just expected no root password = no login possible, but it turns
>  > out 'su' just gave out a root shell with no password entered...
>  > 
>  > It's easy to fix once I realized that, but it had been that way for
>  > quite a while until then; I'd definitely support removing nullok on the
>  > default install.
>  
>  At least with Fedora 31 the root-Password is invalid by default, so I
>  guess it has been set to an empty password explicitely.
>  I'd classify this more as a bug in the puppet-scripts, as it sounds like
>  it touched security relevant stuff on installation, without admins being
>  aware of it. 
Yes, definitely. I'm pretty sure puppet didn't touch it, but they must
have set the root password to an empty string somewhere on deployment --
I found it now I'm looking, they run 'passwd -d root' in the image on
purpose apparently (don't ask me why...), and people who had done it
left and turnover happened and new people weren't aware of it.

I really just wanted to answer Adam's "does it really happen?" question
- it does.

Would the change have been enough to make whoever removed the root
password not also re-add nullok ? I don't know, but it might have made
them think about it twice and reconsider doing that.


In an ideal world I think most people would consider passwordless login
ok if you're on the console or a physical seat, and not ok if you come
from ssh or some script running somewhere (cgi or whatever). Is that
attainable ?

-- 
Dominique

[Kamil Paral]

On Mon, Nov 25, 2019 at 10:27 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:

> https://fedoraproject.org/wiki/Changes/DisallowEmptyPasswordsByDefault
>
>  == Summary ==
>  Remove ''nullok'' parameter from pam_unix module in default PAM
>  configuration in order to disallow authentication with empty password.
>
>  == Owner ==
>  * Name: [[User:pbrezina| Pavel Březina]]
>  * Email: <pbrezina(a)redhat.com&gt;
>
>  == Detailed Description ==
>
>  Current default configuration allows users to login with an empty
>  password by setting nullok parameter to pam_unix module. This affects
>  only logins to local machine, it does not affect ssh logins as this
>  must be explicitly allowed in sshd_config. We want to disallow empty
>  password by default for local logins as well to improve system
>  hardening.
>  
It makes sense to implement this functionality so that users/admins can
harden their systems in this way if they prefer. But I don't think it
should be the default all across Fedora. Especially in desktop space, empty
passwords make sense. I think the best approach would be to provide the
functionality and then let individual spins/editions enable this by default
if they want (e.g. the Security spin, or Server).

[John M. Harris Jr]

On Tuesday, November 26, 2019 3:31:54 AM MST Kamil Paral wrote:
>  On Mon, Nov 25, 2019 at 10:27 PM Ben Cotton
> <bcotton(a)redhat.com&gt; wrote:
>  > https://fedoraproject.org/wiki/Changes/DisallowEmptyPasswordsByDefault
>  > 
>  > == Summary ==
>  > Remove ''nullok'' parameter from pam_unix module in default PAM
>  > configuration in order to disallow authentication with empty password.
>  > 
>  > == Owner ==
>  > * Name: [[User:pbrezina| Pavel Březina]]
>  > * Email: <pbrezina(a)redhat.com&gt;
>  > 
>  > == Detailed Description ==
>  > 
>  > Current default configuration allows users to login with an empty
>  > password by setting nullok parameter to pam_unix module. This affects
>  > only logins to local machine, it does not affect ssh logins as this
>  > must be explicitly allowed in sshd_config. We want to disallow empty
>  > password by default for local logins as well to improve system
>  > hardening.
>  
>  It makes sense to implement this functionality so that users/admins can
>  harden their systems in this way if they prefer. But I don't think it
>  should be the default all across Fedora. Especially in desktop space, empty
>  passwords make sense. I think the best approach would be to provide the
>  functionality and then let individual spins/editions enable this by default
>  if they want (e.g. the Security spin, or Server). 
Let me clarify something I said earlier in this thread. I don't believe anyone 
should be using empty passwords. That said, I know that there's no way I can 
convince certain people to use a password, and those people would still like 
to be able to use Fedora without having to learn pam configuration.

I don't believe that empty passwords make sense in any case.

-- 
John M. Harris, Jr.
Splentity

[Zbigniew Jędrzejewski-Szmek]

On Mon, Nov 25, 2019 at 03:55:28PM -0800, Adam Williamson wrote:
>  On Tue, 2019-11-26 at 00:34 +0100, Kevin Kofler wrote:
>  > Samuel Sieb wrote:
>  > > Steps 1 - 4 are not benefits, they are workarounds to critical system
>  > > utilities required by this change.  I don't understand why this change
>  > > is necessary at all.  It only affects local logins and if someone wants
>  > > to have an empty password, why make it so difficult?  It's their choice.
>  > 
>  > +1, I do not see the point of patronizing our users that way (and it is only 
>  > an extra hoop to jump through because they can still readd the nullok), and 
>  > find it particularly pointless to make all those error-prone changes to core 
>  > system utilities just to make that work.
>  > 
>  > >   It's not like Fedora has any default logins with empty passwords, the
>  > > user has to make their own.
>  > 
>  > That part is actually not entirely true: the live images have no password 
>  > set on the liveuser and root accounts. Hence, this change will also break 
>  > the live images, unless we add yet another hack to the scriptlets in the 
>  > live kickstarts, one that readds the nullok option. IMHO, we already have 
>  > too many hacks in the kickstart scriptlets.
>  
>  I gotta say +1 too. I don't buy that there's a significant 'hardening'
>  benefit worth all the effort mentioned in the Change *plus* the
>  additional consequences Kevin and Martin pointed out. At minimum I'd
>  like to see a much more convincing case that people are creating users
>  without passwords without understanding what they're doing. 
+1 from me too. It is very convenient to be able to set an empty password
on certains VMs and containers and special-purpose machines.

I would support this change if there were plausible scenarios where the 
password is unset by mistake. But the only case cited so far is the puppet
mistake where the admins scripted 'passwd -d root' and then forgot about
this. This is not a fight we could ever win: if we remove 'nullok',
the admins would simply add another script line to add it back.

Zbyszek

[Pete Walter]

26.11.2019, 11:39, "Zbigniew Jędrzejewski-Szmek" <zbyszek(a)in.waw.pl&gt;:
>  On Mon, Nov 25, 2019 at 03:55:28PM -0800, Adam Williamson wrote:
> >  On Tue, 2019-11-26 at 00:34 +0100, Kevin Kofler wrote:
> >  > Samuel Sieb wrote:
> >  > > Steps 1 - 4 are not benefits, they are workarounds to critical system
> >  > > utilities required by this change. I don't understand why this change
> >  > > is necessary at all. It only affects local logins and if someone wants
> >  > > to have an empty password, why make it so difficult? It's their
> choice.
> >  >
> >  > +1, I do not see the point of patronizing our users that way (and it is only
> >  > an extra hoop to jump through because they can still readd the nullok), and
> >  > find it particularly pointless to make all those error-prone changes to core
> >  > system utilities just to make that work.
> >  >
> >  > > It's not like Fedora has any default logins with empty passwords, the
> >  > > user has to make their own.
> >  >
> >  > That part is actually not entirely true: the live images have no password
> >  > set on the liveuser and root accounts. Hence, this change will also break
> >  > the live images, unless we add yet another hack to the scriptlets in the
> >  > live kickstarts, one that readds the nullok option. IMHO, we already have
> >  > too many hacks in the kickstart scriptlets.
> >
> >  I gotta say +1 too. I don't buy that there's a significant
> 'hardening'
> >  benefit worth all the effort mentioned in the Change *plus* the
> >  additional consequences Kevin and Martin pointed out. At minimum I'd
> >  like to see a much more convincing case that people are creating users
> >  without passwords without understanding what they're doing.
>
>  +1 from me too. It is very convenient to be able to set an empty password
>  on certains VMs and containers and special-purpose machines.
>
>  I would support this change if there were plausible scenarios where the
>  password is unset by mistake. But the only case cited so far is the puppet
>  mistake where the admins scripted 'passwd -d root' and then forgot about
>  this. This is not a fight we could ever win: if we remove 'nullok',
>  the admins would simply add another script line to add it back. 
Agreed. I too am against this change for the reasons other people have already stated.

Pete

[Chris Adams]

Once upon a time, David Kaufmann <astra(a)ionic.at&gt; said:
>  At least with Fedora 31 the root-Password is invalid by default, so
> I
>  guess it has been set to an empty password explicitely. 
How does that work with single-user mode, rescue mode, etc.?

In the past, you could change the options to /sbin/sulogin, but systemd
apparently absorbed or wraps that functionality with its own thing,
/usr/lib/systemd/systemd-sulogin-shell, that doesn't appear to be
documented (at least in the man pages).

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Michael Catanzaro]

On Tue, Nov 26, 2019 at 8:03 am, Chris Adams <linux(a)cmadams.net&gt; wrote:
>  How does that work with single-user mode, rescue mode, etc.? 
I assume single-user mode does not work. Rescue mode certainly does not 
work. It asks for a root password, but root account is locked.

Michael

[Michael Catanzaro]

On Tue, Nov 26, 2019 at 9:45 am, Dominique Martinet 
<dominique.martinet(a)cea.fr&gt; wrote:
>  They just expected no root password = no login possible, but it
> turns
>  out 'su' just gave out a root shell with no password entered... 
It depends on whether the account is locked or not. In Workstation we 
default to locked passwordless root, equivalent to:

# passwd -d root
# passwd -l root

which is what your association really wanted to do with their VMs: no 
root password, and cannot log in as root. They forgot the 'passwd -l', 
without which you're able to log in as root with no password. ('passwd 
-d' removes the password and unlocks the account; 'passwd -l' locks it.)

Michael

[Chris Adams]

Once upon a time, Michael Catanzaro <mcatanzaro(a)gnome.org&gt; said:
>  On Tue, Nov 26, 2019 at 8:03 am, Chris Adams
> <linux(a)cmadams.net&gt; wrote:
>  >How does that work with single-user mode, rescue mode, etc.?
>  
>  I assume single-user mode does not work. Rescue mode certainly does
>  not work. It asks for a root password, but root account is locked. 
That should be considered a bug IMHO...
-- 
Chris Adams <linux(a)cmadams.net&gt;

[Michael Catanzaro]

On Tue, Nov 26, 2019 at 9:35 am, Chris Adams <linux(a)cmadams.net&gt; wrote:
>  That should be considered a bug IMHO... 
At least for rescue mode, probably yes, but I don't know what to do 
about it. Can we make systemd's rescue prompt ask for username and 
allow logging in with any user account (goal being to log in to admin 
account then 'sudo -i')? Or would there be problems with that? Clearly 
it's not designed for that purpose, and it seems intentional.

[Adam Williamson]

On Tue, 2019-11-26 at 09:45 +0100, Dominique Martinet wrote:
>  Adam Williamson wrote on Mon, Nov 25, 2019 at 03:55:28PM -0800:
>  > I gotta say +1 too. I don't buy that there's a significant
> 'hardening'
>  > benefit worth all the effort mentioned in the Change *plus* the
>  > additional consequences Kevin and Martin pointed out. At minimum I'd
>  > like to see a much more convincing case that people are creating users
>  > without passwords without understanding what they're doing.
>  
>  FWIW this has happened at an association I help at -- they had VMs with
>  no root password set, and users created by puppet some of whom have
>  sudo.
>  They just expected no root password = no login possible, but it turns
>  out 'su' just gave out a root shell with no password entered... 
Uh. This sounds odd. How exactly did they do this? Making a root
account with no password is not that easy; you can't do it
interactively through anaconda, I don't even know if you can do it with
a kickstart. So they figured out how to do it post-install but somehow
didn't at the same time figure out what doing it means?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Adam Williamson]

On Tue, 2019-11-26 at 08:14 -0800, Adam Williamson wrote:
>  On Tue, 2019-11-26 at 09:45 +0100, Dominique Martinet wrote:
>  > Adam Williamson wrote on Mon, Nov 25, 2019 at 03:55:28PM -0800:
>  > > I gotta say +1 too. I don't buy that there's a significant
> 'hardening'
>  > > benefit worth all the effort mentioned in the Change *plus* the
>  > > additional consequences Kevin and Martin pointed out. At minimum I'd
>  > > like to see a much more convincing case that people are creating users
>  > > without passwords without understanding what they're doing.
>  > 
>  > FWIW this has happened at an association I help at -- they had VMs with
>  > no root password set, and users created by puppet some of whom have
>  > sudo.
>  > They just expected no root password = no login possible, but it turns
>  > out 'su' just gave out a root shell with no password entered...
>  
>  Uh. This sounds odd. How exactly did they do this? Making a root
>  account with no password is not that easy; you can't do it
>  interactively through anaconda, I don't even know if you can do it with
>  a kickstart. So they figured out how to do it post-install but somehow
>  didn't at the same time figure out what doing it means? 
Never mind, I see this was answered already.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Chris Murphy]

On Tue, Nov 26, 2019 at 8:36 AM Chris Adams <linux(a)cmadams.net&gt; wrote:
>  Once upon a time, Michael Catanzaro <mcatanzaro(a)gnome.org&gt; said:
>  > On Tue, Nov 26, 2019 at 8:03 am, Chris Adams <linux(a)cmadams.net&gt; wrote:
>  > >How does that work with single-user mode, rescue mode, etc.?
>  >
>  > I assume single-user mode does not work. Rescue mode certainly does
>  > not work. It asks for a root password, but root account is locked.
>
>  That should be considered a bug IMHO... 
I brought this up ages ago. Basically emergency.target and
rescue.target have a hard requirement on root, and there aren't enough
services present to authenticate some other user (I guess?). And on
Workstation, it was long ago decided to not require setting up a root
user at install time *if* an (admin) user were setup. And that was
followed up more recently by eliminating the install time user setup
entirely, on Workstation edition.

So...it's a difficult problem to solve. Mayyyybee systemd-homed is in
a position to solve this by having early enough authentication
capability by rescue.target time that any admin user can login?

-- 
Chris Murphy

[Chris Adams]

Once upon a time, Chris Murphy <lists(a)colorremedies.com&gt; said:
>  On Tue, Nov 26, 2019 at 8:36 AM Chris Adams <linux(a)cmadams.net&gt;
> wrote:
>  >
>  > Once upon a time, Michael Catanzaro <mcatanzaro(a)gnome.org&gt; said:
>  > > On Tue, Nov 26, 2019 at 8:03 am, Chris Adams <linux(a)cmadams.net&gt; wrote:
>  > > >How does that work with single-user mode, rescue mode, etc.?
>  > >
>  > > I assume single-user mode does not work. Rescue mode certainly does
>  > > not work. It asks for a root password, but root account is locked.
>  >
>  > That should be considered a bug IMHO...
>  
>  I brought this up ages ago. Basically emergency.target and
>  rescue.target have a hard requirement on root, and there aren't enough
>  services present to authenticate some other user (I guess?). And on
>  Workstation, it was long ago decided to not require setting up a root
>  user at install time *if* an (admin) user were setup. And that was
>  followed up more recently by eliminating the install time user setup
>  entirely, on Workstation edition.
>  
>  So...it's a difficult problem to solve. Mayyyybee systemd-homed is in
>  a position to solve this by having early enough authentication
>  capability by rescue.target time that any admin user can login? 
You can't guarantee that a non-root admin user even exists at
single/rescue mode time, since they could all be network authentication.

I'd suggest switching back to not requiring a password for single/rescue
mode by default; there's not a default boot-loader password requirement,
so it's not like the single/rescue root password can't be bypassed
already.  I actually had that as part of my personal setup scripts for a
while, until now systemd removed the unit files and went to an
undocumented wrapper binary.

There should be a documented way to enable the password requirement (and
then how to handle it, setting a root password, setting a boot-loader
password, anything else required).  But it is really IMHO kind of silly
to have it there by default.
-- 
Chris Adams <linux(a)cmadams.net&gt;

[Chris Murphy]

On Mon, Nov 25, 2019 at 2:26 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  https://fedoraproject.org/wiki/Changes/DisallowEmptyPasswordsByDefault
>
>  == Summary ==
>  Remove ''nullok'' parameter from pam_unix module in default PAM
>  configuration in order to disallow authentication with empty password. 
How difficult is it to apply this change (disallow authentication for
user with empty password) to only root and users in the wheel group?
i.e. permit empty password standard users (not in wheel)?

>  Current default configuration allows users to login with an empty
>  password by setting nullok parameter to pam_unix module. This affects
>  only logins to local machine, it does not affect ssh logins as this
>  must be explicitly allowed in sshd_config. We want to disallow empty
>  password by default for local logins as well to improve system
>  hardening. 
At least out of the box on Fedora Workstation it's non-trivial to get
into this situation, you have to know what you're doing. The root user
has sp_pwdp set to ! and neither GNOME Initial Setup nor the GNOME
Settings: Users panel permits an empty passphrase.

Anyway, there is also a lot of other implied work with this feature
that I wonder if feature owners should evaluate the implications of a
possible future adoption of systemd-homed? That's a new feature in
systemd-244, and is something the Workstation WG is evaluating as part
of enabling user home encryption by default. The main thing
systemd-homed brings to the table is a cleaner authentication
paradigm, with user home encryption as a (recommended) option which
systemd-homed also manages. I'll start a separate thread about homed,
but since it touches on authentication and so does this feature
proposal, I think it's relevant to bring attention to it.


-- 
Chris Murphy

[Chris Murphy]

On Tue, Nov 26, 2019 at 9:48 AM Chris Adams <linux(a)cmadams.net&gt; wrote:
>  Once upon a time, Chris Murphy <lists(a)colorremedies.com&gt; said:
>  > On Tue, Nov 26, 2019 at 8:36 AM Chris Adams <linux(a)cmadams.net&gt; wrote:
>  > >
>  > > Once upon a time, Michael Catanzaro <mcatanzaro(a)gnome.org&gt; said:
>  > > > On Tue, Nov 26, 2019 at 8:03 am, Chris Adams <linux(a)cmadams.net&gt;
> wrote:
>  > > > >How does that work with single-user mode, rescue mode, etc.?
>  > > >
>  > > > I assume single-user mode does not work. Rescue mode certainly does
>  > > > not work. It asks for a root password, but root account is locked.
>  > >
>  > > That should be considered a bug IMHO...
>  >
>  > I brought this up ages ago. Basically emergency.target and
>  > rescue.target have a hard requirement on root, and there aren't enough
>  > services present to authenticate some other user (I guess?). And on
>  > Workstation, it was long ago decided to not require setting up a root
>  > user at install time *if* an (admin) user were setup. And that was
>  > followed up more recently by eliminating the install time user setup
>  > entirely, on Workstation edition.
>  >
>  > So...it's a difficult problem to solve. Mayyyybee systemd-homed is in
>  > a position to solve this by having early enough authentication
>  > capability by rescue.target time that any admin user can login?
>
>  You can't guarantee that a non-root admin user even exists at
>  single/rescue mode time, since they could all be network authentication. 
Good point.

>  I'd suggest switching back to not requiring a password for
> single/rescue
>  mode by default; there's not a default boot-loader password requirement,
>  so it's not like the single/rescue root password can't be bypassed
>  already. 
Yeah I forget the rationale for this. Since there's no bootloader
lockdown, and it's trivial to just add systemd.debug-shell=1 I can get
a tty with root user active and not even need a password, for any
target, including multi-user and graphical.


-- 
Chris Murphy

[Kevin Kofler]

Dominique Martinet wrote:
>  They just expected no root password = no login possible, but it
> turns
>  out 'su' just gave out a root shell with no password entered... 
Then they need to RTFM of passwd. The correct way to block password login 
for an account is passwd -l, not passwd -d.

Even passwd --help explicitly documents -d as removing the password lock, 
not adding it.

        Kevin Kofler

[John M. Harris Jr]

On Tuesday, November 26, 2019 8:10:49 AM MST Michael Catanzaro wrote:
>  On Tue, Nov 26, 2019 at 8:03 am, Chris Adams
> <linux(a)cmadams.net&gt; wrote:
>  
>  > How does that work with single-user mode, rescue mode, etc.?
>  
>  
>  I assume single-user mode does not work. Rescue mode certainly does not 
>  work. It asks for a root password, but root account is locked.
>  
>  Michael 
The easiest method is to just do `rw init=/bin/bash` and do what you need to 
do.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Tuesday, November 26, 2019 8:53:49 AM MST Michael Catanzaro wrote:
>  On Tue, Nov 26, 2019 at 9:35 am, Chris Adams
> <linux(a)cmadams.net&gt; wrote:
>  
>  > That should be considered a bug IMHO...
>  
>  
>  At least for rescue mode, probably yes, but I don't know what to do 
>  about it. Can we make systemd's rescue prompt ask for username and 
>  allow logging in with any user account (goal being to log in to admin 
>  account then 'sudo -i')? Or would there be problems with that? Clearly 
>  it's not designed for that purpose, and it seems intentional. 
That would not work in 99% of scenarios that require rescue, especially with 
most networks employing network authentication, which would not be available.

-- 
John M. Harris, Jr.
Splentity

[Zbigniew Jędrzejewski-Szmek]

On Tue, Nov 26, 2019 at 09:53:49AM -0600, Michael Catanzaro wrote:
>  On Tue, Nov 26, 2019 at 9:35 am, Chris Adams
> <linux(a)cmadams.net&gt; wrote:
>  >That should be considered a bug IMHO...
>  
>  At least for rescue mode, probably yes, but I don't know what to do
>  about it. Can we make systemd's rescue prompt ask for username and
>  allow logging in with any user account (goal being to log in to
>  admin account then 'sudo -i')? Or would there be problems with that?
>  Clearly it's not designed for that purpose, and it seems
>  intentional. 
systemd does not implement user authentication by itself: it just spawns
getty/gdm/etc during normal runtime, and sulogin for emergency logins.
We generally do not want to re-implement this functionality in systemd.
selinux has some special permissions for sulogin, etc.
Ideally, sulogin would get the capability to pick an alternative user.
util-linux already has the code to select and authenticate users, so
it'd be just a question of some design work and rearranging the code.

On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote:
>  Mayyyybee systemd-homed is in
>  a position to solve this by having early enough authentication
>  capability by rescue.target time that any admin user can login? 
Actually, it may. Things are confusing here, because systemd-homed is
implemented together with changes to how user metadata querying is done:
instead of using dbus, a brokerless and much simpler varlink query is used.
That last part is what would be relevant to early-boot logins, because
less services need to be up to bring up the user session.

Zbyszek

[Przemek Klosowski]

On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote:
>  On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote:
> > Mayyyybee systemd-homed is in
> > a position to solve this by having early enough authentication
> > capability by rescue.target time that any admin user can login?
>  Actually, it may. Things are confusing here, because systemd-homed is
>  implemented together with changes to how user metadata querying is done:
>  instead of using dbus, a brokerless and much simpler varlink query is used.
>  That last part is what would be relevant to early-boot logins, because
>  less services need to be up to bring up the user session. 
There's one tricky feature of homed : remote login (ssh) is only 
possible after an initial local login. It is OK for his intended use (a 
personal laptop/tablet client), except for corner cases like a remotely 
accessed personal desktop in the basement that might get rebooted e.g. 
for updates, resulting in an accidental lockout.

[John M. Harris Jr]

On Monday, December 2, 2019 9:48:05 AM MST Przemek Klosowski via devel wrote:
>  On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote:
>  > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote:
>  >> Mayyyybee systemd-homed is in
>  >> a position to solve this by having early enough authentication
>  >> capability by rescue.target time that any admin user can login?
>  > 
>  > Actually, it may. Things are confusing here, because systemd-homed is
>  > implemented together with changes to how user metadata querying is done:
>  > instead of using dbus, a brokerless and much simpler varlink query is
>  > used.
>  > That last part is what would be relevant to early-boot logins, because
>  > less services need to be up to bring up the user session.
>  
>  There's one tricky feature of homed : remote login (ssh) is only
>  possible after an initial local login. It is OK for his intended use (a
>  personal laptop/tablet client), except for corner cases like a remotely
>  accessed personal desktop in the basement that might get rebooted e.g.
>  for updates, resulting in an accidental lockout. 
Basically, systemd-homed is useless for any power user, but might be useful 
for people just getting into GNU/Linux, who don't use ssh yet or don't have 
more than one system.

-- 
John M. Harris, Jr.
Splentity

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 02, 2019 at 10:44:46AM -0700, John M. Harris Jr wrote:
>  On Monday, December 2, 2019 9:48:05 AM MST Przemek Klosowski via
> devel wrote:
>  > On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote:
>  > > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote:
>  > >> Mayyyybee systemd-homed is in
>  > >> a position to solve this by having early enough authentication
>  > >> capability by rescue.target time that any admin user can login?
>  > > 
>  > > Actually, it may. Things are confusing here, because systemd-homed is
>  > > implemented together with changes to how user metadata querying is done:
>  > > instead of using dbus, a brokerless and much simpler varlink query is
>  > > used.
>  > > That last part is what would be relevant to early-boot logins, because
>  > > less services need to be up to bring up the user session.
>  > 
>  > There's one tricky feature of homed : remote login (ssh) is only
>  > possible after an initial local login. It is OK for his intended use (a
>  > personal laptop/tablet client), except for corner cases like a remotely
>  > accessed personal desktop in the basement that might get rebooted e.g.
>  > for updates, resulting in an accidental lockout.
>  
>  Basically, systemd-homed is useless for any power user, but might be useful 
>  for people just getting into GNU/Linux, who don't use ssh yet or don't have 
>  more than one system. 
How often do you ssh *into* your laptop? I occasionally do, but more
because I can than because I really need to. systemd-homed is most
suited for the case of a portable personal device, and this is exactly
the type of device one is relatively unlikely to access from the
network. So I don't think this limitation is so terrible.

Nevertheless, I'm pretty sure that a workaround for this will be made
anyway. I think the latest version of the patchset allows exporting
the authorized_keys content in the non-encrypted metadata for the user.

Zbyszek

[Nicolas Mailhot]

Le lundi 02 décembre 2019 à 18:16 +0000, Zbigniew Jędrzejewski-Szmek a
écrit :
>  
>  How often do you ssh *into* your laptop? 
I use the same tech desktop and home server side. If it does not work
on my home server, I don’t want to see it on my desktops. I have other
things to do in life than coping with Linux systems fragmentation.

Trying to invent desktop-only things, when the Linux desktop market
share is marginal, and a large part of this marginal userbase is people
also working on Linux servers, is not likely to succeed.

Regards,

-- 
Nicolas Mailhot

[Martin Kolman]

On Mon, 2019-12-02 at 18:16 +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  On Mon, Dec 02, 2019 at 10:44:46AM -0700, John M. Harris Jr wrote:
>  > On Monday, December 2, 2019 9:48:05 AM MST Przemek Klosowski via devel wrote:
>  > > On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote:
>  > > > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote:
>  > > > > Mayyyybee systemd-homed is in
>  > > > > a position to solve this by having early enough authentication
>  > > > > capability by rescue.target time that any admin user can login?
>  > > > 
>  > > > Actually, it may. Things are confusing here, because systemd-homed is
>  > > > implemented together with changes to how user metadata querying is done:
>  > > > instead of using dbus, a brokerless and much simpler varlink query is
>  > > > used.
>  > > > That last part is what would be relevant to early-boot logins, because
>  > > > less services need to be up to bring up the user session.
>  > > 
>  > > There's one tricky feature of homed : remote login (ssh) is only
>  > > possible after an initial local login. It is OK for his intended use (a
>  > > personal laptop/tablet client), except for corner cases like a remotely
>  > > accessed personal desktop in the basement that might get rebooted e.g.
>  > > for updates, resulting in an accidental lockout.
>  > 
>  > Basically, systemd-homed is useless for any power user, but might be useful 
>  > for people just getting into GNU/Linux, who don't use ssh yet or don't have
>
>  > more than one system.
>  
>  How often do you ssh *into* your laptop? 
Actually all the time - my (personal home)
laptop is where my hobby projects
live, where various SSH private keys are, etc. So I SSH there to connect to another
machine using the SSH keys, to work an my hobby projects from a workstation computer
at home, etc.

And this is just "human" SSH sessions, various automated rsync/scp connections
might
happen as well.

>   I occasionally do, but more
>  because I can than because I really need to. systemd-homed is most
>  suited for the case of a portable personal device, and this is exactly
>  the type of device one is relatively unlikely to access from the
>  network. So I don't think this limitation is so terrible.
>  
>  Nevertheless, I'm pretty sure that a workaround for this will be made
>  anyway. I think the latest version of the patchset allows exporting
>  the authorized_keys content in the non-encrypted metadata for the user.
>  
>  Zbyszek
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

[Chris Murphy]

On Mon, Dec 2, 2019 at 9:48 AM Przemek Klosowski via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote:
>
>  On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote:
>
>  Mayyyybee systemd-homed is in
>  a position to solve this by having early enough authentication
>  capability by rescue.target time that any admin user can login?
>
>  Actually, it may. Things are confusing here, because systemd-homed is
>  implemented together with changes to how user metadata querying is done:
>  instead of using dbus, a brokerless and much simpler varlink query is used.
>  That last part is what would be relevant to early-boot logins, because
>  less services need to be up to bring up the user session.
>
>  There's one tricky feature of homed : remote login (ssh) is only possible after an
> initial local login. It is OK for his intended use (a personal laptop/tablet client),
> except for corner cases like a remotely accessed personal desktop in the basement that
> might get rebooted e.g. for updates, resulting in an accidental lockout. 
It's not just an issue for systemd-homed, this problem applies to any
user home encryption implementation when the user has not first
authenticated/unlocked their user home. e.g. if you install with /home
encrypted in Anaconda, in fact your boot stops at plymouth in the
initramfs so sshd is thwarted from even starting in the first place;
and even if GNOME Shell's login were to be enhanced to do this unlock,
still requires unlock.

Basically you have to choose between user home security (or more
specifically privacy) and remote logins. However, there are some ideas
that could possibly work around this, to varying degrees of
inelegance, which I'll gratuitously copy from a related Workstation WG
issue [1].

1. Enhance openssh's PAM support
2. Stub account to ssh into, whereby the user is prompted to
authenticate+unlock the real account; and now ssh into the real
account.
3. Same as 2 but maybe it's possible to bind mount the real home dir
over the stub home dir, eliminating the 2nd login? (Vaguely recall
reading about this somewhere, maybe Ubuntu's use of ecryptfs based
home, now since deprecated in favor of LUKS)
4. If based on any fscrypt implementation, exclude ~/.ssh/ from encryption


[1]
https://pagure.io/fedora-workstation/issue/82#comment-614193

-- 
Chris Murphy

[Chris Murphy]

On Mon, Dec 2, 2019 at 10:45 AM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Monday, December 2, 2019 9:48:05 AM MST Przemek Klosowski via devel wrote:
>  > On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote:
>  > > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote:
>  > >> Mayyyybee systemd-homed is in
>  > >> a position to solve this by having early enough authentication
>  > >> capability by rescue.target time that any admin user can login?
>  > >
>  > > Actually, it may. Things are confusing here, because systemd-homed is
>  > > implemented together with changes to how user metadata querying is done:
>  > > instead of using dbus, a brokerless and much simpler varlink query is
>  > > used.
>  > > That last part is what would be relevant to early-boot logins, because
>  > > less services need to be up to bring up the user session.
>  >
>  > There's one tricky feature of homed : remote login (ssh) is only
>  > possible after an initial local login. It is OK for his intended use (a
>  > personal laptop/tablet client), except for corner cases like a remotely
>  > accessed personal desktop in the basement that might get rebooted e.g.
>  > for updates, resulting in an accidental lockout.
>
>  Basically, systemd-homed is useless for any power user, but might be useful
>  for people just getting into GNU/Linux, who don't use ssh yet or don't have
>  more than one system. 
I disagree with all of this, including the predisposition that this
limitation can't be worked around somehow. I ssh into various laptops
around the home office on a daily basis, I'm not going to give that
up. Based on the systemd-homed presentation, slides, and the early
code review happening, it addresses a number of concerns the
Workstation WG has in making forward progress to secure user data by
default.

It's almost 2020, and I shouldn't have to pick and choose between
remote access and securing user data at rest by default. We surely can
have our cake and eat it too.

-- 
Chris Murphy

[Kevin Fenzi]

On Mon, Dec 02, 2019 at 06:16:43PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
...snip...
>  Nevertheless, I'm pretty sure that a workaround for this will be
> made
>  anyway. I think the latest version of the patchset allows exporting
>  the authorized_keys content in the non-encrypted metadata for the user. 
I wonder if clevis/tang could help here?
( https://github.com/latchset/clevis )

It could allow decryption in home networks, but not when traveling. 

Of course you would have to setup the server, etc. 

kevin

[Chris Murphy]

On Mon, Dec 2, 2019 at 12:39 PM Chris Murphy <lists(a)colorremedies.com&gt; wrote:

>  4. If based on any fscrypt implementation, exclude ~/.ssh/ from
> encryption 
Actually this is essentially the same problem. Yes, I've ssh'd into
the real home, but everything is still encrypted, so I'd have to
unlock my home dir manually to gain access to my stuff. I mean, this
is the point, it's encrypted. And in any case there would be an opt
out for encryption.

-- 
Chris Murphy

[John M. Harris Jr]

On Monday, December 2, 2019 11:16:43 AM MST Zbigniew Jędrzejewski-Szmek wrote:
>  How often do you ssh *into* your laptop? 
Every time I'm on another system without access to my NFS server, or I need my 
GnuPG key when not using my laptop.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Monday, December 2, 2019 12:46:30 PM MST Chris Murphy wrote:
>  It's almost 2020, and I shouldn't have to pick and choose
> between
>  remote access and securing user data at rest by default. 
You don't have to. Data at rest would mean that your system is powered off, or  
suspended to disk. You can have that now with full disk encryption, just as I 
do. Depending on your system, you can actually encrypt the entire disk such 
that you don't even have a partition table. I do this with my X200 Tablet, 
where GRUB is loaded from flash, which decrypts my disk, and then mounts ZFS 
mountpoints, swaps on a ZFS zdev.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Monday, December 2, 2019 12:39:52 PM MST Chris Murphy wrote:
>  On Mon, Dec 2, 2019 at 9:48 AM Przemek Klosowski via devel
>  <devel(a)lists.fedoraproject.org&gt; wrote:
>  
>  >
>  >
>  > On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote:
>  >
>  >
>  >
>  > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote:
>  >
>  >
>  >
>  > Mayyyybee systemd-homed is in
>  > a position to solve this by having early enough authentication
>  > capability by rescue.target time that any admin user can login?
>  >
>  >
>  >
>  > Actually, it may. Things are confusing here, because systemd-homed is
>  > implemented together with changes to how user metadata querying is done:
>  > instead of using dbus, a brokerless and much simpler varlink query is
>  > used. 
 That last part is what would be relevant to early-boot logins,
>  > because less services need to be up to bring up the user
> session.
>  >
>  >
>  >
>  > There's one tricky feature of homed : remote login (ssh) is only possible
>  > after an initial local login. It is OK for his intended use (a personal
>  > laptop/tablet client), except for corner cases like a remotely accessed
>  > personal desktop in the basement that might get rebooted e.g. for
>  > updates, resulting in an accidental lockout.
>  
>  It's not just an issue for systemd-homed, this problem applies to any
>  user home encryption implementation when the user has not first
>  authenticated/unlocked their user home. e.g. if you install with /home
>  encrypted in Anaconda, in fact your boot stops at plymouth in the
>  initramfs so sshd is thwarted from even starting in the first place;
>  and even if GNOME Shell's login were to be enhanced to do this unlock,
>  still requires unlock. 
That is simply not the case. I don't know what you're referring to with "if 
you install with /home encrypted in Anaconda", or why GNOME Shell would have 
anything to ssh, however with Plasma, my desktop environment doesn't have to 
be loaded at all in order for me to ssh in.

>  Basically you have to choose between user home security (or more
>  specifically privacy) and remote logins. However, there are some ideas
>  that could possibly work around this, to varying degrees of
>  inelegance, which I'll gratuitously copy from a related Workstation WG
>  issue [1]. 
You really don't. It's pretty much there by default, and there's not a lot 
that I have to change from a default Plasma install. Doing an Anaconda guided 
LVM full disk encryption setup is sufficient to protect data at rest.

>  1. Enhance openssh's PAM support 
What do you believe needs to be "enhanced"?

>  2. Stub account to ssh into, whereby the user is prompted to
>  authenticate+unlock the real account; and now ssh into the real
>  account. 
Why should somebody have to create TWO accounts in order to access their 
system?

>  3. Same as 2 but maybe it's possible to bind mount the real home
> dir
>  over the stub home dir, eliminating the 2nd login? (Vaguely recall
>  reading about this somewhere, maybe Ubuntu's use of ecryptfs based
>  home, now since deprecated in favor of LUKS) 
If we really wanted to, that's possible now, without systemd-homed.

>  4. If based on any fscrypt implementation, exclude ~/.ssh/ from
> encryption 
That's a bad idea. That directory, by default, contains ssh private keys, as 
well as the list of authorized keys. A better workaround would be similar to 
what is already implemented for sssd, where a proxy command is used to get the 
authorized keys for an account.

-- 
John M. Harris, Jr.
Splentity

[Lennart Poettering]

On Mo, 02.12.19 10:44, John M. Harris Jr (johnmh(a)splentity.com) wrote:

>  On Monday, December 2, 2019 9:48:05 AM MST Przemek Klosowski via
> devel wrote:
>  > On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote:
>  > > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote:
>  > >> Mayyyybee systemd-homed is in
>  > >> a position to solve this by having early enough authentication
>  > >> capability by rescue.target time that any admin user can login?
>  > >
>  > > Actually, it may. Things are confusing here, because systemd-homed is
>  > > implemented together with changes to how user metadata querying is done:
>  > > instead of using dbus, a brokerless and much simpler varlink query is
>  > > used.
>  > > That last part is what would be relevant to early-boot logins, because
>  > > less services need to be up to bring up the user session.
>  >
>  > There's one tricky feature of homed : remote login (ssh) is only
>  > possible after an initial local login. It is OK for his intended use (a
>  > personal laptop/tablet client), except for corner cases like a remotely
>  > accessed personal desktop in the basement that might get rebooted e.g.
>  > for updates, resulting in an accidental lockout.
>
>  Basically, systemd-homed is useless for any power user, but might be useful
>  for people just getting into GNU/Linux, who don't use ssh yet or don't have
>  more than one system. 
You can SSH into a systemd-homed account just fine, you just need to
unlock the home directory once first, for example by logging in
locally. The key to unlock the home directory needs to come from
somewhere, hence a PAM authentication has to take place once, so that
systemd-homed can derive the LUKS key once from the pw you
enter. However, if you never authenticated via PAM (but via ssh
authorized keys only) then there's no pw to unlock the volume with.

It's exactly the same as with LUKS encrypted traditional /home or root
btw, except that the unlocking is moved a bit later: i.e. things are
just much worse there, because you have to enter the pw at boot
already and thus your secrets are already unlocked when you haven't
even logged in.

Also note that on Fedora Workstation we default to suspend-on-idle
these days. i.e. when you don't actually work on the laptop the laptop
is suspended and not reachable via SSH at all, hence adding
systemd-homed doesn't make anything worse in that regard...

Lennart

--
Lennart Poettering, Berlin

[Lennart Poettering]

On Mo, 02.12.19 12:39, Chris Murphy (lists(a)colorremedies.com) wrote:

>  Basically you have to choose between user home security (or more
>  specifically privacy) and remote logins. However, there are some
>  ideas that could possibly work around this, to varying degrees of
>  inelegance, which I'll gratuitously copy from a related Workstation
>  WG issue [1].
>
>  1. Enhance openssh's PAM support
>  2. Stub account to ssh into, whereby the user is prompted to
>  authenticate+unlock the real account; and now ssh into the real
>  account.
>  3. Same as 2 but maybe it's possible to bind mount the real home dir
>  over the stub home dir, eliminating the 2nd login? (Vaguely recall
>  reading about this somewhere, maybe Ubuntu's use of ecryptfs based
>  home, now since deprecated in favor of LUKS)
>  4. If based on any fscrypt implementation, exclude ~/.ssh/ from
>  encryption 
systemd-homed integrates with sshd's AuthorizedKeysCommand and
supplies any SSH keys assoicated with the user account directly to SSH
without anyone needing access ~/.ssh/. i.e. integration with SSH is
actually already in place.

The problem is that sshd's PAM implementation doesn't allow PAM
modules to ask questions in login sessions which are authenticated via
authorized_keys instead of PAM. Because if we could ask questions
then, we could simply ask the user for the passphrase to derive the
LUKS key from if we need. That would mean that if you SSH login if you
already are logged in locally, then logins would be instant, but if
you SSH login otherwise then you'd get a prompt for the pw first.

Lennart

--
Lennart Poettering, Berlin

[John M. Harris Jr]

On Tuesday, December 3, 2019 1:18:57 AM MST Lennart Poettering wrote:
>  systemd-homed integrates with sshd's AuthorizedKeysCommand and
>  supplies any SSH keys assoicated with the user account directly to SSH
>  without anyone needing access ~/.ssh/. i.e. integration with SSH is
>  actually already in place. 
Excellent, that's what I mentioned in the other subthread. Does this use 
sssd's existing AuthorizedKeysCommand, or would it interfere with it?

>  The problem is that sshd's PAM implementation doesn't allow
> PAM
>  modules to ask questions in login sessions which are authenticated via
>  authorized_keys instead of PAM. Because if we could ask questions
>  then, we could simply ask the user for the passphrase to derive the
>  LUKS key from if we need. That would mean that if you SSH login if you
>  already are logged in locally, then logins would be instant, but if
>  you SSH login otherwise then you'd get a prompt for the pw first. 
Is the key's passphrase always going to be based on the user's password with 
systed-homed? Is there a mechanism to use a separate password?

-- 
John M. Harris, Jr.
Splentity

[Lennart Poettering]

On Di, 03.12.19 01:29, John M. Harris Jr (johnmh(a)splentity.com) wrote:

>  > The problem is that sshd's PAM implementation doesn't
> allow PAM
>  > modules to ask questions in login sessions which are authenticated via
>  > authorized_keys instead of PAM. Because if we could ask questions
>  > then, we could simply ask the user for the passphrase to derive the
>  > LUKS key from if we need. That would mean that if you SSH login if you
>  > already are logged in locally, then logins would be instant, but if
>  > you SSH login otherwise then you'd get a prompt for the pw first.
>
>  Is the key's passphrase always going to be based on the user's password with
>  systed-homed? Is there a mechanism to use a separate password? 
In theory the infrastructure would allow that, but systemd-homed's
idea is really to unify authentication, and make disk encryption part
of the user account an implementation detail. Hence, in systemd-homed
you can have N passwords and M PKCS#11 tokens (i.e. yubikeys) and
these translate to N+M keyslots on the LUKS volume, so that any
supplied password or any supplied yubikey unlocks the whole stack.

(And N and M can individually be zero, but N+M must be > 0)

(And systemd-homed also supports ext4 encryption as backend, as well
as unencrypted backends, and authentication works the same there
except that the keys are never propagated to any storage backend
because the storage backend has no interest in cryptographic key
material)

Lennart

--
Lennart Poettering, Berlin

[Michael Catanzaro]

On Tue, Dec 3, 2019 at 9:07 am, Lennart Poettering 
<mzerqung(a)0pointer.de&gt; wrote:
>  Also note that on Fedora Workstation we default to suspend-on-idle
>  these days. i.e. when you don't actually work on the laptop the laptop
>  is suspended and not reachable via SSH at all, hence adding
>  systemd-homed doesn't make anything worse in that regard... 
Hi,

A clarification. This is true upstream, but in Fedora it is only true 
for laptops on battery power. Desktops and laptops that are plugged in 
do not suspend on idle (unless you have changed the settings from our 
defaults).

It would be unusual to SSH into a laptop on battery power unless you 
are physically present in the room (since it could run out of power).

Michael

[Przemek Klosowski]

On 12/3/19 1:57 AM, John M. Harris Jr wrote:
>  On Monday, December 2, 2019 12:46:30 PM MST Chris Murphy wrote:
> > It's almost 2020, and I shouldn't have to pick and choose between
> > remote access and securing user data at rest by default.
>  You don't have to. Data at rest would mean that your system is powered off, or
>  suspended to disk. You can have that now with full disk encryption, just as I
>  do. Depending on your system, you can actually encrypt the entire disk such
>  that you don't even have a partition table. I do this with my X200 Tablet,
>  where GRUB is loaded from flash, which decrypts my disk, and then mounts ZFS
>  mountpoints, swaps on a ZFS zdev. 
I think Chris is referring to the fact that you have to be there when 
the encrypted system is restarted, to type the decryption key/password. 
The dilemma is this: if the decryption is automatic, it doesn't really 
protect the data at rest, because the boot process is not secured like 
it is on Android or IOS, and therefore the intruders could get in and 
access the now-unencrypted disk.

It is conceivable  to set up some sort of location-based decryption, 
where you would not have to give the password if the system is on a 
known network, authenticating through a trusted interface to a known 
host, but it's not a solved problem.

[Chris Murphy]

On Mon, Dec 2, 2019 at 11:58 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Monday, December 2, 2019 12:46:30 PM MST Chris Murphy wrote:
>  > It's almost 2020, and I shouldn't have to pick and choose between
>  > remote access and securing user data at rest by default.
>
>  You don't have to. Data at rest would mean that your system is powered off, or
>  suspended to disk. You can have that now with full disk encryption, just as I
>  do. Depending on your system, you can actually encrypt the entire disk such
>  that you don't even have a partition table. I do this with my X200 Tablet,
>  where GRUB is loaded from flash, which decrypts my disk, and then mounts ZFS
>  mountpoints, swaps on a ZFS zdev. 
OK you just took a 90 degree turn, detouring the line of discussion,
which was your premise that systemd-homed is pointless if the user
can't ssh into it. There is no difference between a systemd-homed
encrypted user home, and FDE, in this respect. Someone must type in a
passphrase to unlock the volume that contains the user home you want
access to it with ssh, in both cases. In your case you have to
physically type that passphrase when you startup, at plymouth. In the
systemd-homed case, login and crypto home unlock are tied together.

I actually prefer the idea that'd if I'm not logged in, my data is
considered at rest and crypto home is locked, in contrast to how FDE
does it which treats my data as not at rest even though I'm not logged
in at all.

Trying to get back on track with this thread though, if systemd-homed
is available by the time startup reaches rescue.target, does this
somewhat confuse the distinction of whatever multi-user.target is,
which would then rather be more like manyservices.target in contrast
to fewservices.target? I also don't know if systemd-homed is simple
enough that it's a good idea to make it available by rescue.target.
But then, also what about emergency.target which is even more
rudimentary and likewise requires root?

systemd.debug-shell=1 does provide a root shell on tty9, by the time
rescue.target is reached. And in that shell I can extract
rdsosreport.txt or a full journal among other things, and get running
again. It's admittedly obscure knowledge though.


-- 
Chris Murphy

[Chris Murphy]

On Tue, Dec 3, 2019 at 12:05 AM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  > It's not just an issue for systemd-homed, this problem applies to any
>  > user home encryption implementation when the user has not first
>  > authenticated/unlocked their user home. e.g. if you install with /home
>  > encrypted in Anaconda, in fact your boot stops at plymouth in the
>  > initramfs so sshd is thwarted from even starting in the first place;
>  > and even if GNOME Shell's login were to be enhanced to do this unlock,
>  > still requires unlock.
>
>  That is simply not the case. I don't know what you're referring to with "if
>  you install with /home encrypted in Anaconda", 
Anaconda custom partitioning has a per mount point encryption option.
I can LUKS encrypt only the volume mounted at /home. And if I do this,
startup is inhibited at a plymouth prompt for a passphrase, the same
as if I check the earlier "encrypt my data" option at Destination
Installation - which is the FDE layout.

sshd doesn't startup until after this. You can't ssh into your system
before user home is unlocked. There is at least a chance of this with
systemd-homed even if it's not yet implemented.


> or why GNOME Shell would have
>  anything to ssh, however with Plasma, my desktop environment doesn't have to
>  be loaded at all in order for me to ssh in. 
That's because you are physically present to type in a passphrase
during boot. And that exposes all user data as plaintext too, in the
FDE case. The only thing protecting user data are discretionary access
controls.

The reason for a full desktop environment stack being available at
LUKS unlock time has to do with various UX problems with the much more
limited initramfs+plymouth environment. This is elaborated on in the
Workstation WG issue I referenced. An open question is to what degree
we run into those same kinds of problems with remote login.


>  > Basically you have to choose between user home security (or more
>  > specifically privacy) and remote logins. However, there are some ideas
>  > that could possibly work around this, to varying degrees of
>  > inelegance, which I'll gratuitously copy from a related Workstation WG
>  > issue [1].
>
>  You really don't. It's pretty much there by default, and there's not a lot
>  that I have to change from a default Plasma install. Doing an Anaconda guided
>  LVM full disk encryption setup is sufficient to protect data at rest. 
It's a valid argument that when a user is not logged in, their data
should be at rest and encrypted. systemd-homed is one possible way to
address that, not necessarily the only way, but for sure the current
options in the installer don't address it.


--
Chris Murphy

[Kevin Kofler]

John M. Harris Jr wrote:
>  however with Plasma, my desktop environment doesn't have to be
> loaded at
>  all in order for me to ssh in. 
This depends (even in the absence of disk encryption) on where you have told 
plasma-nm to store your WPA (or 802.11x etc.) credentials (unless you are 
using an entirely open network). (The credential storage strategy is 
configurable in plasma-nm.)

If the credentials are stored in system-wide unencrypted storage, you can 
SSH in immediately. If they are stored in your KWallet, you have to log in 
first so that plasma-nm knows what wallet to unlock, and if you use the 
default setup, so that the KWallet PAM module can use your login password to 
unlock your wallet. (You can also have an entirely passwordless KWallet, but 
even that would not help you in this case because NM would still not know 
where to look for your credentials. You need to have plasma-nm running, and 
as the correct user, to get working KWallet NM integration.) And if you use 
a non-empty KWallet password that is not your login password, you also have 
to enter that, of course.

        Kevin Kofler

[Kevin Kofler]

Lennart Poettering wrote:
>  The problem is that sshd's PAM implementation doesn't allow
> PAM
>  modules to ask questions in login sessions which are authenticated via
>  authorized_keys instead of PAM. Because if we could ask questions
>  then, we could simply ask the user for the passphrase to derive the
>  LUKS key from if we need. That would mean that if you SSH login if you
>  already are logged in locally, then logins would be instant, but if
>  you SSH login otherwise then you'd get a prompt for the pw first. 
I think a proper SSH integration would actually store a LUKS keyfile 
encrypted with the SSH public key somewhere in .ssh, and on login, send that 
to the client, have that decrypt it with the SSH private key and send it 
back, and use the decrypted key to unlock the LUKS partition.

        Kevin Kofler

[John M. Harris Jr]

On Tuesday, December 3, 2019 6:02:57 PM MST Chris Murphy wrote:
>  sshd doesn't startup until after this. You can't ssh into
> your system
>  before user home is unlocked. There is at least a chance of this with
>  systemd-homed even if it's not yet implemented. 
For the record, it is not unheard of for LUKS encrypted systems to use 
something like dracut-crypt-ssh or dracut-sshd in order to unlock their system 
during initramfs.

>  That's because you are physically present to type in a
> passphrase
>  during boot. And that exposes all user data as plaintext too, in the
>  FDE case. The only thing protecting user data are discretionary access
>  controls. 
How does that "expose[] all user data as plaintext"?

>  The reason for a full desktop environment stack being available at
>  LUKS unlock time has to do with various UX problems with the much more
>  limited initramfs+plymouth environment. This is elaborated on in the
>  Workstation WG issue I referenced. An open question is to what degree
>  we run into those same kinds of problems with remote login. 
I would have to disagree with that, but I don't have a dog in that fight for 
GNOME anyway.

>  It's a valid argument that when a user is not logged in, their
> data
>  should be at rest and encrypted. systemd-homed is one possible way to
>  address that, not necessarily the only way, but for sure the current
>  options in the installer don't address it. 
I don't see how redefining "at rest" is useful here. Especially because, I 
can't imagine a time where my user isn't logged in in one way or another, or a 
user that has permissions to enter my home directory is logged in. Further, 
when one of their cron jobs run, or a systemd user service runs, would that 
use a cached key to unlock their home directory?

While some users might not be logged in constantly (either graphically, via 
SSH, a virtual terminal, screen/tmux session or whatever), it is much more 
common for users to have cron jobs or user units set up.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Tuesday, December 3, 2019 6:57:37 PM MST Kevin Kofler wrote:
>  This depends (even in the absence of disk encryption) on where you
> have told
>   plasma-nm to store your WPA (or 802.11x etc.) credentials (unless you are
>  using an entirely open network). (The credential storage strategy is
>  configurable in plasma-nm.) 
Of course, that would be for wireless systems, or systems with 802.1X not 
using host certificates.

For my own setup, this is not an issue, because I use FreeIPA provisioning 
certificates for WPA2 EAP-TLS for wireless and 802.1X EAP-TLS for wired 
clients. I can definitely see how that would apply to most wireless users 
though. I definitely overlooked ssh'ing into systems that are primarily 
wireless.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Tuesday, December 3, 2019 12:35:01 PM MST Przemek Klosowski via devel 
wrote:
>  I think Chris is referring to the fact that you have to be there when
>
>  the encrypted system is restarted, to type the decryption key/password. 
>  The dilemma is this: if the decryption is automatic, it doesn't really 
>  protect the data at rest, because the boot process is not secured like 
>  it is on Android or IOS, and therefore the intruders could get in and 
>  access the now-unencrypted disk.
>  
>  It is conceivable  to set up some sort of location-based decryption, 
>  where you would not have to give the password if the system is on a 
>  known network, authenticating through a trusted interface to a known 
>  host, but it's not a solved problem. 
There are solutions for this, in the form of dracut modules that spawn an SSH 
server, and wait for you to connect and unlock the system, if you are not 
available to unlock it physically.

Network based decryption keys are possible, but I don't recommend it, because 
there's no way to determine that the user booting up the system is actually 
meant to have access to the data that's on it. However, if you're interested 
in network based keys for that purpose, that'd be a surprisingly simple 
project. I believe there was a blog post from a Red Hat engineer a few years 
ago about network based luks volume decryption.

-- 
John M. Harris, Jr.
Splentity

[Lennart Poettering]

On Mi, 04.12.19 03:09, Kevin Kofler (kevin.kofler(a)chello.at) wrote:

>  Lennart Poettering wrote:
>  > The problem is that sshd's PAM implementation doesn't allow PAM
>  > modules to ask questions in login sessions which are authenticated via
>  > authorized_keys instead of PAM. Because if we could ask questions
>  > then, we could simply ask the user for the passphrase to derive the
>  > LUKS key from if we need. That would mean that if you SSH login if you
>  > already are logged in locally, then logins would be instant, but if
>  > you SSH login otherwise then you'd get a prompt for the pw first.
>
>  I think a proper SSH integration would actually store a LUKS keyfile
>  encrypted with the SSH public key somewhere in .ssh, and on login, send that
>  to the client, have that decrypt it with the SSH private key and send it
>  back, and use the decrypted key to unlock the LUKS partition. 
To my knowledge the SSH protocol doesn't have provisions for allowing
that. i.e. there's no API and no protocol for allowing apps on the
server to ask for decryption of arbitrary blobs from the client.

I mean, I am happy to support anything that we can do, but I am not
sure I want to get involved with SSH enough to amend protocol and
implementation for this, given that I don't even think it's as crucial
as some people think it is...

Lennart

--
Lennart Poettering, Berlin

[Lennart Poettering]

On Mi, 04.12.19 03:12, John M. Harris Jr (johnmh(a)splentity.com) wrote:

>  I don't see how redefining "at rest" is useful here.
> Especially because, I
>  can't imagine a time where my user isn't logged in in one way or another, or a
>  user that has permissions to enter my home directory is logged in. Further,
>  when one of their cron jobs run, or a systemd user service runs, would that
>  use a cached key to unlock their home directory? 
in systemd-homed cronjobs can't run as long as you aren't logged
in. If you are logged in all is good and they run as they
traditionally did, but if you aren't logged in then the LUKS volume is locked
and there's no password available from cron we could use to unlock the
volume.

It's a feature not a bug though: systemd-homed gives you much stronger
security guarantees: as long as you are present on the device the
device has can access the data on behalf of you. But as soon as you
leave (by logging out or suspending the machine) the data as locked
and the keys removed from memory so that access is logically
impossible.

(One thinkable extension of homed's current model btw is to support
logind lingering by asking for the user pw using plymouth. this would
then mean you'd be asked to unlock your user during early boot like as
with classic disk encryption, and then it remains unlocked for the
entire lifetime of the system. But I am not sure it's worth it, if you
are happy with such a much weaker model you might as well use regular
full disk encryption and have the home dirs themselves just be plain
directories)

Lennart

--
Lennart Poettering, Berlin

[Lennart Poettering]

On Di, 03.12.19 16:28, Chris Murphy (lists(a)colorremedies.com) wrote:

>  Trying to get back on track with this thread though, if
> systemd-homed
>  is available by the time startup reaches rescue.target, does this
>  somewhat confuse the distinction of whatever multi-user.target is,
>  which would then rather be more like manyservices.target in contrast
>  to fewservices.target? I also don't know if systemd-homed is simple
>  enough that it's a good idea to make it available by rescue.target.
>  But then, also what about emergency.target which is even more
>  rudimentary and likewise requires root? 
The only thing stopping systemd-homed to run in early boot is D-Bus:
communication with systemd-homed is mostly D-Bus and that is run after
basic.target, hence logging earlier into home directories managed by
homed is not doable (at least how things are right now).

Lennart

--
Lennart Poettering, Berlin

[John M. Harris Jr]

On Wednesday, December 4, 2019 3:53:08 AM MST Lennart Poettering wrote:
>  To my knowledge the SSH protocol doesn't have provisions for
> allowing
>  that. i.e. there's no API and no protocol for allowing apps on the
>  server to ask for decryption of arbitrary blobs from the client.
>  
>  I mean, I am happy to support anything that we can do, but I am not
>  sure I want to get involved with SSH enough to amend protocol and
>  implementation for this, given that I don't even think it's as crucial
>  as some people think it is... 
Well, you could theoretically use ssh-agent (or equivalent), without changing 
the protocol in any way.

-- 
John M. Harris, Jr.
Splentity

[Roberto Ragusa]

On 12/4/19 12:28 AM, Chris Murphy wrote:

>  I actually prefer the idea that'd if I'm not logged in, my
> data is
>  considered at rest and crypto home is locked, in contrast to how FDE
>  does it which treats my data as not at rest even though I'm not logged
>  in at all. 
On the other hand I would expect my cronjobs to be able to run "as me"
even if I'm not physically present.
This "logged in" concept coming from Windows and OS X never fits too well
with Linux.

Regards.

-- 
    Roberto Ragusa    mail at robertoragusa.it

[Chris Murphy]

On Wed, Dec 4, 2019 at 9:01 AM Roberto Ragusa <mail(a)robertoragusa.it&gt; wrote:
>  On 12/4/19 12:28 AM, Chris Murphy wrote:
>
>  > I actually prefer the idea that'd if I'm not logged in, my data is
>  > considered at rest and crypto home is locked, in contrast to how FDE
>  > does it which treats my data as not at rest even though I'm not logged
>  > in at all.
>
>  On the other hand I would expect my cronjobs to be able to run "as me"
>  even if I'm not physically present.
>  This "logged in" concept coming from Windows and OS X never fits too well
>  with Linux. 
It's a valid use case that is being taken into account. The open
question is the degree of "lock down" by default. You'd still be able
to opt out of login being tied to ~/ encryption, if that is
incongruent with your workflow. And you'd still be able to opt into a
conventional full disk encryption scheme instead.

Other alternatives:
a. At least on ext4, you can today selectively encrypt directories and
files, so you could have an non-encrypted ~/ by default, and choose
what directories to encrypt. There's no GUI assistance for this yet
that I'm aware of.
b. If you can clearly compartmentalize our use cases, you can have two
accounts, one is encrypted and other not.

I think the later two put a lot of burden on the user to figure out
and manage. I'm not sure there's a way for GNOME or systemd-homed to
directly support such use cases, but I also don't expect it would
stand in the way of user implementation of such a scheme.

-- 
Chris Murphy

[Przemek Klosowski]

On 12/4/19 5:25 AM, John M. Harris Jr wrote:
>  Network based decryption keys are possible, but I don't recommend
> it, because
>  there's no way to determine that the user booting up the system is actually
>  meant to have access to the data that's on it. 
There are two distinct thread models :

- stolen/lost laptop:  I think this is the most important one for most  
people; it is mitigaged by a trusted-network-based decryption, unless 
the device is in unencrypted sleep mode and the new 'beneficial owner' 
manages to read the disk before the system goes down.

- someone breaks into your home/office/hotel room and extracts the data: 
important to some people but not very common scenario.

You are correct that it's hard to mitigate both of those threats, but I 
think the first one is the primary concern.

To be clear, I was suggesting a network scheme where your device 
authenticates from e.g. a trusted subnet to a known server IP with a 
specific certificate associated with this IP. To defeat this, you can't 
just set up a a fake IP network ---you would have to somehow break into 
(physically or at least electronically) the trusted subnet.

By the way, as I said. Android/IOS solved those issues by having a 
secure boot process, so the OS can fully boot and will keep the secrets 
until local ( or possibly remote) authentication. So this is a solved 
problem, and perhaps we should be looking into securing the full boot 
process instead of trying to mitigate threats resulting from the holes 
in it.

[Marius Schwarz]

Am 03.12.19 um 09:07 schrieb Lennart Poettering:
>  Also note that on Fedora Workstation we default to suspend-on-idle
>  these days. i.e. when you don't actually work on the laptop the laptop
>  is suspended and not reachable via SSH at all, hence adding
>  systemd-homed doesn't make anything worse in that regard...
>  
How do you wanne access data on your homeserver, when you are at work?

The system will idle, will go into suspend and you can't access it anymore?

I really hope, it's easily configureable, otherwise it will end up here
"dnf erase".

best regards,
Marius

[Marius Schwarz]

Am 04.12.19 um 02:02 schrieb Chris Murphy:
>  Anaconda custom partitioning has a per mount point encryption
> option.
>  I can LUKS encrypt only the volume mounted at /home. And if I do this, 
If you do
this, someone can manipulate your system to trojan horse your
passwords,
when he has physical access to it.

Full-Diskencryption ( /boot included ) is the only way to protect the
system itself.
Anything else is simply not secure.

best regards,
Marius

[Chris Murphy]

On Wed, Dec 4, 2019 at 4:22 PM Marius Schwarz <fedoradev(a)cloud-foo.de&gt; wrote:
>  Am 03.12.19 um 09:07 schrieb Lennart Poettering:
>  > Also note that on Fedora Workstation we default to suspend-on-idle
>  > these days. i.e. when you don't actually work on the laptop the laptop
>  > is suspended and not reachable via SSH at all, hence adding
>  > systemd-homed doesn't make anything worse in that regard...
>  >
>
>  How do you wanne access data on your homeserver, when you are at work? 
And how do you want to protect it, when you're at work?

>  The system will idle, will go into suspend and you can't access it anymore? 
You do understand that present day suspend to RAM, the encryption keys
are in memory and your data is not protected at rest? Locking ~/ prior
to suspend is a feature. It's intentional that you can't access ~/
until you authenticate again. The challenge is how to make remote
authentication that does both login and ~/ unlock possible.

>  I really hope, it's easily configureable, otherwise it will end up here
>  "dnf erase". 
The challenge will be how to convey the configuration, and its
different consequences to the user. And it's not even decided what the
default behaviors would be.

-- 
Chris Murphy

[John M. Harris Jr]

On Wednesday, December 4, 2019 12:00:06 PM MST Chris Murphy wrote:
>  Other alternatives:
>  a. At least on ext4, you can today selectively encrypt directories and
>  files, so you could have an non-encrypted ~/ by default, and choose
>  what directories to encrypt. There's no GUI assistance for this yet
>  that I'm aware of.
>  b. If you can clearly compartmentalize our use cases, you can have two
>  accounts, one is encrypted and other not.
>  
>  I think the later two put a lot of burden on the user to figure out
>  and manage. I'm not sure there's a way for GNOME or systemd-homed to
>  directly support such use cases, but I also don't expect it would
>  stand in the way of user implementation of such a scheme. 
"Alternative" B is a complete cop-out. It's essentially ignoring the fault 
entirely, and blaming the using for wanting to do something the traditional 
way.

That is a workaround, not a solution.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Wednesday, December 4, 2019 4:40:14 PM MST Marius Schwarz wrote:
>  Am 04.12.19 um 02:02 schrieb Chris Murphy:
>  
>  > Anaconda custom partitioning has a per mount point encryption option.
>  > I can LUKS encrypt only the volume mounted at /home. And if I do this,
>  
>  If you do this, someone can manipulate your system to trojan horse your
>  passwords,
>  when he has physical access to it.
>  
>  Full-Diskencryption ( /boot included ) is the only way to protect the
>  system itself.
>  Anything else is simply not secure.
>  
>  best regards,
>  Marius 
Agreed. One of the most common solutions to this is coreboot with a GRUB 
payload.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Wednesday, December 4, 2019 12:38:20 PM MST Przemek Klosowski via devel 
wrote:
>  - stolen/lost laptop:  I think this is the most important one for
> most  
>  people; it is mitigaged by a trusted-network-based decryption, unless 
>  the device is in unencrypted sleep mode and the new 'beneficial owner' 
>  manages to read the disk before the system goes down. 
That may be the case for home users, but not for businesses. Let's take this 
example. Employee A has files from a given project, but Employee B doesn't 
have access to that project. Employee B is malicious, and takes Employee A's 
laptop, gets it on the network, it unencrypts itself and then takes it. The 
data is not Employee B's.

>  - someone breaks into your home/office/hotel room and extracts the
> data: 
>  important to some people but not very common scenario. 
This is important to most businesses.

>  You are correct that it's hard to mitigate both of those threats,
> but I 
>  think the first one is the primary concern.
>  
>  To be clear, I was suggesting a network scheme where your device 
>  authenticates from e.g. a trusted subnet to a known server IP with a 
>  specific certificate associated with this IP. To defeat this, you can't 
>  just set up a a fake IP network ---you would have to somehow break into 
>  (physically or at least electronically) the trusted subnet. 
Right, of course. The only method for network based decryption that I am aware 
of is a server that you must set up. I don't think a 

>  By the way, as I said. Android/IOS solved those issues by having a 
>  secure boot process,  
There's nothing inherently "secure" about Android's boot process, though
I'm 
not familiar with that of iOS. Depending on the version, and this is different 
in the most popular fork, a key is either immediately requested to decrypt the 
system or the system itself is unencrypted to begin with, and key is requested 
to decrypt user data.

>  so the OS can fully boot and will keep the secrets 
>  until local ( or possibly remote) authentication. 
See above.

>  So this is a solved problem, and perhaps we should be looking into
> securing
>  the full boot process instead of trying to mitigate threats resulting from
>  the holes in it. 
Well, it really isn't a "solved problem". Most of these "secure
boot" 
solutions don't actually do anything that makes them inherently secure, vboot 
included. They're just trusting a vendor key, by default.

-- 
John M. Harris, Jr.
Splentity

[Chris Murphy]

On Wed, Dec 4, 2019 at 4:41 PM Marius Schwarz <fedoradev(a)cloud-foo.de&gt; wrote:
>  Am 04.12.19 um 02:02 schrieb Chris Murphy:
>  > Anaconda custom partitioning has a per mount point encryption option.
>  > I can LUKS encrypt only the volume mounted at /home. And if I do this,
>  If you do this, someone can manipulate your system to trojan horse your
>  passwords,
>  when he has physical access to it.
>
>  Full-Diskencryption ( /boot included ) is the only way to protect the
>  system itself.
>  Anything else is simply not secure. 
systemd-homed doesn't depend on /etc/passwd or /etc/shadow for
authentication. By all means its security guarantees should be
evaluated.
https://github.com/systemd/systemd/pull/14096

What you're talking about is entirely up to the user to configure
manually. Fedora installations today don't support bootloader lock
down, encrypted /boot, or purging the LUKS key from memory during
suspend, out of the box. And therefore I'm not sure what your goal
posts are, what two things you're comparing.



-- 
Chris Murphy

[John M. Harris Jr]

On Wednesday, December 4, 2019 5:09:55 PM MST Chris Murphy wrote:
>  On Wed, Dec 4, 2019 at 4:41 PM Marius Schwarz
> <fedoradev(a)cloud-foo.de&gt;
>  wrote:
>  >
>  >
>  > Am 04.12.19 um 02:02 schrieb Chris Murphy:
>  > 
>  > > Anaconda custom partitioning has a per mount point encryption option.
>  > > I can LUKS encrypt only the volume mounted at /home. And if I do this,
>  > 
>  > If you do this, someone can manipulate your system to trojan horse your
>  > passwords,
>  > when he has physical access to it.
>  >
>  >
>  >
>  > Full-Diskencryption ( /boot included ) is the only way to protect the
>  > system itself.
>  > Anything else is simply not secure.
>  
>  
>  systemd-homed doesn't depend on /etc/passwd or /etc/shadow for
>  authentication. By all means its security guarantees should be
>  evaluated.
>  https://github.com/systemd/systemd/pull/14096
>  
>  What you're talking about is entirely up to the user to configure
>  manually. Fedora installations today don't support bootloader lock
>  down, encrypted /boot, or purging the LUKS key from memory during
>  suspend, out of the box. And therefore I'm not sure what your goal
>  posts are, what two things you're comparing. 
It may be the case that the GNOME Spin doesn't support that, but it is 
supported with the KDE Spin. I don't think it's likely that anything in the 
GNOME image would break that, but it's possible I suppose.

-- 
John M. Harris, Jr.
Splentity

[Chris Murphy]

On Wed, Dec 4, 2019 at 4:59 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Wednesday, December 4, 2019 12:00:06 PM MST Chris Murphy wrote:
>  > Other alternatives:
>  > a. At least on ext4, you can today selectively encrypt directories and
>  > files, so you could have an non-encrypted ~/ by default, and choose
>  > what directories to encrypt. There's no GUI assistance for this yet
>  > that I'm aware of.
>  > b. If you can clearly compartmentalize our use cases, you can have two
>  > accounts, one is encrypted and other not.
>  >
>  > I think the later two put a lot of burden on the user to figure out
>  > and manage. I'm not sure there's a way for GNOME or systemd-homed to
>  > directly support such use cases, but I also don't expect it would
>  > stand in the way of user implementation of such a scheme.
>
>  "Alternative" B is a complete cop-out. It's essentially ignoring the fault
>  entirely, and blaming the using for wanting to do something the traditional
>  way.
>
>  That is a workaround, not a solution. 
It's a fair criticism, but it's also not a solution I'm advocating as
a default behavior either.

You know what is a work around and not a solution and is default? ~/
isn't encrypted. And the two install time options insist on restricted
character sets for the passphrase, the user must not change their
keyboard layout, or their keyboard to one with a different keymapping
- lest they experience data loss.

The traditional way is unquestionably hostile to international users,
and doing better, however untraditional, is absolutely something I
strongly favor.

-- 
Chris Murphy

[John M. Harris Jr]

On Wednesday, December 4, 2019 5:28:17 PM MST Chris Murphy wrote:
>  You know what is a work around and not a solution and is default? ~/
>  isn't encrypted. And the two install time options insist on restricted
>  character sets for the passphrase, the user must not change their
>  keyboard layout, or their keyboard to one with a different keymapping
>  - lest they experience data loss. 
$HOME is encrypted if you put it on an encrypted filesystem. Additionally, 
that Anaconda restricts what the passphrase for the key sounds like a bug in 
Anaconda. The user can change their keyboard layout. That's fine. It wouldn't 
cause data loss. However, it would make it more difficult to unlock the 
system, if they forget they've changed the keyboard layout and regenerated 
their initramfs. (If they do it globally, if they just do it once the OS is 
booted, then they're good to go.)

>  The traditional way is unquestionably hostile to international
> users,
>  and doing better, however untraditional, is absolutely something I
>  strongly favor. 
How is it "hostile to international users"? "international users"
generally 
set their keyboard layout to the one they use primarily.. Just like everyone 
else :)

-- 
John M. Harris, Jr.
Splentity

[Chris Murphy]

On Wed, Dec 4, 2019 at 5:14 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Wednesday, December 4, 2019 5:09:55 PM MST Chris Murphy wrote:
>  > On Wed, Dec 4, 2019 at 4:41 PM Marius Schwarz <fedoradev(a)cloud-foo.de&gt;
>  > wrote:
>  > >
>  > >
>  > > Am 04.12.19 um 02:02 schrieb Chris Murphy:
>  > >
>  > > > Anaconda custom partitioning has a per mount point encryption option.
>  > > > I can LUKS encrypt only the volume mounted at /home. And if I do this,
>  > >
>  > > If you do this, someone can manipulate your system to trojan horse your
>  > > passwords,
>  > > when he has physical access to it.
>  > >
>  > >
>  > >
>  > > Full-Diskencryption ( /boot included ) is the only way to protect the
>  > > system itself.
>  > > Anything else is simply not secure.
>  >
>  >
>  > systemd-homed doesn't depend on /etc/passwd or /etc/shadow for
>  > authentication. By all means its security guarantees should be
>  > evaluated.
>  > https://github.com/systemd/systemd/pull/14096
>  >
>  > What you're talking about is entirely up to the user to configure
>  > manually. Fedora installations today don't support bootloader lock
>  > down, encrypted /boot, or purging the LUKS key from memory during
>  > suspend, out of the box. And therefore I'm not sure what your goal
>  > posts are, what two things you're comparing.
>
>  It may be the case that the GNOME Spin doesn't support that, but it is
>  supported with the KDE Spin. I don't think it's likely that anything in the
>  GNOME image would break that, but it's possible I suppose. 
I have no idea what you mean by "supported" nor which of the multiple
characteristics I listed you think apply to Fedora KDE.

What I mean by support = that which Fedora produces in release
blocking desktops, most typically in a default configuration, and for
which release criteria have been written. None of the things I wrote
apply to Fedora KDE either, so it's simply not correct to call them
supported. The functionality may exist in KDE, but that's not the same
thing as what Fedora supports. And I did very clearly write "Fedora
installations today don't support..."



-- 
Chris Murphy

[John M. Harris Jr]

On Wednesday, December 4, 2019 5:41:13 PM MST Chris Murphy wrote:
>  On Wed, Dec 4, 2019 at 5:14 PM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  wrote:
>  >
>  >
>  > On Wednesday, December 4, 2019 5:09:55 PM MST Chris Murphy wrote:
>  > 
>  > > On Wed, Dec 4, 2019 at 4:41 PM Marius Schwarz <fedoradev(a)cloud-foo.de&gt;
>  > > wrote:
>  > > 
>  > > >
>  > > >
>  > > >
>  > > > Am 04.12.19 um 02:02 schrieb Chris Murphy:
>  > > >
>  > > >
>  > > >
>  > > > > Anaconda custom partitioning has a per mount point encryption
>  > > > > option.
>  > > > > I can LUKS encrypt only the volume mounted at /home. And if I do
>  > > > > this,
>  > > >
>  > > >
>  > > >
>  > > > If you do this, someone can manipulate your system to trojan horse
>  > > > your
>  > > > passwords,
>  > > > when he has physical access to it.
>  > > >
>  > > >
>  > > >
>  > > >
>  > > >
>  > > > Full-Diskencryption ( /boot included ) is the only way to protect the
>  > > > system itself.
>  > > > Anything else is simply not secure.
>  > >
>  > >
>  > >
>  > >
>  > > systemd-homed doesn't depend on /etc/passwd or /etc/shadow for
>  > > authentication. By all means its security guarantees should be
>  > > evaluated.
>  > > https://github.com/systemd/systemd/pull/14096
>  > >
>  > >
>  > >
>  > > What you're talking about is entirely up to the user to configure
>  > > manually. Fedora installations today don't support bootloader lock
>  > > down, encrypted /boot, or purging the LUKS key from memory during
>  > > suspend, out of the box. And therefore I'm not sure what your goal
>  > > posts are, what two things you're comparing.
>  >
>  >
>  >
>  > It may be the case that the GNOME Spin doesn't support that, but it is
>  > supported with the KDE Spin. I don't think it's likely that anything in
>  > the GNOME image would break that, but it's possible I suppose.
>  
>  
>  I have no idea what you mean by "supported" nor which of the multiple
>  characteristics I listed you think apply to Fedora KDE.
>  
>  What I mean by support = that which Fedora produces in release
>  blocking desktops, most typically in a default configuration, and for
>  which release criteria have been written. None of the things I wrote
>  apply to Fedora KDE either, so it's simply not correct to call them
>  supported. The functionality may exist in KDE, but that's not the same
>  thing as what Fedora supports. And I did very clearly write "Fedora
>  installations today don't support..." 
Fedora supports installation on ARM devices with vboot today.

-- 
John M. Harris, Jr.
Splentity

[Chris Murphy]

On Wed, Dec 4, 2019 at 5:38 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Wednesday, December 4, 2019 5:28:17 PM MST Chris Murphy wrote:
>  > You know what is a work around and not a solution and is default? ~/
>  > isn't encrypted. And the two install time options insist on restricted
>  > character sets for the passphrase, the user must not change their
>  > keyboard layout, or their keyboard to one with a different keymapping
>  > - lest they experience data loss.
>
>  $HOME is encrypted if you put it on an encrypted filesystem 
You have a particular knack for pointing out the obvious as if you
think everyone is a moron. It's variably amusing and annoying.

> Additionally,
>  that Anaconda restricts what the passphrase for the key sounds like a bug in
>  Anaconda. 
The idea is to protect the user from using characters that can't be
passed via plymouth to cryptsetup during startup. Known problem, I've
only cited it a couple times in this thread.

> The user can change their keyboard layout. That's fine. It
> wouldn't
>  cause data loss. 
The user experience is identical to data loss. The passphrase is
considered wrong, there's no feedback whatsoever to the user that the
keymapping has changed, that this is the actual problem.

https://drive.google.com/open?id=1imiPyYBiTcE3zTsspOhKynWo7ysraRWC


>  However, it would make it more difficult to unlock the
>  system, if they forget they've changed the keyboard layout and regenerated
>  their initramfs. (If they do it globally, if they just do it once the OS is
>  booted, then they're good to go.) 
Like I said, it's a user hostile experience.
>  > The traditional way is unquestionably hostile to international users,
>  > and doing better, however untraditional, is absolutely something I
>  > strongly favor.
>
>  How is it "hostile to international users"? "international users"
> generally
>  set their keyboard layout to the one they use primarily.. Just like everyone
>  else :) 
Ok so you're not aware of the issues, and you persistently refuse to
go read the issue I've cited multiple times that discuss these
problems, which you previously categorically rejected as even
existing. So it's a stupid or weird game and I refuse to participate.


-- 
Chris Murphy

[Kevin Kofler]

Chris Murphy wrote:
>  Fedora installations today don't support bootloader lock down,
That can be configured in grub.cfg after installation and it should not 
break anything.

>  encrypted /boot, 
You can actually get that by using Calamares (which is packaged in Fedora) 
to install Fedora instead of Anaconda. You can even do that on a stock 
Fedora live image: just open any terminal emulator and run:
sudo dnf install calamares
kdesu -t calamares
(The first command will also install kdesu as a dependency, because it is 
the best way to run Calamares as root without eating the environment 
variables needed for desktop integration. So I used kdesu for the second 
command. This is also what the Calamares menu entry uses, so it is possible 
to run Calamares from the menu instead if you don't care about the terminal 
output (that -t flag), which shows some minimal logging by default (use 
"kdesu -t calamares -d" for more verbose output).)

        Kevin Kofler

[Kevin Kofler]

John M. Harris Jr wrote:
>  Well, you could theoretically use ssh-agent (or equivalent), without
>  changing the protocol in any way. 
You need protocol support to do this securely. Otherwise, your ssh-agent is 
a decryption oracle which can be used by an attacker to decrypt your LUKS 
keyfile on demand. The decryption should only be possible as part of the 
login process after the server fingerprint has been verified and before 
arbitrary application data can be sent.

        Kevin Kofler

[Chris Murphy]

On Wed, Dec 4, 2019 at 5:44 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Wednesday, December 4, 2019 5:41:13 PM MST Chris Murphy wrote:
>  > On Wed, Dec 4, 2019 at 5:14 PM John M. Harris Jr <johnmh(a)splentity.com&gt;
>  > wrote:
>  > >
>  > >
>  > > On Wednesday, December 4, 2019 5:09:55 PM MST Chris Murphy wrote:
>  > >
>  > > > On Wed, Dec 4, 2019 at 4:41 PM Marius Schwarz
> <fedoradev(a)cloud-foo.de&gt;
>  > > > wrote:
>  > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > > Am 04.12.19 um 02:02 schrieb Chris Murphy:
>  > > > >
>  > > > >
>  > > > >
>  > > > > > Anaconda custom partitioning has a per mount point encryption
>  > > > > > option.
>  > > > > > I can LUKS encrypt only the volume mounted at /home. And if I
> do
>  > > > > > this,
>  > > > >
>  > > > >
>  > > > >
>  > > > > If you do this, someone can manipulate your system to trojan horse
>  > > > > your
>  > > > > passwords,
>  > > > > when he has physical access to it.
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > > Full-Diskencryption ( /boot included ) is the only way to protect
> the
>  > > > > system itself.
>  > > > > Anything else is simply not secure.
>  > > >
>  > > >
>  > > >
>  > > >
>  > > > systemd-homed doesn't depend on /etc/passwd or /etc/shadow for
>  > > > authentication. By all means its security guarantees should be
>  > > > evaluated.
>  > > > https://github.com/systemd/systemd/pull/14096
>  > > >
>  > > >
>  > > >
>  > > > What you're talking about is entirely up to the user to configure
>  > > > manually. Fedora installations today don't support bootloader lock
>  > > > down, encrypted /boot, or purging the LUKS key from memory during
>  > > > suspend, out of the box. And therefore I'm not sure what your goal
>  > > > posts are, what two things you're comparing.
>  > >
>  > >
>  > >
>  > > It may be the case that the GNOME Spin doesn't support that, but it is
>  > > supported with the KDE Spin. I don't think it's likely that anything
> in
>  > > the GNOME image would break that, but it's possible I suppose.
>  >
>  >
>  > I have no idea what you mean by "supported" nor which of the multiple
>  > characteristics I listed you think apply to Fedora KDE.
>  >
>  > What I mean by support = that which Fedora produces in release
>  > blocking desktops, most typically in a default configuration, and for
>  > which release criteria have been written. None of the things I wrote
>  > apply to Fedora KDE either, so it's simply not correct to call them
>  > supported. The functionality may exist in KDE, but that's not the same
>  > thing as what Fedora supports. And I did very clearly write "Fedora
>  > installations today don't support..."
>
>  Fedora supports installation on ARM devices with vboot today. 
The only Fedora KDE image that's release blocking is x86_64.
https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking



-- 
Chris Murphy

[John M. Harris Jr]

On Wednesday, December 4, 2019 5:56:39 PM MST Chris Murphy wrote:
>  On Wed, Dec 4, 2019 at 5:38 PM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  wrote:
>  >
>  >
>  > On Wednesday, December 4, 2019 5:28:17 PM MST Chris Murphy wrote:
>  > 
>  > > You know what is a work around and not a solution and is default? ~/
>  > > isn't encrypted. And the two install time options insist on restricted
>  > > character sets for the passphrase, the user must not change their
>  > > keyboard layout, or their keyboard to one with a different keymapping
>  > > - lest they experience data loss.
>  >
>  >
>  >
>  > $HOME is encrypted if you put it on an encrypted filesystem
>  
>  
>  You have a particular knack for pointing out the obvious as if you
>  think everyone is a moron. It's variably amusing and annoying.
>  
>  
>  >Additionally,
>  >
>  > that Anaconda restricts what the passphrase for the key sounds like a bug
>  > in Anaconda.
>  
>  
>  The idea is to protect the user from using characters that can't be
>  passed via plymouth to cryptsetup during startup. Known problem, I've
>  only cited it a couple times in this thread.
>  
>  
>  >The user can change their keyboard layout. That's fine. It wouldn't
>  >
>  > cause data loss.
>  
>  
>  The user experience is identical to data loss. The passphrase is
>  considered wrong, there's no feedback whatsoever to the user that the
>  keymapping has changed, that this is the actual problem.
>  
>  https://drive.google.com/open?id=1imiPyYBiTcE3zTsspOhKynWo7ysraRWC
>  
>  
>  
>  > However, it would make it more difficult to unlock the
>  > system, if they forget they've changed the keyboard layout and
>  > regenerated
>  > their initramfs. (If they do it globally, if they just do it once the OS
>  > is booted, then they're good to go.)
>  
>  
>  Like I said, it's a user hostile experience.
>  
>  >
>  >
>  > > The traditional way is unquestionably hostile to international users,
>  > > and doing better, however untraditional, is absolutely something I
>  > > strongly favor.
>  >
>  >
>  >
>  > How is it "hostile to international users"? "international
> users"
>  > generally set their keyboard layout to the one they use primarily.. Just
>  > like everyone else :)
>  
>  
>  Ok so you're not aware of the issues, and you persistently refuse to
>  go read the issue I've cited multiple times that discuss these
>  problems, which you previously categorically rejected as even
>  existing. So it's a stupid or weird game and I refuse to participate. 
I asked a question because you stated that there is a problem, and what you've 
described as a problem actually is not one.

Please allow me to explain. You can change the keyboard layout, but the 
original keyboard layout is used unless you rebuild the initramfs afterwards. 
Simply updating your kernel achieves the same, if you don't know how to do 
that.

The user experience is nothing like data loss. The users are not stupid. It's 
fine that the keyboard layout for initramfs is only updated when initramfs is 
rebuilt. People don't change their primary keyboard layout very often. I have 
to disagree, that this is a "hostile user experience". If you want to fix 
this, the fix is simple. Rebuild initramfs when the system-wide keyboard 
layout is changed.

Unless something has changed, plymouth does not actually handle input. This 
may have changed, but was the case as of F29. I don't use Plymouth, so I won't 
pretend to know what it does in current Fedora.

PS:
This is not a Fedora requirement, or anything of the sort, but please don't 
link to proprietary file sharing websites.. It's not really in line with 
Fedora's Four Foundations, but that's just my opinion.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Wednesday, December 4, 2019 6:08:31 PM MST Chris Murphy wrote:
>  On Wed, Dec 4, 2019 at 5:44 PM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  wrote:
>  >
>  >
>  > On Wednesday, December 4, 2019 5:41:13 PM MST Chris Murphy wrote:
>  > 
>  > > On Wed, Dec 4, 2019 at 5:14 PM John M. Harris Jr <johnmh(a)splentity.com&gt;
>  > > wrote:
>  > > 
>  > > >
>  > > >
>  > > >
>  > > > On Wednesday, December 4, 2019 5:09:55 PM MST Chris Murphy wrote:
>  > > >
>  > > >
>  > > >
>  > > > > On Wed, Dec 4, 2019 at 4:41 PM Marius Schwarz
>  > > > > <fedoradev(a)cloud-foo.de&gt;
>  > > > > wrote:
>  > > > >
>  > > > >
>  > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > > Am 04.12.19 um 02:02 schrieb Chris Murphy:
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > > > Anaconda custom partitioning has a per mount point
> encryption
>  > > > > > > option.
>  > > > > > > I can LUKS encrypt only the volume mounted at /home. And if
> I
>  > > > > > > do
>  > > > > > > this,
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > > If you do this, someone can manipulate your system to trojan
>  > > > > > horse
>  > > > > > your
>  > > > > > passwords,
>  > > > > > when he has physical access to it.
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > >
>  > > > > > Full-Diskencryption ( /boot included ) is the only way to
> protect
>  > > > > > the
>  > > > > > system itself.
>  > > > > > Anything else is simply not secure.
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > > systemd-homed doesn't depend on /etc/passwd or /etc/shadow for
>  > > > > authentication. By all means its security guarantees should be
>  > > > > evaluated.
>  > > > > https://github.com/systemd/systemd/pull/14096
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > > What you're talking about is entirely up to the user to
> configure
>  > > > > manually. Fedora installations today don't support bootloader
> lock
>  > > > > down, encrypted /boot, or purging the LUKS key from memory during
>  > > > > suspend, out of the box. And therefore I'm not sure what your
> goal
>  > > > > posts are, what two things you're comparing.
>  > > >
>  > > >
>  > > >
>  > > >
>  > > >
>  > > > It may be the case that the GNOME Spin doesn't support that, but it
>  > > > is
>  > > > supported with the KDE Spin. I don't think it's likely that
> anything
>  > > > in
>  > > > the GNOME image would break that, but it's possible I suppose.
>  > >
>  > >
>  > >
>  > >
>  > > I have no idea what you mean by "supported" nor which of the
> multiple
>  > > characteristics I listed you think apply to Fedora KDE.
>  > >
>  > >
>  > >
>  > > What I mean by support = that which Fedora produces in release
>  > > blocking desktops, most typically in a default configuration, and for
>  > > which release criteria have been written. None of the things I wrote
>  > > apply to Fedora KDE either, so it's simply not correct to call them
>  > > supported. The functionality may exist in KDE, but that's not the same
>  > > thing as what Fedora supports. And I did very clearly write "Fedora
>  > > installations today don't support..."
>  >
>  >
>  >
>  > Fedora supports installation on ARM devices with vboot today.
>  
>  
>  The only Fedora KDE image that's release blocking is x86_64.
>  https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking 
What does this have to do with "Fedora installations today don't
support..."?

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Wednesday, December 4, 2019 6:02:07 PM MST Kevin Kofler wrote:
>  John M. Harris Jr wrote:
>  
>  > Well, you could theoretically use ssh-agent (or equivalent), without
>  > changing the protocol in any way.
>  
>  
>  You need protocol support to do this securely. Otherwise, your ssh-agent is
>   a decryption oracle which can be used by an attacker to decrypt your LUKS
>  keyfile on demand. The decryption should only be possible as part of the
>  login process after the server fingerprint has been verified and before
>  arbitrary application data can be sent. 
Oh, of course after fingerprint verification. Luckily, that can be 
accomplished by forcing a fake shell which would run a check to see if the 
home directory is already mounted. If it's not, it'd use the ssh agent, or 
equivalent, then execute the real shell. If it's already mounted, short 
circuit to the last step, executing the real shell.

-- 
John M. Harris, Jr.
Splentity

[Kevin Kofler]

John M. Harris Jr wrote:
>  Oh, of course after fingerprint verification. Luckily, that can be
>  accomplished by forcing a fake shell which would run a check to see if the
>  home directory is already mounted. If it's not, it'd use the ssh agent, or
>  equivalent, then execute the real shell. If it's already mounted, short
>  circuit to the last step, executing the real shell. 
How would that work? The shell runs on the server. The SSH agent runs on the 
client, the only one that has the private key. How can the SSH agent know 
that it is talking to your "fake shell" and not to an attacker's fake
"fake 
shell"? This needs to be part of the protocol, not hacked onto it.

        Kevin Kofler

[Nicolas Mailhot]

Le mercredi 04 décembre 2019 à 16:59 -0700, John M. Harris Jr a écrit :
>  On Wednesday, December 4, 2019 12:38:20 PM MST Przemek Klosowski via
>  devel 
>  wrote:
>  > - stolen/lost laptop:  I think this is the most important one for
>  > most  
>  > people; it is mitigaged by a trusted-network-based decryption,
>  > unless 
>  > the device is in unencrypted sleep mode and the new 'beneficial
>  > owner' 
>  > manages to read the disk before the system goes down.
>  
>  That may be the case for home users, but not for businesses. Let's
>  take this 
>  example. Employee A has files from a given project, but Employee B
>  doesn't 
>  have access to that project. Employee B is malicious, and takes
>  Employee A's 
>  laptop, gets it on the network, it unencrypts itself and then takes
>  it. The 
>  data is not Employee B's. 
Let’s get real, in most businesses, the data will already be available
in a network share, a common database, etc. Trying to perform fine-
grained control checks on the mass of data businesses routinely
manipulate is a loosing game. You always end up needing to trust
humans.

That’s even the case in ultra-secure environments like the NSA. How do
you think wikileaks happened?

-- 
Nicolas Mailhot

[Nicolas Mailhot]

Le mercredi 04 décembre 2019 à 17:37 -0700, John M. Harris Jr a écrit :
>  
>  > The traditional way is unquestionably hostile to international
>  > users,
>  > and doing better, however untraditional, is absolutely something I
>  > strongly favor.
>  
>  How is it "hostile to international users"? "international users"
>  generally 
>  set their keyboard layout to the one they use primarily.. Just like
>  everyone  else :) 
That works in the GUI. All the low-level parts (including in anaconda
terminal, right after it asked the user to choose a layout) are not
configured properly by the distribution and will fallback to qwerty.

Really, we should try to change the default to Azerty or the Russian
layout for a release. That would teach qwerty users what is hostile to
users of other layouts or not.

-- 
Nicolas Mailhot

[Marius Schwarz]

Am 05.12.19 um 01:13 schrieb John M. Harris Jr:
> > Full-Diskencryption ( /boot included ) is the only way to protect
> the
> > system itself.
> > Anything else is simply not secure.
>  systemd-homed doesn't depend on /etc/passwd or /etc/shadow for
>  authentication. By all means its security guarantees should be
>  evaluated.
>  https://github.com/systemd/systemd/pull/14096 
It does not need to, if your system is open to any physical abuser, he
simply can exchange the tool to unlock the drive,
get the password, send it to the attacker and unlock the drive. Nothing
has changed for the user, but it got compromised.

And encrypting only parts of your system makes it extrem easy to tamper it.

and btw.. nothing stops an attacker from waiting for you to unlock the
drive for him, and exfiltrate your data when it's active.

System security needs four major anchors to rely on:

a full disc encryption
a good, not backdoored encryption system
secure programs 
and secure passcodes

if you only partly encrypt your disk, your data is only be protected
against a random theft and you have to enter your password
anyway to unlock it, so you also can encrypt the entire system. There
will be no extra work for you to do ;)

If you have to worry about someone instantly cooling your RAM down to
protect in-memory crypto keys after seizing your laptop, it's time to
rethink your lifestyle ;)


Best regards,
Marius

[Lennart Poettering]

On Do, 05.12.19 00:21, Marius Schwarz (fedoradev(a)cloud-foo.de) wrote:

>  Am 03.12.19 um 09:07 schrieb Lennart Poettering:
>  > Also note that on Fedora Workstation we default to suspend-on-idle
>  > these days. i.e. when you don't actually work on the laptop the laptop
>  > is suspended and not reachable via SSH at all, hence adding
>  > systemd-homed doesn't make anything worse in that regard...
>
>  How do you wanne access data on your homeserver, when you are at
>  work? 
Fedora Workstation is — as the name suggests — a workstation OS. It
enforces policies by deault (such as suspend-on-idle) that are not
appropriate for a server.

Which has nothing to do with systemd-homed btw, it's the existing
Fedora Workstation behaving that way.

>  The system will idle, will go into suspend and you can't access
> it
>  anymore? 
Yeah, isn't it great that when you leave your laptop on your desk
unattended you know for sure it's securely locked after a while and
can only be unlocked from you again with your pw?

>  I really hope, it's easily configureable, otherwise it will end
> up here
>  "dnf erase". 
I love you too, my friend.

Lennart

--
Lennart Poettering, Berlin

[Lennart Poettering]

On Do, 05.12.19 00:40, Marius Schwarz (fedoradev(a)cloud-foo.de) wrote:

>  Am 04.12.19 um 02:02 schrieb Chris Murphy:
>  > Anaconda custom partitioning has a per mount point encryption option.
>  > I can LUKS encrypt only the volume mounted at /home. And if I do this,
>  If you do this, someone can manipulate your system to trojan horse your
>  passwords,
>  when he has physical access to it.
>
>  Full-Diskencryption ( /boot included ) is the only way to protect the
>  system itself.
>  Anything else is simply not secure. 
Uh, first of all plain full disk encryption like we set it up
typically on Fedora provides confidentiality, not integrity. For the
OS image itself you want integrity though, confidentiality is not
needed (after all anyone can download Fedora from the Internet,
everyone knows all the bits and bytes in it anyway, it's inherently
public information, there's zero point in encrypting it).

Unless you combine dm-crypt with dm-integrity (which we currently
generally do not do), or you use dm-verity you are not actually
protecting the OS from undetected modification.

And there's no point in encrypting /boot, because that contains only
public information too. If you want to protect your boot chain, use
something like a complete SecureBoot chain, but that too is something
we currently don't actually support on Fedora. (because initrds are
not verified).

Anyway, figure out your threat model, and figure out how you want to
protect what, and understand that for different parts of the
installation different rules apply. And yes, I think encrypting the
home directory with the user's own password makes most sense.

Lennart

--
Lennart Poettering, Berlin

[Marius Schwarz]

Hi,

Am 05.12.19 um 10:33 schrieb Lennart Poettering:
> >> Also note that on Fedora Workstation we default to
> suspend-on-idle
> >> these days. i.e. when you don't actually work on the laptop the laptop
> >> is suspended and not reachable via SSH at all, hence adding
> >> systemd-homed doesn't make anything worse in that regard...
> > How do you wanne access data on your homeserver, when you are at
> > work?
>  Fedora Workstation is — as the name suggests — a workstation OS. It
>  enforces policies by deault (such as suspend-on-idle) that are not
>  appropriate for a server. 
My "workstation" -> is <- my homeserver,
or do you have a 19" data rack 
in your home, just to be able to suspend your "workingstation", when you
go to your actual work? No, you don't :) And i don't speculate if you
either have a Laptop with all your data on it or a big pc to work with,
which is fast & has big storages and good GFX capabilities, because it
will be something i did not imagine. So don't assume, you know how
people use their stuff, make something universal. IMHO systemd and it's
components are there to start a system, not to control it afterwards.
That is out of systemds business.

>  Which has nothing to do with systemd-homed btw, it's the
> existing
>  Fedora Workstation behaving that way. 
Quite right, so why do you wanne take control of it?


>  Yeah, isn't it great that when you leave your laptop on your
> desk
>  unattended you know for sure it's securely locked after a while and
>  can only be unlocked from you again with your pw? 
As long as my running system software does not have any major flaws, I
already sleep well, if it gets stolen.

There are very cool components, most of the users have no knowledge
about, that auto lock your system, when you leave the physical area
around your laptop. It's already implemented in Fedora today. i.e. via
detecting the absence of BT beacons (of any sort) in the near vicinity
of the laptop. 

With FDE running and "Suspend-to-disk" selected in your screensafer
settings, you get asked for your password on hw wakeup before your
system gets back running. If someone wants to use such things, he
already can.

Where is the advantage of homed, considering, that only encrypting
/home, is a major security flaw by itself. All your goals are already
there and it's more useful and secure too :) I really have a problem
understanding why you wanne implement a security flaw and call it "better".

If you wanne improve security, please focus on userfriendlyneess for
things like "disabling unused usb ports"/"whitelist for usb
ids"/"insecure Highspeed USB network adapter detection"  same for any
plugable port you have in your hw. And last, but not least, "motherboard
serial number validation on wakeup" to counter the switch of hw components.

>  I love you too, my friend. 
Cu :D

Best regards,
Marius

[John M. Harris Jr]

On Thursday, December 5, 2019 2:56:22 AM MST Lennart Poettering wrote:
>  Uh, first of all plain full disk encryption like we set it up
>  typically on Fedora provides confidentiality, not integrity. For the
>  OS image itself you want integrity though, confidentiality is not
>  needed (after all anyone can download Fedora from the Internet,
>  everyone knows all the bits and bytes in it anyway, it's inherently
>  public information, there's zero point in encrypting it). 
I have to disagree. The system itself is not just the list of packages 
installed, but can certainly include software that an individual or company 
wrote themselves or purchased , and do not wish to lose to a breach. This also 
includes global configuration files, which may include, for example, a VPN 
configuration, network configuration and so on.

>  Unless you combine dm-crypt with dm-integrity (which we currently
>  generally do not do), or you use dm-verity you are not actually
>  protecting the OS from undetected modification. 
Well, you are, in that the average attacker have to break or steal a key to 
decrypt the drive first. Sure, it wouldn't stop a sophisticated attack.

>  And there's no point in encrypting /boot, because that contains
> only
>  public information too. If you want to protect your boot chain, use
>  something like a complete SecureBoot chain, but that too is something
>  we currently don't actually support on Fedora. (because initrds are
>  not verified). 
This is not generally true either. Encrypting /boot helps to ensure that /boot 
is not modified, and is generally paired with GRUB signature validation. In 
some setups, this GRUB configuration is moved to flash storage.

>  Anyway, figure out your threat model, and figure out how you want to
>  protect what, and understand that for different parts of the
>  installation different rules apply. 
I don't believe this as the case, as specified above.

>  And yes, I think encrypting the home directory with the user's
> own password
>  makes most sense. 
I suppose that's a good *start*, where users wouldn't use encryption 
otherwise.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Wednesday, December 4, 2019 8:44:18 PM MST Kevin Kofler wrote:
>  How would that work? The shell runs on the server. The SSH agent runs
> on the
>   client, the only one that has the private key. How can the SSH agent know
>  that it is talking to your "fake shell" and not to an attacker's fake
> "fake
>  shell"? This needs to be part of the protocol, not hacked onto it.  
The very same way that it already knows when it's talking to `ssh` on a remote 
server. You've already verified the fingerprint, either manually or using DNS.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Thursday, December 5, 2019 1:03:50 AM MST Nicolas Mailhot via devel wrote:
>  That works in the GUI. All the low-level parts (including in
> anaconda
>  terminal, right after it asked the user to choose a layout) are not
>  configured properly by the distribution and will fallback to qwerty. 
That's the case, until you actually install the system with it set globally. 
That is most likely because the livesystems are built for, I suppose, US 
QWERTY, and Anaconda devs didn't take switching to vttys into consideration 
there.

>  Really, we should try to change the default to Azerty or the Russian
>  layout for a release. That would teach qwerty users what is hostile to
>  users of other layouts or not. 
There is no "default", there is only what the live images are built with. 

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Thursday, December 5, 2019 12:57:15 AM MST Nicolas Mailhot via devel wrote:

>  Let’s get real, in most businesses, the data will already be
> available
>  in a network share, a common database, etc. Trying to perform fine-
>  grained control checks on the mass of data businesses routinely
>  manipulate is a loosing game. You always end up needing to trust
>  humans. 
Let's get real. In most business, the data will also be available in a network 
share. Trying to perform proper separation of permissions is the appropriate 
method of preventing unauthorized users from gaining that data. You don't need 
to "trust humans", other than those who do have access to the data.

>  That’s even the case in ultra-secure environments like the NSA. How
> do
>  you think wikileaks happened? 
No.

-- 
John M. Harris, Jr.
Splentity

[Marius Schwarz]

Am 05.12.19 um 09:03 schrieb Nicolas Mailhot via devel:
>  Really, we should try to change the default to Azerty or the Russian
>  layout for a release. That would teach qwerty users what is hostile to
>  users of other layouts or not. 
It was in the past, and i.e. a live disk is still
defaulting to the US
keyboard layout,
so all !US/UK citizens know the problem ;)

best regards,
Marius

[Marius Schwarz]

Hi,

Am 25.11.19 um 22:59 schrieb Samuel Sieb:
>  Steps 1 - 4 are not benefits, they are workarounds to critical system
>  utilities required by this change.  I don't understand why this change
>  is necessary at all.  It only affects local logins and if someone
>  wants to have an empty password, why make it so difficult?  It's their
>  choice.  It's not like Fedora has any default logins with empty
>  passwords, the user has to make their own. 
I know at least two real exiting none nerd users, who will agree with
you, as they use FullDiskEnc and no further passwords to Login after boot.

Which would be impossible if the changes will be made. I personally have
only on scenario to offer:

A tablet pc is booted directly into the desktop, as any other tablet
(android or ipad) will do.

@Ben.Cotton

Will that be still possible, when empty passwords are dismissed?

best regards,
Marius

[Lennart Poettering]

On Do, 05.12.19 12:02, Marius Schwarz (fedoradev(a)cloud-foo.de) wrote:

>  With FDE running and "Suspend-to-disk" selected in your
> screensafer
>  settings, you get asked for your password on hw wakeup before your
>  system gets back running. If someone wants to use such things, he
>  already can. 
Well, the way this has been traditionally done is that the lock screen
is displayed by a program running under the user's identity and that
the user's data is entirely unlocked the entire time during suspend,
i.e. the decryption key is lying around in memory just fine. If you
steal a laptop that way and read out the memory (which sufficiently
sophisticated hackers can, via thunderbolt DMA for example, or finding
an exploit in the screen locker, like we prominently had in the past
in xscreensaver) then you have full acces to your full data. The
intention here is to lock things down so that while the system is
suspended you can rest safely that it is as locked down as it would be
if the device was turned off. i.e. so that if you manage to exploit
xscreensaver or if you manage to exploit thunderbolt, or manage to
exploit the kernel it doesn't help you anything, because the crypto
keys are not present on the device anymore.

>  Where is the advantage of homed, considering, that only encrypting
>  /home, is a major security flaw by itself. All your goals are
>  already there and it's more useful and secure too :) I really have a
>  problem understanding why you wanne implement a security flaw and
>  call it "better". 
Locking down the OS itself and locking down the user's home are two
different things, because OS integrity should be bound to different
mechanisms than user data encryption. (i.e. OS integrity should be
bound to vendor trust or TPM, while user data should be bound to
user's security credentials).

>  If you wanne improve security, please focus on userfriendlyneess for
>  things like "disabling unused usb ports"/"whitelist for usb
>  ids"/"insecure Highspeed USB network adapter detection"  same for any
>  plugable port you have in your hw. And last, but not least, "motherboard
>  serial number validation on wakeup" to counter the switch of hw components. 
Uh, locking down USB like that doesn't really work. USB has no
mechanism for recognizing devices securely, which means any whitelist
is pointless because any device can claim to be whatever it wants to
be. (And yes, it would be great if we could be a bit more secure
there, but it's an orthogonal problem)

Lennart

--
Lennart Poettering, Berlin

[Lennart Poettering]

On Do, 05.12.19 04:30, John M. Harris Jr (johnmh(a)splentity.com) wrote:

>  > Unless you combine dm-crypt with dm-integrity (which we
> currently
>  > generally do not do), or you use dm-verity you are not actually
>  > protecting the OS from undetected modification.
>
>  Well, you are, in that the average attacker have to break or steal a key to
>  decrypt the drive first. Sure, it wouldn't stop a sophisticated
>  attack. 
Not how this works.

>  > And there's no point in encrypting /boot, because that
> contains only
>  > public information too. If you want to protect your boot chain, use
>  > something like a complete SecureBoot chain, but that too is something
>  > we currently don't actually support on Fedora. (because initrds are
>  > not verified).
>
>  This is not generally true either. Encrypting /boot helps to ensure that /boot
>  is not modified, and is generally paired with GRUB signature validation. In
>  some setups, this GRUB configuration is moved to flash storage. 
You are conflating integrity and confidentiality. If you want to
protect boot loaders against modification you want the former, not
necessarily the latter.

Lennart

--
Lennart Poettering, Berlin

[Nico Kadel-Garcia]

On Wed, Dec 4, 2019 at 6:01 AM Lennart Poettering <mzerqung(a)0pointer.de&gt; wrote:

>  (One thinkable extension of homed's current model btw is to
> support
>  logind lingering by asking for the user pw using plymouth. this would
>  then mean you'd be asked to unlock your user during early boot like as
>  with classic disk encryption, and then it remains unlocked for the
>  entire lifetime of the system. But I am not sure it's worth it, if you
>  are happy with such a much weaker model you might as well use regular
>  full disk encryption and have the home dirs themselves just be plain
>  directories)
>
>  Lennart 
If someone wants to spend that much of their resources on homedir
security, they need to decide whether they want SSH key based access.
That is manageable by configuring SSH to store SSH public keys in an
alternate location and inform the users of the modified sshd_config
and its modified, accessible "AuthorizedKeysFile" setting. Or the user
can spend the time and effort to activate Kerberos based logins, or
use password based logins. I'd avoid trying to rewrite SSH for such an
OS-specific and non-portable need as homedir decryption mounting.

In common usage, very few people encrypt their home directories
separately from their basic disk image. It makes system management for
administrators or even a local root user very awkward. I could see it
for home directories in "/home", and it would only cost SSH key based
access, not ordinary password or Kerberos ticket based login. But it
sounds quite risky and destabilizing, much as the "kill dangling
processes when people log out". That  caused a lot of shock when it
was activated by default and started killing processes with no
logging. Let's not repeat a surprise like that and avoid killing SSH
key access by default.

[Nico Kadel-Garcia]

On Wed, Dec 4, 2019 at 9:24 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Wednesday, December 4, 2019 6:02:07 PM MST Kevin Kofler wrote:
>  > John M. Harris Jr wrote:
>  >
>  > > Well, you could theoretically use ssh-agent (or equivalent), without
>  > > changing the protocol in any way.
>  >
>  >
>  > You need protocol support to do this securely. Otherwise, your ssh-agent is
>  >  a decryption oracle which can be used by an attacker to decrypt your LUKS
>  > keyfile on demand. The decryption should only be possible as part of the
>  > login process after the server fingerprint has been verified and before
>  > arbitrary application data can be sent.
>
>  Oh, of course after fingerprint verification. Luckily, that can be
>  accomplished by forcing a fake shell which would run a check to see if the
>  home directory is already mounted. If it's not, it'd use the ssh agent, or
>  equivalent, then execute the real shell. If it's already mounted, short
>  circuit to the last step, executing the real shell. 
Let's not go too far down the "gummy fingerprint" thread. If a
sophisticated person has your laptop, they probably have your
fingerprints, and very few fingerprint scanners successfully resist a
duplicated and printed fingerprint.

[John M. Harris Jr]

On Thursday, December 5, 2019 5:41:44 AM MST Nico Kadel-Garcia wrote:
>  If someone wants to spend that much of their resources on homedir
>  security, they need to decide whether they want SSH key based access.
>  That is manageable by configuring SSH to store SSH public keys in an
>  alternate location and inform the users of the modified sshd_config
>  and its modified, accessible "AuthorizedKeysFile" setting. Or the user
>  can spend the time and effort to activate Kerberos based logins, or
>  use password based logins. I'd avoid trying to rewrite SSH for such an
>  OS-specific and non-portable need as homedir decryption mounting. 
Please don't recommend to anyone to use passwords for SSH. That is incredibly 
insecure, and if privileged users are using password-based SSH, that'll 
quickly lead to a serious compromise of your entire system, depending on the 
complexity of the password, of course, but still holds nothing to key-based 
authentication with the best password.

>  In common usage, very few people encrypt their home directories
>  separately from their basic disk image. It makes system management for
>  administrators or even a local root user very awkward. I could see it
>  for home directories in "/home", and it would only cost SSH key based
>  access, not ordinary password or Kerberos ticket based login. But it
>  sounds quite risky and destabilizing, much as the "kill dangling
>  processes when people log out". That  caused a lot of shock when it
>  was activated by default and started killing processes with no
>  logging. Let's not repeat a surprise like that and avoid killing SSH
>  key access by default. 
A bit off topic, but where is "kill danging processes when people log out" 
set? I've not experienced that anywhere.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Thursday, December 5, 2019 5:35:09 AM MST Lennart Poettering wrote:
>  On Do, 05.12.19 04:30, John M. Harris Jr (johnmh(a)splentity.com)
> wrote:
>  > Well, you are, in that the average attacker have to break or steal a key
>  > to decrypt the drive first. Sure, it wouldn't stop a sophisticated
>  > attack.
>  
>  
>  Not how this works. 
It is. If you cannot decrypt it, you cannot modify it, nor even read it.

>  > This is not generally true either. Encrypting /boot helps to
> ensure that
>  > /boot is not modified, and is generally paired with GRUB signature
>  > validation. In some setups, this GRUB configuration is moved to flash
>  > storage.
>  
>  
>  You are conflating integrity and confidentiality. If you want to
>  protect boot loaders against modification you want the former, not
>  necessarily the latter. 
I am not conflating the two, though confidentiality inherently provides a 
certain degree of integrity. If you want to protect boot loaders against 
modification, you want *both*.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Thursday, December 5, 2019 5:53:18 AM MST Nico Kadel-Garcia wrote:
>  On Wed, Dec 4, 2019 at 9:24 PM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  wrote:
>  >
>  >
>  > On Wednesday, December 4, 2019 6:02:07 PM MST Kevin Kofler wrote:
>  > 
>  > > John M. Harris Jr wrote:
>  > >
>  > >
>  > >
>  > > > Well, you could theoretically use ssh-agent (or equivalent), without
>  > > > changing the protocol in any way.
>  > >
>  > >
>  > >
>  > >
>  > > You need protocol support to do this securely. Otherwise, your ssh-agent
>  > > is
>  > 
>  > >  a decryption oracle which can be used by an attacker to decrypt your
>  > >  LUKS
>  > > 
>  > > keyfile on demand. The decryption should only be possible as part of
>  > > the
>  > > login process after the server fingerprint has been verified and before
>  > > arbitrary application data can be sent.
>  >
>  >
>  >
>  > Oh, of course after fingerprint verification. Luckily, that can be
>  > accomplished by forcing a fake shell which would run a check to see if
>  > the
>  > home directory is already mounted. If it's not, it'd use the ssh agent,
>  > or
>  > equivalent, then execute the real shell. If it's already mounted, short
>  > circuit to the last step, executing the real shell.
>  
>  
>  Let's not go too far down the "gummy fingerprint" thread. If a
>  sophisticated person has your laptop, they probably have your
>  fingerprints, and very few fingerprint scanners successfully resist a
>  duplicated and printed fingerprint. 
We were talking about ssh key fingerprints. I would never suggest fingerprint 
scanners as a form of security.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Thursday, December 5, 2019 5:07:04 AM MST Marius Schwarz wrote:
>  Hi,
>  
>  Am 25.11.19 um 22:59 schrieb Samuel Sieb:
>  
>  >
>  >
>  > Steps 1 - 4 are not benefits, they are workarounds to critical system
>  > utilities required by this change.  I don't understand why this change
>  > is necessary at all.  It only affects local logins and if someone
>  > wants to have an empty password, why make it so difficult?  It's their
>  > choice.  It's not like Fedora has any default logins with empty
>  > passwords, the user has to make their own.
>  
>  
>  I know at least two real exiting none nerd users, who will agree with
>  you, as they use FullDiskEnc and no further passwords to Login after boot.
>  
>  Which would be impossible if the changes will be made. I personally have
>  only on scenario to offer:
>  
>  A tablet pc is booted directly into the desktop, as any other tablet
>  (android or ipad) will do.
>  
>  @Ben.Cotton
>  
>  Will that be still possible, when empty passwords are dismissed? 
Only if this configuration is modified by the end-user while setting up that 
kiosk-like systems.

-- 
John M. Harris, Jr.
Splentity

[Neal Gompa]

On Thu, Dec 5, 2019 at 9:02 AM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Thursday, December 5, 2019 5:41:44 AM MST Nico Kadel-Garcia wrote:
>  > If someone wants to spend that much of their resources on homedir
>  > security, they need to decide whether they want SSH key based access.
>  > That is manageable by configuring SSH to store SSH public keys in an
>  > alternate location and inform the users of the modified sshd_config
>  > and its modified, accessible "AuthorizedKeysFile" setting. Or the user
>  > can spend the time and effort to activate Kerberos based logins, or
>  > use password based logins. I'd avoid trying to rewrite SSH for such an
>  > OS-specific and non-portable need as homedir decryption mounting.
>
>  Please don't recommend to anyone to use passwords for SSH. That is incredibly
>  insecure, and if privileged users are using password-based SSH, that'll
>  quickly lead to a serious compromise of your entire system, depending on the
>  complexity of the password, of course, but still holds nothing to key-based
>  authentication with the best password.
>  
Please don't suggest that password-based auth for SSH is insecure.
That's not even close to true. A password isn't terribly different
from an SSH key from an authentication perspective. If the password is
strong or hard to crack, then it's fine.

Frankly, it's irresponsible to give blanket statements like that,
because they're untrue and do not recognize the nuance of threat
models and risk assessments.

For the vast majority of people using SSH in a non-shared context
(i.e. not a VPS or some kind of easily accessible server), password
auth is more than sufficient with a strong enough password or
passphrase.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[John M. Harris Jr]

On Thursday, December 5, 2019 7:07:04 AM MST Neal Gompa wrote:
>  Please don't suggest that password-based auth for SSH is
> insecure.
>  That's not even close to true. A password isn't terribly different
>  from an SSH key from an authentication perspective. If the password is
>  strong or hard to crack, then it's fine. 
It's not insecure as a mechanism, but, without something like fail2ban, it 
takes a surprisingly short amount of time to break into systems using password 
authentication. In practice, it is insecure, especially when compared to the 
other options.

>  Frankly, it's irresponsible to give blanket statements like
> that,
>  because they're untrue and do not recognize the nuance of threat
>  models and risk assessments. 
It is irresponsible to suggest password based authentication, especially at a 
time where residential ranges especially are being mass scanned, and bots 
attempt to break into these systems once ssh servers with password 
authentication have been found.

>  For the vast majority of people using SSH in a non-shared context
>  (i.e. not a VPS or some kind of easily accessible server), password
>  auth is more than sufficient with a strong enough password or
>  passphrase. 
This would depend heavily on what environment they're using it on. If it never 
connects to the internet, you would be correct. If it connects to shared wifi, 
or home wifi with the average home router, then I would argue that it is not 
sufficient to use password authentication. Especially on shared wifi, for 
example guest wifi at most businesses.

-- 
John M. Harris, Jr.
Splentity

[Kevin Kofler]

Lennart Poettering wrote:
>  Uh, first of all plain full disk encryption like we set it up
>  typically on Fedora provides confidentiality, not integrity. 
Well, it does protect against offline modification (i.e., "borrow" the 
computer or the storage devices, put the storage devices into another 
computer, trojan the OS, and return the "borrowed" device without getting 
caught; or even just boot the computer from a malicious boot device and 
trojan the OS from there, if the boot order is not locked). It does not 
protect against online modification (i.e., attack the system while it is 
running and the disk is decrypted).

        Kevin Kofler

[Kevin Kofler]

Nico Kadel-Garcia wrote:
>  Let's not go too far down the "gummy fingerprint"
> thread. If a
>  sophisticated person has your laptop, they probably have your
>  fingerprints, and very few fingerprint scanners successfully resist a
>  duplicated and printed fingerprint. 
We were talking about SSH key fingerprints here, not actual (biometric) 
finger prints.

        Kevin Kofler

[Lennart Poettering]

On Do, 05.12.19 15:23, Kevin Kofler (kevin.kofler(a)chello.at) wrote:

>  Lennart Poettering wrote:
>  > Uh, first of all plain full disk encryption like we set it up
>  > typically on Fedora provides confidentiality, not integrity.
>
>  Well, it does protect against offline modification (i.e., "borrow" the
>  computer or the storage devices, put the storage devices into another
>  computer, trojan the OS, and return the "borrowed" device without getting
>  caught; or even just boot the computer from a malicious boot device and
>  trojan the OS from there, if the boot order is not locked). It does not
>  protect against online modification (i.e., attack the system while it is
>  running and the disk is decrypted). 
No it does not protect against offline modification. That's why
dm-integrity exists after all.

If you use LUKS/dm-crypt without dm-integrity and you have a clue
where things are located then you can change files without anything
being able to detect that. (On btrfs you might have some luck, since
it has data checksumming, but ext4 and other traditional file systems
do not).

And it's easier to figure out where stuff is located then you might
think since we live in a world where people use SSDs and mount file
systems with "discard", so that what are used blocks and what are free
blocks is propagated to the underlying device. Moreover file systems
write in certain patterns, i.e. try to keep large files in one stream
together, put files in the same directories adjacent to each other and
so on, and are usually roughly reproducible.

Lennart

--
Lennart Poettering, Berlin

[Marius Schwarz]

Am 05.12.19 um 13:32 schrieb Lennart Poettering:
>  Well, the way this has been traditionally done is that the lock
> screen
>  is displayed by a program running under the user's identity and that
>  the user's data is entirely unlocked the entire time during suspend, 
That
depends on what you have chosen "sleep" or "hibernate" .

If the device just sleeps, your data is unprotected, as the key could be
in your still powered memory bank.

With hibernation, as far as I have seen it with my devices, the hw stops
entirely after saving the memory state to disk,
an encrypted disk I may add. On boot, it asks for the decryption keys as
it would normally do, finds the hibernate signature
on swap ( i presume / which is also encrypted ) and restores memory. I
don't see a way for an attack here.

I think your approach is not to the full extent of all possible user
data locations. Some examples:

/var/lib/mysql  MariaDB SQL Database ( required i.e. by MythTV )
/var/www/       Apache Webserver ( required i.e. by RoundCube, BackupPC
or Gnome User-Share )

if those aren't common enough, this will be:

/media/                Additional Storage Drives

It's quite common to have additional storage space on a desktop pc,
which do not exactly extend /home/ space, more general space. If you
have more than one "user" on a system, you can't mount it into
/home/username/path as of the rights management.

When I had to estimate my system, it's a hundred GB in /home/ against a
few TB != /home . Anyone who as ever bought a second drive for
his/her/it pc , will face this problem, or has to learn to use LVM.  I
don't think it will work for the majority of userbase. It will only work
for simple cases.

best regards,
Marius

[Przemek Klosowski]

On 12/4/19 6:59 PM, John M. Harris Jr wrote:
>  On Wednesday, December 4, 2019 12:38:20 PM MST Przemek Klosowski via
> devel
>  wrote:
> > - stolen/lost laptop:  I think this is the most important one for most
> > people; it is mitigaged by a trusted-network-based decryption, unless
> > the device is in unencrypted sleep mode and the new 'beneficial owner'
> > manages to read the disk before the system goes down.
>  That may be the case for home users, but not for businesses. Let's take this
>  example. Employee A has files from a given project, but Employee B doesn't
>  have access to that project. Employee B is malicious, and takes Employee A's
>  laptop, gets it on the network, it unencrypts itself and then takes it. 
Defending
against threat model allowing physical access and malicious 
insiders, who e.g. install a screen/keyboard capturing camera in the 
target office, is an entirely different ballgame, requiring multi-factor 
authentication, etc. --- and even those are not infallible (c.f. wikileaks).
> > - someone breaks into your home/office/hotel room and extracts the data:
> > important to some people but not very common scenario.
>  This is important to most businesses. 
Same argument as above. Again, we're
talking about taking care of the 
low hanging fruit like hard disks stripped from equipment and sold on Ebay.

[Kevin Fenzi]

On Thu, Dec 05, 2019 at 07:02:08AM -0700, John M. Harris Jr wrote:
>  On Thursday, December 5, 2019 5:41:44 AM MST Nico Kadel-Garcia wrote:
...snip...
>  > In common usage, very few people encrypt their home directories
>  > separately from their basic disk image. It makes system management for
>  > administrators or even a local root user very awkward. I could see it
>  > for home directories in "/home", and it would only cost SSH key based
>  > access, not ordinary password or Kerberos ticket based login. But it
>  > sounds quite risky and destabilizing, much as the "kill dangling
>  > processes when people log out". That  caused a lot of shock when it
>  > was activated by default and started killing processes with no
>  > logging. Let's not repeat a surprise like that and avoid killing SSH
>  > key access by default.
>  
>  A bit off topic, but where is "kill danging processes when people log out" 
>  set? I've not experienced that anywhere. 
It's set in /etc/systemd/logind.conf, but it defaults to off in fedora. 

It was enabled for a short time in rawhide, then disabled.

kevin

[Chris Murphy]

On Thu, Dec 5, 2019 at 8:04 AM Lennart Poettering <mzerqung(a)0pointer.de&gt; wrote:
>  If you use LUKS/dm-crypt without dm-integrity and you have a clue
>  where things are located then you can change files without anything
>  being able to detect that. (On btrfs you might have some luck, since
>  it has data checksumming, but ext4 and other traditional file systems
>  do not). 
xxhash, sha256, and blake2 coming to Btrfs in kernel 5.5, with online
conversion between them.


>  And it's easier to figure out where stuff is located then you
> might
>  think since we live in a world where people use SSDs and mount file
>  systems with "discard", so that what are used blocks and what are free
>  blocks is propagated to the underlying device. Moreover file systems
>  write in certain patterns, i.e. try to keep large files in one stream
>  together, put files in the same directories adjacent to each other and
>  so on, and are usually roughly reproducible. 
Fedora install time default for LUKS encrypted volumes is to unlocked
with cryptsetup open --allow-discards, which is set in /etc/crypttab
by using the discard option. This is since Fedora 27.
https://fedoraproject.org/wiki/Changes/EnableTrimOnDmCrypt

However, the installer doesn't enable the discard mount option for any
file system in /etc/fstab, and fstrim.timer is disabled by default.
Therefore the feature is a no op for most users, who are unlikely to
enable file system discards using either method.

-- 
Chris Murphy

[Andreas Tunek]

On Thu, 5 Dec 2019, 02:11 John M. Harris Jr, <johnmh(a)splentity.com&gt; wrote:

>  The user experience is nothing like data loss. The users are not stupid.
>  It's
>  fine that the keyboard layout for initramfs is only updated when initramfs
>  is
>  rebuilt. People don't change their primary keyboard layout very often. I
>  have
>  to disagree, that this is a "hostile user experience". If you want to fix
>  this, the fix is simple. Rebuild initramfs when the system-wide keyboard
>  layout is changed.
>
>  John M. Harris, Jr.
>  Splentity
>
>  
I change my keyboard layout several times every hour.



>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Chris Murphy]

On Thu, Dec 5, 2019 at 8:57 AM Marius Schwarz <fedoradev(a)cloud-foo.de&gt; wrote:
>  Am 05.12.19 um 13:32 schrieb Lennart Poettering:
>
>  Well, the way this has been traditionally done is that the lock screen
>  is displayed by a program running under the user's identity and that
>  the user's data is entirely unlocked the entire time during suspend,
>
>  That depends on what you have chosen "sleep" or "hibernate" .
>
>  If the device just sleeps, your data is unprotected, as the key could be in your still
> powered memory bank.
>
>  With hibernation, as far as I have seen it with my devices, the hw stops entirely after
> saving the memory state to disk,
>  an encrypted disk I may add. On boot, it asks for the decryption keys as it would
> normally do, finds the hibernate signature
>  on swap ( i presume / which is also encrypted ) and restores memory. I don't see a
> way for an attack here. 
Hibernation is out of scope to rely on, let alone make a default, for
at least the following reasons:
a. It's not sufficiently well supported upstream for regressions that
may appear in new kernels, and not supported by the Fedora kernel
team.
b. It's disabled by kernel lockdown on UEFI Secure Boot systems.
c. Resource requirements are excessive, there's no dynamic allocation
so to be safe you need to allocate a minimum of 1x RAM for a swap
partition used for a hibernation image. As a consequence, there's now
an excessive amount of relatively slow swap which can result in swap
thrashing and the effective loss of the system. See "Better
interactivity in low-memory situations "
https://pagure.io/fedora-workstation/issue/98
d. There's no release criterion. Therefore the project wouldn't block
release on any discovered bugs. Serious bugs would likely lead to
reverting any use of hibernation by default, and so it's not at all
likely it'll become supported by default.


-- 
Chris Murphy

[Chris Murphy]

On Thu, Dec 5, 2019 at 5:07 AM Marius Schwarz <fedoradev(a)cloud-foo.de&gt; wrote:
>  Hi,
>
>  Am 25.11.19 um 22:59 schrieb Samuel Sieb:
>  >
>  > Steps 1 - 4 are not benefits, they are workarounds to critical system
>  > utilities required by this change.  I don't understand why this change
>  > is necessary at all.  It only affects local logins and if someone
>  > wants to have an empty password, why make it so difficult?  It's their
>  > choice.  It's not like Fedora has any default logins with empty
>  > passwords, the user has to make their own.
>
>  I know at least two real exiting none nerd users, who will agree with
>  you, as they use FullDiskEnc and no further passwords to Login after boot.
>
>  Which would be impossible if the changes will be made. I personally have
>  only on scenario to offer:
>
>  A tablet pc is booted directly into the desktop, as any other tablet
>  (android or ipad) will do. 
If you set a passphrase for full disk encryption (or only /home mount
point, using custom partitioning)  in the installer, and use the same
passphrase when running GNOME Initial Setup, and then set autologin
for that user, you will get the behavior you describe.


-- 
Chris Murphy

[Chris Murphy]

On Thu, Dec 5, 2019 at 4:03 AM Marius Schwarz <fedoradev(a)cloud-foo.de&gt; wrote:

>  With FDE running and "Suspend-to-disk" selected in your
> screensafer
>  settings, you get asked for your password on hw wakeup before your
>  system gets back running. If someone wants to use such things, he
>  already can. 
FDE depends on initramfs and plymouth to present the UI for volume
unlock passphrase. That stack is limited, and presents numerous UI/UX,
a11y, i18n, and other problems , that must be considered in the
evaluation to enable it by default. And that is the context, how to
better secure user data by default. The mandate is not to make it
perfect. It's to do better.

>  Where is the advantage of homed, considering, that only encrypting
>  /home, is a major security flaw by itself. All your goals are already
>  there and it's more useful and secure too :) I really have a problem
>  understanding why you wanne implement a security flaw and call it "better".
Please read "LUKS by default"
https://pagure.io/fedora-workstation/issue/82

If you read the whole thing, you should come to understand why the
initial agreement to implement full disk encryption was suspended, and
also that this issue has a history proving it is being taken seriously
and deliberately.


-- 
Chris Murphy

[John M. Harris Jr]

On Thursday, December 5, 2019 5:32:55 AM MST Lennart Poettering wrote:
>  > Where is the advantage of homed, considering, that only
> encrypting
>  > /home, is a major security flaw by itself. All your goals are
>  > already there and it's more useful and secure too :) I really have a
>  > problem understanding why you wanne implement a security flaw and
>  > call it "better".
>  
>  
>  Locking down the OS itself and locking down the user's home are two
>  different things, because OS integrity should be bound to different
>  mechanisms than user data encryption. (i.e. OS integrity should be
>  bound to vendor trust or TPM, while user data should be bound to
>  user's security credentials). 
I could not disagree more. That would be fine if the trust were the user or 
the organization that owns the machine, but not vendor trust or anything of 
the like. It's not some third party's system, it's the user or
organization's. 
Additionally, it's much easier to get a third party to sign something for you 
than to get the users themselves, or an organization, to sign it.

>  > If you wanne improve security, please focus on userfriendlyneess
> for
>  > things like "disabling unused usb ports"/"whitelist for usb
>  > ids"/"insecure Highspeed USB network adapter detection"  same for
> any
>  > plugable port you have in your hw. And last, but not least, "motherboard
>  > serial number validation on wakeup" to counter the switch of hw
>  > components.
>  
>  Uh, locking down USB like that doesn't really work. USB has no
>  mechanism for recognizing devices securely, which means any whitelist
>  is pointless because any device can claim to be whatever it wants to
>  be. (And yes, it would be great if we could be a bit more secure
>  there, but it's an orthogonal problem) 
Well, that's not entirely true. For example, while devices could easily give a 
false VID and PID, even just limiting that would be a useful feature, because 
it'd limit the USB functionality of the system (only the modules Linux maps 
those VID/PID combos to would be available).

-- 
John M. Harris, Jr.
Splentity

[Kevin Kofler]

Lennart Poettering wrote:
>  No it does not protect against offline modification. That's why
>  dm-integrity exists after all. 
How do you want to modify an encrypted file system without being able to 
decrypt or encrypt anything?

        Kevin Kofler

[John M. Harris Jr]

On Thursday, December 5, 2019 9:26:09 AM MST Przemek Klosowski via devel 
wrote:
>  On 12/4/19 6:59 PM, John M. Harris Jr wrote:
>  > On Wednesday, December 4, 2019 12:38:20 PM MST Przemek Klosowski via devel
>  > 
>  > wrote:
>  >> - stolen/lost laptop:  I think this is the most important one for most
>  >> people; it is mitigaged by a trusted-network-based decryption, unless
>  >> the device is in unencrypted sleep mode and the new 'beneficial owner'
>  >> manages to read the disk before the system goes down.
>  > 
>  > That may be the case for home users, but not for businesses. Let's take
>  > this example. Employee A has files from a given project, but Employee B
>  > doesn't have access to that project. Employee B is malicious, and takes
>  > Employee A's laptop, gets it on the network, it unencrypts itself and
>  > then takes it.
>  Defending against threat model allowing physical access and malicious
>  insiders, who e.g. install a screen/keyboard capturing camera in the
>  target office, is an entirely different ballgame, requiring multi-factor
>  authentication, etc. --- and even those are not infallible (c.f. wikileaks). 
You're conflating issues. For example, Snowden was an issue of trust, the 
human element. He had access to the data he removed. I'm not talking about 
that, because that is out of scope.

>  >> - someone breaks into your home/office/hotel room and
> extracts the data:
>  >> important to some people but not very common scenario.
>  > 
>  > This is important to most businesses.
>  
>  Same argument as above. Again, we're talking about taking care of the
>  low hanging fruit like hard disks stripped from equipment and sold on Ebay. 
The argument from above does not apply here. You're talking about physical 
security, which is out of scope. I'm talking about software security.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Thursday, December 5, 2019 1:40:02 PM MST Chris Murphy wrote:
>  Hibernation is out of scope to rely on, let alone make a default,
> for
>  at least the following reasons:
>  a. It's not sufficiently well supported upstream for regressions that
>  may appear in new kernels, and not supported by the Fedora kernel
>  team. 
I'm not sure who told you this, but that's not the case. Hibernation is 
supported in Fedora.

>  b. It's disabled by kernel lockdown on UEFI Secure Boot systems.
How so? What "kernel lockdown" are you referring to?

>  c. Resource requirements are excessive, there's no dynamic
> allocation
>  so to be safe you need to allocate a minimum of 1x RAM for a swap
>  partition used for a hibernation image. As a consequence, there's now
>  an excessive amount of relatively slow swap which can result in swap
>  thrashing and the effective loss of the system. See "Better
>  interactivity in low-memory situations "
>  https://pagure.io/fedora-workstation/issue/98 
What are you talking about? You should have at least 1x RAM for swap whether 
you use hibernation or not. If you're having issues, you can adjust the 
swappiness as needed. There is no "effective loss of the system" involved.

>  d. There's no release criterion. Therefore the project
> wouldn't block
>  release on any discovered bugs. Serious bugs would likely lead to
>  reverting any use of hibernation by default, and so it's not at all
>  likely it'll become supported by default. 
Blockers are dynamic. We can make new blockers if we need them.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Thursday, December 5, 2019 3:02:48 PM MST Chris Murphy wrote:
>  On Thu, Dec 5, 2019 at 4:03 AM Marius Schwarz
> <fedoradev(a)cloud-foo.de&gt;
>  wrote: 
 
>  
>  > With FDE running and "Suspend-to-disk" selected in your screensafer
>  > settings, you get asked for your password on hw wakeup before your
>  > system gets back running. If someone wants to use such things, he
>  > already can.
>  
>  
>  FDE depends on initramfs and plymouth to present the UI for volume
>  unlock passphrase. That stack is limited, and presents numerous UI/UX,
>  a11y, i18n, and other problems , that must be considered in the
>  evaluation to enable it by default. And that is the context, how to
>  better secure user data by default. The mandate is not to make it
>  perfect. It's to do better. 
There is really no UI/UX issue. It just needs to ask for a password for a key 
to decrypt. That's it. The UI is limited to either:
1, without Plymouth: A line in a framebuffer asking you to enter a password
2, with Plymouth: A box in the center of your screen that shows circles as you 
enter keys, expecting you to enter a password for a key.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Thursday, December 5, 2019 12:46:51 PM MST Chris Murphy wrote:
>  Therefore the feature is a no op for most users, who are unlikely to
>  enable file system discards using either method. 
This is Fedora, not Sugar on a Stick. Our users are not ignorant of modifying 
fstab, or similar. I wouldn't be so quick to assume that users wouldn't change 
the mount options, especially as there are guides online that suggest adding 
'discard'.

-- 
John M. Harris, Jr.
Splentity

[Chris Murphy]

On Thu, Dec 5, 2019 at 4:49 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Thursday, December 5, 2019 1:40:02 PM MST Chris Murphy wrote:
>  > Hibernation is out of scope to rely on, let alone make a default, for
>  > at least the following reasons:
>  > a. It's not sufficiently well supported upstream for regressions that
>  > may appear in new kernels, and not supported by the Fedora kernel
>  > team.
>
>  I'm not sure who told you this, but that's not the case. Hibernation is
>  supported in Fedora. 
No it isn't. But as I've asked you for your definition of "support"
and you still haven't, and I've offered my own and you haven't
disputed it, I win. That's the short version because you have a track
record of not reading provided references. For the long version:

https://lists.fedoraproject.org/archives/list/[e-mail]....


>  > b. It's disabled by kernel lockdown on UEFI Secure Boot
> systems.
>
>  How so? What "kernel lockdown" are you referring to? 
[    1.097121] Lockdown: swapper/0: Hibernation is restricted; see man
kernel_lockdown.7

And also the above kernel list email thread mentions it also. I'm
surprised you haven't heard of it, it's been around for quite a long
time as it's an obvious attack vector that obviates the point of
Secure Boot.



>  > c. Resource requirements are excessive, there's no dynamic allocation
>  > so to be safe you need to allocate a minimum of 1x RAM for a swap
>  > partition used for a hibernation image. As a consequence, there's now
>  > an excessive amount of relatively slow swap which can result in swap
>  > thrashing and the effective loss of the system. See "Better
>  > interactivity in low-memory situations "
>  > https://pagure.io/fedora-workstation/issue/98
>
>  What are you talking about? You should have at least 1x RAM for swap whether
>  you use hibernation or not. If you're having issues, you can adjust the
>  swappiness as needed. There is no "effective loss of the system" involved.
Already discussed, with examples, in:
https://lists.fedoraproject.org/archives/list/[e-mail].o...

And also a proposal to drop swap on a physical drive in favor of swap
on ZRAM which Fedora does on Live media boot, and for some time on
netinstall/DVD boot.
https://pagure.io/fedora-workstation/issue/82#comment-587914
https://pagure.io/fedora-workstation/issue/98#comment-590690
https://bugzilla.redhat.com/show_bug.cgi?id=1731978

In the case where swap is used heavily, rather than incidentally, the
UX is atrocious. The resulting swap thrashing is ai bad the system is
functionally lost and it's completely reasonable for a user to force
power off.

>  > d. There's no release criterion. Therefore the project wouldn't block
>  > release on any discovered bugs. Serious bugs would likely lead to
>  > reverting any use of hibernation by default, and so it's not at all
>  > likely it'll become supported by default.
>
>  Blockers are dynamic. We can make new blockers if we need them. 
There's actual background study and work to be done before a release
criterion is accepted. Saying things doesn't make them true. The
criterion itself needs to be written, test cases produced and sanity
checked, and perhaps most importantly: who will be fixing the blocker
bugs? You need willing people to be available from multiple teams,
each having enough resources to ensure it gets highly escalated fixes.


--
Chris Murphy

[John M. Harris Jr]

On Thursday, December 5, 2019 6:17:16 PM MST Chris Murphy wrote:
>  On Thu, Dec 5, 2019 at 4:49 PM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  wrote:
>  >
>  >
>  > On Thursday, December 5, 2019 1:40:02 PM MST Chris Murphy wrote:
>  > 
>  > > Hibernation is out of scope to rely on, let alone make a default, for
>  > > at least the following reasons:
>  > > a. It's not sufficiently well supported upstream for regressions that
>  > > may appear in new kernels, and not supported by the Fedora kernel
>  > > team.
>  >
>  >
>  >
>  > I'm not sure who told you this, but that's not the case. Hibernation is
>  > supported in Fedora.
>  
>  
>  No it isn't. But as I've asked you for your definition of "support"
>  and you still haven't, and I've offered my own and you haven't
>  disputed it, I win. That's the short version because you have a track
>  record of not reading provided references. For the long version: 
There's nothing to "win". This isn't a competition. We're all on the
same side 
here.

My definition of "supported in Fedora" is.. supported in Fedora. You can do it 
in Fedora. Without modifying anything. In my DE, for example, I'd do that by 
pressing Alt + F1, the Super key, or click the KDE icon in the left of my 
primary screen's Panel, Leave -> Hibernate.

>  > > b. It's disabled by kernel lockdown on UEFI Secure Boot
> systems.
>  >
>  >
>  >
>  > How so? What "kernel lockdown" are you referring to?
>  
>  
>  [    1.097121] Lockdown: swapper/0: Hibernation is restricted; see man
>  kernel_lockdown.7
>  
>  And also the above kernel list email thread mentions it also. I'm
>  surprised you haven't heard of it, it's been around for quite a long
>  time as it's an obvious attack vector that obviates the point of
>  Secure Boot. 
I don't have a personal system that uses UEFI, much less "Secure Boot", so I

things that affect those systems in Fedora, but not the versions of RHEL I 
work with, I have no reason to follow normally. I'll take a look, however. 
"Secure Boot" is a misnomer, by the way, and hibernation is not a security 
issue. Suspension is, but not hibernation.

>  > What are you talking about? You should have at least 1x RAM for
> swap
>  > whether you use hibernation or not. If you're having issues, you can
>  > adjust the swappiness as needed. There is no "effective loss of the
>  > system" involved. 
...snip...
>  In the case where swap is used heavily, rather than incidentally,
> the
>  UX is atrocious. The resulting swap thrashing is ai bad the system is
>  functionally lost and it's completely reasonable for a user to force
>  power off. 
What are you suggesting the UX is atrocious for? Modifying the swappiness 
value? I have come across situations where a system without swap OOMs, and 
effectively freezes up as a result, causing the user to hard-boot the system, 
but I have never seen that with a system where swap was at least 1x the amount 
of RAM.

>  > > d. There's no release criterion. Therefore the project
> wouldn't block
>  > > release on any discovered bugs. Serious bugs would likely lead to
>  > > reverting any use of hibernation by default, and so it's not at all
>  > > likely it'll become supported by default.
>  >
>  >
>  >
>  > Blockers are dynamic. We can make new blockers if we need them.
>  
>  
>  There's actual background study and work to be done before a release
>  criterion is accepted. Saying things doesn't make them true. The
>  criterion itself needs to be written, test cases produced and sanity
>  checked, and perhaps most importantly: who will be fixing the blocker
>  bugs? You need willing people to be available from multiple teams,
>  each having enough resources to ensure it gets highly escalated fixes. 
It doesn't really make any sense to dismiss this. If it's deemed necessary for 
there to be a blocker, we can make a new blocker. That's a non-issue.

-- 
John M. Harris, Jr.
Splentity

[Chris Murphy]

On Thu, Dec 5, 2019 at 6:40 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Thursday, December 5, 2019 6:17:16 PM MST Chris Murphy wrote: 
>  > No it isn't. But as I've asked you for your definition
> of "support"
>  > and you still haven't, and I've offered my own and you haven't
>  > disputed it, I win. That's the short version because you have a track
>  > record of not reading provided references. For the long version:
>
>  There's nothing to "win". This isn't a competition. We're all on
> the same side
>  here. 
I am not confusing your persistent negativism and contrarianism with a
competition.

I win is tongue in cheek, of course we're all on the same side. Thank
you for saying so explicitly.

>  My definition of "supported in Fedora" is.. supported in
> Fedora. You can do it
>  in Fedora. Without modifying anything. In my DE, for example, I'd do that by
>  pressing Alt + F1, the Super key, or click the KDE icon in the left of my
>  primary screen's Panel, Leave -> Hibernate. 
Using the word to be defined in the definition is insufficient and
vague. It's meaningless.

Feature existence is not support. The community members make a thing
supported, and it's only by community effort and prioritization that
features are supported. The track record of hibernation support, such
as it is, is best effort, but not blocking. If it breaks, Fedora ships
with it broken. There are flat out not enough resources to treat it
with any higher priority than this - it's not a new issue either.





>  > > > b. It's disabled by kernel lockdown on UEFI Secure Boot systems.
>  > >
>  > >
>  > >
>  > > How so? What "kernel lockdown" are you referring to?
>  >
>  >
>  > [    1.097121] Lockdown: swapper/0: Hibernation is restricted; see man
>  > kernel_lockdown.7
>  >
>  > And also the above kernel list email thread mentions it also. I'm
>  > surprised you haven't heard of it, it's been around for quite a long
>  > time as it's an obvious attack vector that obviates the point of
>  > Secure Boot.
>
>  I don't have a personal system that uses UEFI, much less "Secure Boot", so
> I
>  things that affect those systems in Fedora, but not the versions of RHEL I
>  work with, I have no reason to follow normally. I'll take a look, however.
>  "Secure Boot" is a misnomer, by the way, and hibernation is not a security
>  issue. Suspension is, but not hibernation. 
All you're doing is demonstrating you don't understand the issues, or
maybe you don't care about the use case.

The hibernation image is not signed, thus malicious code could be
injected into the image, and loaded and executed upon resume. Contrary
to you merely saying things as if that makes them true, there is in
fact a security issue with hibernation that is incongruent with the
purpose of Secure Boot. It would be no different than allowing
arbitrary loading of unsigned kernel modules, which is also disallowed
by default on Secure Boot systems.

$ dmesg | grep -i lockdown
[    0.000000] Kernel is locked down from EFI secure boot; see man
kernel_lockdown.7
[    1.097121] Lockdown: swapper/0: Hibernation is restricted; see man
kernel_lockdown.7
[    1.438916] Lockdown: systemd: /dev/mem,kmem,port is restricted;
see man kernel_lockdown.7
[    1.439911] Lockdown: systemd: BPF is restricted; see man kernel_lockdown.7

More lockdown is coming in 5.4.


>  > > What are you talking about? You should have at least 1x RAM
> for swap
>  > > whether you use hibernation or not. If you're having issues, you can
>  > > adjust the swappiness as needed. There is no "effective loss of the
>  > > system" involved.
>  ...snip...
>  > In the case where swap is used heavily, rather than incidentally, the
>  > UX is atrocious. The resulting swap thrashing is ai bad the system is
>  > functionally lost and it's completely reasonable for a user to force
>  > power off.
>
>  What are you suggesting the UX is atrocious for? Modifying the swappiness
>  value? I have come across situations where a system without swap OOMs, and
>  effectively freezes up as a result, causing the user to hard-boot the system,
>  but I have never seen that with a system where swap was at least 1x the amount
>  of RAM. 
The thread I cited contains an example of a consistently reproducible
unprivileged compile that acts like a fork bomb that will take down
the system, including one with swap size = 1x RAM. It reproduces on
baremetal and in a VM. The time to OOM providing some chance of
recovery is *extended* the bigger swap is. Thus the problem is
actually made worse.

>  > There's actual background study and work to be done before a
> release
>  > criterion is accepted. Saying things doesn't make them true. The
>  > criterion itself needs to be written, test cases produced and sanity
>  > checked, and perhaps most importantly: who will be fixing the blocker
>  > bugs? You need willing people to be available from multiple teams,
>  > each having enough resources to ensure it gets highly escalated fixes.
>
>  It doesn't really make any sense to dismiss this. If it's deemed necessary for
>  there to be a blocker, we can make a new blocker. That's a non-issue. 
You asked who told me that it's not supported, I referenced you the
thread discussing that point in detail, and yet you're still being
dismissive. You have a hypocrisy problem when you accuse others of
being dismissive, and yet being dismissive of others is your default
position.


-- 
Chris Murphy

[Nico Kadel-Garcia]

On Thu, Dec 5, 2019 at 9:02 AM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:

>  Please don't recommend to anyone to use passwords for SSH. That
> is incredibly
>  insecure, and if privileged users are using password-based SSH, that'll
>  quickly lead to a serious compromise of your entire system, depending on the
>  complexity of the password, of course, but still holds nothing to key-based
>  authentication with the best password. 
I was merely pointing out the options. Believe me, for SSH, I've seen
them some very astute and some quite foolish authentication practices
since I published the first public ports of ssh-1 and ssh-2 to SunOS
back in the 90's.

>  > In common usage, very few people encrypt their home directories
>  > separately from their basic disk image. It makes system management for
>  > administrators or even a local root user very awkward. I could see it
>  > for home directories in "/home", and it would only cost SSH key based
>  > access, not ordinary password or Kerberos ticket based login. But it
>  > sounds quite risky and destabilizing, much as the "kill dangling
>  > processes when people log out". That  caused a lot of shock when it
>  > was activated by default and started killing processes with no
>  > logging. Let's not repeat a surprise like that and avoid killing SSH
>  > key access by default.
>
>  A bit off topic, but where is "kill danging processes when people log out"
>  set? I've not experienced that anywhere. 
Sorry, should have spelt that "dangling". systemd does so by default
based on a compile-time option, and for a time Fedora had it enabled
by default. After quite a furor, elected to disable this normally
unwelcome feture by default, See /etc/systemd/logind.conf.for the
"#KillUserProcesses=no" line.

[Lennart Poettering]

On Fr, 06.12.19 00:39, Kevin Kofler (kevin.kofler(a)chello.at) wrote:

>  Lennart Poettering wrote:
>  > No it does not protect against offline modification. That's why
>  > dm-integrity exists after all.
>
>  How do you want to modify an encrypted file system without being able to
>  decrypt or encrypt anything? 
If you know where stuff is located you can change individual blocks in
files. You are not going to know what you are changing them to, but
you can change it and traditional files will not detect that you did that.

Lennart

--
Lennart Poettering, Berlin

[Lennart Poettering]

On Do, 05.12.19 16:33, John M. Harris Jr (johnmh(a)splentity.com) wrote:

>  > Locking down the OS itself and locking down the user's home
> are two
>  > different things, because OS integrity should be bound to different
>  > mechanisms than user data encryption. (i.e. OS integrity should be
>  > bound to vendor trust or TPM, while user data should be bound to
>  > user's security credentials).
>
>  I could not disagree more. That would be fine if the trust were the user or
>  the organization that owns the machine, but not vendor trust or anything of
>  the like. It's not some third party's system, it's the user or
> organization's.
>  Additionally, it's much easier to get a third party to sign something for you
>  than to get the users themselves, or an organization, to sign it. 
Humm, so you turn off gpg verification of RPMs you install? Nah, you
don't, because you put trust in Fedora that the RPMs they build are
somewhat safe to use. That's what vendor trust means. Since regular
users (and even very technical ones) cannot personally validate the
trustworthiness of compiled code we outsource that to distributions,
and trust the vendor's benevolence and understanding of things. And
that's the correct way to build integrity for OS resources.

Lennart

--
Lennart Poettering, Berlin

[Nico Kadel-Garcia]

On Fri, Dec 6, 2019 at 3:02 AM Lennart Poettering <mzerqung(a)0pointer.de&gt; wrote:

>  Humm, so you turn off gpg verification of RPMs you install? Nah, you
>  don't, because you put trust in Fedora that the RPMs they build are
>  somewhat safe to use. That's what vendor trust means. Since regular
>  users (and even very technical ones) cannot personally validate the
>  trustworthiness of compiled code we outsource that to distributions,
>  and trust the vendor's benevolence and understanding of things. And
>  that's the correct way to build integrity for OS resources. 
We also have the source code, for Fedora, which we can compile and
compare, which has its own trust issues. Vendor trust should not be
automatic nor absolute. GPG keys for RPM are also validation keys, and
provide robust, procedurally integrated checksum. for content that is
often transferred unencrypted and thus is vulnerable to transmission
or local transcription errors. Since most yum configurations publish a
pointer to an offsite public GPG key, they're not that useful for
individually maintained 3rd party repos that people may choose to use.

It's rather different when vendor keys are used to encrypt a user's
*own* data. That's the core issue of Trusted Computing. Even if you
generate your own keys, the vendor normally holds a copy in escrow,
and the vendor has the root keys tied to your personal hardware and
work their way down the keychain. It's part of hte lost key data
recovery system, if systemd is going to enter the game of encrypting
local filesystems robustly. I'd suggest taking a look at the lessons
learned from Trusted Computing.

[Marius Schwarz]

Am 05.12.19 um 21:40 schrieb Chris Murphy:
>  Hibernation is out of scope to rely on, let alone make a default, for
>  at least the following reasons:
>  a. It's not sufficiently well supported upstream for regressions that
>  may appear in new kernels, and not supported by the Fedora kernel
>  team. 
For it not beeing there, it works very well on my Surface ;)

The Surface has sleep issues, due to the unsupported intel hw, but
hibernation works fine.


Best regards,
Marius

[Marius Schwarz]

Am 06.12.19 um 00:33 schrieb John M. Harris Jr:
> > Uh, locking down USB like that doesn't really work. USB has no
> > mechanism for recognizing devices securely, which means any whitelist
> > is pointless because any device can claim to be whatever it wants to
> > be. (And yes, it would be great if we could be a bit more secure
> > there, but it's an orthogonal problem)
>  Well, that's not entirely true. For example, while devices could easily give a 
>  false VID and PID, even just limiting that would be a useful feature, because 
>  it'd limit the USB functionality of the system (only the modules Linux maps 
>  those VID/PID combos to would be available).
>  
If you just go and buy some cheap usb drives from a single seller, you
can endup with the same serial numbers on several drives and i'm not
surprised if they also clone any other IDs.

I think a "we do our best" approach is here really better than doing
nothing at all.

if possible, powering down the usb connectors when they are not in use,
would be a good idea. That still does not protect from destructive
fake-usb devices, but simply inserting something in an open port, would
not work anymore.

I know that not all usb io hw supports it, but when, it should be done.

Best regards,
Marius

[Marius Schwarz]

Am 06.12.19 um 09:02 schrieb Lennart Poettering:
>  Humm, so you turn off gpg verification of RPMs you install? Nah, you
>  don't, because you put trust in Fedora that the RPMs they build are
>  somewhat safe to use. That's what vendor trust means. Since regular 
As the vendor supplies the checksums, what is your point?

GPG RPM verification is there to make sure, that the supplychain isn't
tampered, not if the base code matches the src someone posted on github.

As many fedora builds have "rh" patches added to them, a deep user
survey of sourceodes used would reveal major differences with the
original code. To name two prominent: Apache & Firefox.

In the end, yes we trust in Fedora Devs not include backdoors into the
software, but it has absolutely nothing to do, with homed only
encrypting userhomedirs, instead of the entire system. That way, the
integrity of the system can not be guaranteed and therefor it does not
matter much, if or if the homedir is encrypted.

best regards,
Marius

[John M. Harris Jr]

On Thursday, December 5, 2019 8:12:13 PM MST Chris Murphy wrote:
>  Using the word to be defined in the definition is insufficient and
>  vague. It's meaningless.
>  
>  Feature existence is not support. The community members make a thing
>  supported, and it's only by community effort and prioritization that
>  features are supported. The track record of hibernation support, such
>  as it is, is best effort, but not blocking. If it breaks, Fedora ships
>  with it broken. There are flat out not enough resources to treat it
>  with any higher priority than this - it's not a new issue either. 
Nonetheless, it is "supported" in Fedora. Several of the major Spins, for 
example, the KDE Spin, even have a big button for it in the Application 
Launcher widget. We don't need for it to be a blocker for it to be supported. 
There are far too many things Fedora can do for each one to be a blocker.

>  The hibernation image is not signed, thus malicious code could be
>  injected into the image, and loaded and executed upon resume. Contrary
>  to you merely saying things as if that makes them true, there is in
>  fact a security issue with hibernation that is incongruent with the
>  purpose of Secure Boot. It would be no different than allowing
>  arbitrary loading of unsigned kernel modules, which is also disallowed
>  by default on Secure Boot systems. 
The purpose of Secure Boot is to limit what boots to vendor keys. We've 
circumvented that, but that doesn't make it a "Secure" system.

It makes very little sense to disallow loading of unsigned kernel modules, or 
resuming from an unsigned swap partition, so long as they're encrypted. 
Whoever implemented this, in my opinion, was misguided.

>  > What are you suggesting the UX is atrocious for? Modifying the
> swappiness
>  > value? I have come across situations where a system without swap OOMs,
>  > and
>  > effectively freezes up as a result, causing the user to hard-boot the
>  > system, but I have never seen that with a system where swap was at least
>  > 1x the amount of RAM.
>  
>  
>  The thread I cited contains an example of a consistently reproducible
>  unprivileged compile that acts like a fork bomb that will take down
>  the system, including one with swap size = 1x RAM. It reproduces on
>  baremetal and in a VM. The time to OOM providing some chance of
>  recovery is *extended* the bigger swap is. Thus the problem is
>  actually made worse. 
That's not a problem. That's the system doing what you've told it. If you 
don't want it to do that, put quotas on that user. This is what we do in 
enterprise environments, for example.

>  > It doesn't really make any sense to dismiss this. If
> it's deemed necessary
>  > for there to be a blocker, we can make a new blocker. That's a
>  > non-issue.
>  
>  You asked who told me that it's not supported, I referenced you the
>  thread discussing that point in detail, and yet you're still being
>  dismissive. You have a hypocrisy problem when you accuse others of
>  being dismissive, and yet being dismissive of others is your default
>  position. 
That's because it is supported. It works out of box, and several DEs even have 
a button for it. I don't know if GNOME does, but the GNOME Spin has always 
been a bit special.

The only time it wouldn't work seems to be in one of those special UEFI + 
Secure Boot cases.


-- 
John M. Harris, Jr.
Splentity

[Marius Schwarz]

Am 05.12.19 um 21:21 schrieb Andreas Tunek:
>  On Thu, 5 Dec 2019, 02:11 John M. Harris Jr,
> <johnmh(a)splentity.com
>  <mailto:[e-mail]>> wrote:
>
>
>      Rebuild initramfs when the system-wide keyboard
>      layout is changed.
>
>
>  I change my keyboard layout several times every hour.
>  
I had the wrong keyboard layout shipped with my laptop, and had to
change the system kb layout very frequently per hour when i needed "|" ;)

@JMH: Sorry, that idea isn't working in the wild.

best regards,
Marius

[John M. Harris Jr]

On Friday, December 6, 2019 1:02:04 AM MST Lennart Poettering wrote:
>  On Do, 05.12.19 16:33, John M. Harris Jr (johnmh(a)splentity.com)
> wrote:
>  
>  
>  > > Locking down the OS itself and locking down the user's home are two
>  > > different things, because OS integrity should be bound to different
>  > > mechanisms than user data encryption. (i.e. OS integrity should be
>  > > bound to vendor trust or TPM, while user data should be bound to
>  > > user's security credentials).
>  >
>  >
>  >
>  > I could not disagree more. That would be fine if the trust were the user
>  > or the organization that owns the machine, but not vendor trust or
>  > anything of the like. It's not some third party's system, it's the user
>  > or organization's. Additionally, it's much easier to get a third party to
>  > sign something for you than to get the users themselves, or an
>  > organization, to sign it.
>  
>  Humm, so you turn off gpg verification of RPMs you install? Nah, you
>  don't, because you put trust in Fedora that the RPMs they build are
>  somewhat safe to use. That's what vendor trust means. Since regular
>  users (and even very technical ones) cannot personally validate the
>  trustworthiness of compiled code we outsource that to distributions,
>  and trust the vendor's benevolence and understanding of things. And
>  that's the correct way to build integrity for OS resources. 
Vendor trust for packages are not the same as vendor trust for the boot 
environment. A better solution for the boot environment, with UX in mind, 
would be to generate a key for the system at install time, and require that 
the kernel+initramfs be signed with that key in order to boot. This would 
prevent individuals, outside of the folks the user has trusted to maintain 
their kernel image for them, normally the packagers of Fedora's kernel but 
sometimes Linux-libre or similar, from modifying their boot environment.

Even for packages, I don't trust Red Hat's key outright. For example, at 
$WORK, where we deploy RHEL, we resign using our own GPG keys when we bring in 
updates, removing things like PackageKit and flatpak.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Friday, December 6, 2019 6:52:30 AM MST Marius Schwarz wrote:
>  If you just go and buy some cheap usb drives from a single seller,
> you
>  can endup with the same serial numbers on several drives and i'm not
>  surprised if they also clone any other IDs. 
The serial number doesn't actually matter, and the VID/PID is actually 
expected to be the same for the same product. That's how what I was suggesting 
would actually work, you're trusting essentially *that model* and the kernel 
module that Linux maps it to.

It's not foolproof, as BadUSB is pretty common, but it'd be better than 
nothing.

>  I think a "we do our best" approach is here really better
> than doing
>  nothing at all.
>  
>  if possible, powering down the usb connectors when they are not in use,
>  would be a good idea. That still does not protect from destructive
>  fake-usb devices, but simply inserting something in an open port, would
>  not work anymore. 
The viability of that would depend heavily on the hubs in use.

>  I know that not all usb io hw supports it, but when, it should be
> done. 
...as you pointed out. :)

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Friday, December 6, 2019 7:50:35 AM MST Marius Schwarz wrote:
>  Am 05.12.19 um 21:21 schrieb Andreas Tunek:
>  > On Thu, 5 Dec 2019, 02:11 John M. Harris Jr, <johnmh(a)splentity.com
>  > 
>  > <mailto:[e-mail]>> wrote:
>  >     Rebuild initramfs when the system-wide keyboard
>  >     layout is changed.
>  > 
>  > I change my keyboard layout several times every hour.
>  
>  I had the wrong keyboard layout shipped with my laptop, and had to
>  change the system kb layout very frequently per hour when i needed "|" ;)
>  
>  @JMH: Sorry, that idea isn't working in the wild.
>  
>  best regards,
>  Marius 
Unless you're rebooting several times per hour as well, that would still work.

-- 
John M. Harris, Jr.
Splentity

[Marius Schwarz]

Am 05.12.19 um 23:02 schrieb Chris Murphy:
>  read "LUKS by default"
>  https://pagure.io/fedora-workstation/issue/82
>
>  If you read the whole thing, you should come to understand why the
>  initial agreement to implement full disk encryption was suspended, and
>  also that this issue has a history proving it is being taken seriously
>  and deliberately. 
First paragraph:

"Figure out the scope - presumably workstation only since servers and
cloud VMs need to boot unattended. But perhaps not desktop VMs?"

VM's in the masses are  not installed via anaconda.
One VM is installed via anaconda, and the rest is a clone of the image
produced by the install and later setup.
Thats how cloudservers are born ;)

If the vm is paravirtualized ( i.e. Xen ) you can't even enter a
plymouth password to unlock a drive. Even if the VM would be encrypted
and running in QEMU, which would use up a lot of cpu power, it's still
not safe. Same as with the partly encryption of homedirs in homed is
insecure, only encrypting the vm is insecure too, due to the
mastersystem being able to intercept anything send to the vm. If someome
tampered the host, the guest encryption is null and void. If the host is
encrypted, there is no longer a need to encrypt the vm.

"Figure out intersection with current work to use the TPM to allow
booting to GDM without entering the password."

Means, if someone steals the device, he can boot a system. Even if we
assume that the systemcode is safe and there is no way to interrupt the
bootprocess, we are now able to attack the login, which will be much
easier than the encryption key, which is massive compared to the
passwords in use.

So, NO: no booting without someone entering something.

Besides the already spoken out point, that not all users want
encryption, because it takes into consideration to manage an additional
passcode,
the entire discussion here was about "encrypt everything, or nothing,
because partly does not help at all".

BTW:

"catanzaro commented a year ago Also: tablets need an OSK to be able to
decrypt the disk."

Add: grub needs an OSK too, or how do you select the matching kernel?

Skipping the rest of it, the simple solution to the problem discussed
would be to ask for encryption more prominent, with a tiny bit of
background for the user.

Before i forget, there can be multiply passwords for a luks key, so
there is no need to wipe a disk, just have a good OSK with all installed
and or system selected languages at hand.


best regards,
Marius

[Marius Schwarz]

Am 06.12.19 um 00:53 schrieb John M. Harris Jr:
>  There is really no UI/UX issue. It just needs to ask for a password for a key 
>  to decrypt. That's it. The UI is limited to either:
>  1, without Plymouth: A line in a framebuffer asking you to enter a password
>  2, with Plymouth: A box in the center of your screen that shows circles as you 
>  enter keys, expecting you to enter a password for a key.
>  
It's not an ui issue, it's a keyboardlayout issue. And therefor teh ui
needs a change, to be able to select the keyboardlayout the password was
entered with, which can differ from the one used on boot.

But plymouth ui needs to be changed anyway to get a working OSK, or
tablets and mobiles are not be able to use encryption.

best regards,
Marius

[Marius Schwarz]

Am 06.12.19 um 08:57 schrieb Lennart Poettering:
>  If you know where stuff is located you can change individual blocks
> in
>  files. You are not going to know what you are changing them to, but
>  you can change it and traditional files will not detect that you did that.
>  
That is correct, but i did not see, how dm-integrity can help here, as
there is nothing to compare it to,
as dm-integrity was invented with raidsystems in mind, where it makes a
lot of sense.

I found no evidence that it will autocorrect a "manipulated" sector, and
i guess, that it does not even know how to fix it.

Does it stop booting?
Does it send an alarm to the user?
When does it do this?
Does it do it at all?
What if the sector is not hit while booting?
How and when do we get a notice of the manipulation?

Best regards,
Marius

[John M. Harris Jr]

On Friday, December 6, 2019 8:30:48 AM MST Marius Schwarz wrote:
>  It's not an ui issue, it's a keyboardlayout issue. And
> therefor teh ui
>  needs a change, to be able to select the keyboardlayout the password was
>  entered with, which can differ from the one used on boot. 
Well, that's not actually the case. It's sufficient for the primary keyboard 
layout of the system to be used during initramfs, which can be changed and 
then the initramfs rebuilt.

>  But plymouth ui needs to be changed anyway to get a working OSK, or
>  tablets and mobiles are not be able to use encryption. 
What you're asking for would be incredibly difficult. It could be done, but 
not with Plymouth, and not without increasing the size of initramfs by several 
10s of not 100s of MB. Right now, Plymouth doesn't handle input. Well, it 
does, but not most things. It's actually the underlying vtty that handles 
input of the passphrase.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Friday, December 6, 2019 8:27:32 AM MST Marius Schwarz wrote:
>  Am 05.12.19 um 23:02 schrieb Chris Murphy:
>  > read "LUKS by default"
>  > https://pagure.io/fedora-workstation/issue/82
>  > 
>  > If you read the whole thing, you should come to understand why the
>  > initial agreement to implement full disk encryption was suspended, and
>  > also that this issue has a history proving it is being taken seriously
>  > and deliberately.
>  
>  First paragraph:
>  
>  "Figure out the scope - presumably workstation only since servers and
>  cloud VMs need to boot unattended. But perhaps not desktop VMs?"
>  
>  VM's in the masses are  not installed via anaconda.
>  One VM is installed via anaconda, and the rest is a clone of the image
>  produced by the install and later setup.
>  Thats how cloudservers are born ;) 
That's how some people do it, but most "cloudservers" are built
automatically 
from a kickstart.

>  If the vm is paravirtualized ( i.e. Xen ) you can't even enter a
>  plymouth password to unlock a drive. 
Well, you can. Why wouldn't you be able to?


>  Even if the VM would be encrypted and running in QEMU, which would
> use up
>  a lot of cpu power, it's still not safe. 
Yeah, shared resources throw security out the window.

>  Same as with the partly encryption of homedirs in homed is
>  insecure, only encrypting the vm is insecure too, due to the
>  mastersystem being able to intercept anything send to the vm. If someome
>  tampered the host, the guest encryption is null and void. If the host is
>  encrypted, there is no longer a need to encrypt the vm. 
Well, VMs are not generally stored on the drive of the host OS, except in one-
offs and on consumer desktops/laptops.

>  "Figure out intersection with current work to use the TPM to
> allow
>  booting to GDM without entering the password."
>  
>  Means, if someone steals the device, he can boot a system. Even if we
>  assume that the systemcode is safe and there is no way to interrupt the
>  bootprocess, we are now able to attack the login, which will be much
>  easier than the encryption key, which is massive compared to the
>  passwords in use. 
Yeah, there are a contingent here that believe that it's not necessary to 
ensure the person booting the device is actually authorized to access the 
content of the laptop..

And, because it makes things "easy" for the user, I get the feeling something 
like this will wind up getting implemented. Oh well.

>  So, NO: no booting without someone entering something.
>  
>  Besides the already spoken out point, that not all users want
>  encryption, because it takes into consideration to manage an additional
>  passcode,
>  the entire discussion here was about "encrypt everything, or nothing,
>  because partly does not help at all".
>  
>  BTW:
>  
>  "catanzaro commented a year ago Also: tablets need an OSK to be able to
>  decrypt the disk."
>  
>  Add: grub needs an OSK too, or how do you select the matching kernel? 
Adding an on-screen keyboard to GRUB would be even more difficult than adding 
it to the initramfs environment. GRUB simply cannot support that. It'd have to 
be rewritten from the ground up to support that sort of thing.

>  Skipping the rest of it, the simple solution to the problem
> discussed
>  would be to ask for encryption more prominent, with a tiny bit of
>  background for the user.
>  
>  Before i forget, there can be multiply passwords for a luks key, so
>  there is no need to wipe a disk, just have a good OSK with all installed
>  and or system selected languages at hand. 
Are you suggesting "translating", for lack of a better term, the passphrase 
between all available keyboard layouts? That would decrease the effective 
security of your system considerably..

-- 
John M. Harris, Jr.
Splentity

[Przemek Klosowski]

On 12/5/19 6:48 PM, John M. Harris Jr wrote:
> > c. Resource requirements are excessive, there's no dynamic
> allocation
> > so to be safe you need to allocate a minimum of 1x RAM for a swap
> > partition used for a hibernation image. As a consequence, there's now
> > an excessive amount of relatively slow swap which can result in swap
> > thrashing and the effective loss of the system. See "Better
> > interactivity in low-memory situations "
> >
> https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure....
>  What are you talking about? You should have at least 1x RAM for swap whether
>  you use hibernation or not. If you're having issues, you can adjust the
>  swappiness as needed. There is no "effective loss of the system" involved.
Many systems have 8, 16 or even 32GB of RAM now. Mine has 16GB, and and 
I regularly run out of memory because some Chrome tab is open to a 
website that keeps reloading ads and leaking memory, sometimes consuming 
gigabytes per tab.

The disk speed being in the double digit MB/s, swapping multiple GB 
takes minutes. During this time, the system is unresponsive, 
unfortunately---the mouse is frozen, alt-tab does not switch between 
apps, etc. Sometimes I can flip to a text console and kill chrome, but 
most of the time the only remedy is to wait it out or force reboot. I am 
not sure if the freezing is mostly kernel's fault or the display 
subsystem's fault.

For that reason, I don't believe that the old advice of swap = 2*RAM  is 
relevant today. Even 1*RAM is of questionable utility---the main reason 
for 1*RAM guideline is the ability to hibernate to swap, in my opinion. 
Instead, I'd say that with the RAM prices being what they are, everyone 
should try to buy as much RAM as appropriate for their regular use.

[James Cassell]

On Fri, Dec 6, 2019, at 11:40 AM, John M. Harris Jr wrote:
>  Are you suggesting "translating", for lack of a better
> term, the passphrase 
>  between all available keyboard layouts? That would decrease the effective 
>  security of your system considerably..
>   
I'd suggest "translating" the password between the default layout and all
layouts selected in anaconda. Just recently, I found that the initramfs honored my
anaconda key layout, but the rescue initramfs did not. I'd expect that in the common
case, this would eat one extra luks slot, and could save a lot of head ache without
meaningfully reducing security.

V/r,
James Cassell

[Lennart Poettering]

On Fr, 06.12.19 16:42, Marius Schwarz (fedoradev(a)cloud-foo.de) wrote:

>  Am 06.12.19 um 08:57 schrieb Lennart Poettering:
>  > If you know where stuff is located you can change individual blocks in
>  > files. You are not going to know what you are changing them to, but
>  > you can change it and traditional files will not detect that you did that.
>  >
>
>  That is correct, but i did not see, how dm-integrity can help here, as
>  there is nothing to compare it to,
>  as dm-integrity was invented with raidsystems in mind, where it makes a
>  lot of sense. 
Nah, one of its primary usecases is to provide authenticated disk
encryption in combination with dm-crypt. See here for example:

https://gitlab.com/cryptsetup/cryptsetup/wikis/DMIntegrity

>  I found no evidence that it will autocorrect a
> "manipulated" sector, and
>  i guess, that it does not even know how to fix it. 
It will not.

>  Does it stop booting?
>  Does it send an alarm to the user?
>  When does it do this?
>  Does it do it at all?
>  What if the sector is not hit while booting?
>  How and when do we get a notice of the manipulation? 
When a sector protected by dm-integrity that has been manipulated is
read dm-integrity will raise EIO to the layer above. If the layer
above is a file system it's up the fs to decide what to do with that
failure.

Lennart

--
Lennart Poettering, Berlin

[Chris Murphy]

On Fri, Dec 6, 2019 at 7:46 AM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Thursday, December 5, 2019 8:12:13 PM MST Chris Murphy wrote:
>  > Using the word to be defined in the definition is insufficient and
>  > vague. It's meaningless.
>  >
>  > Feature existence is not support. The community members make a thing
>  > supported, and it's only by community effort and prioritization that
>  > features are supported. The track record of hibernation support, such
>  > as it is, is best effort, but not blocking. If it breaks, Fedora ships
>  > with it broken. There are flat out not enough resources to treat it
>  > with any higher priority than this - it's not a new issue either.
>
>  Nonetheless, it is "supported" in Fedora. 
And now you're using private terminology, and it amounts to denialism
and arguing rather than issue progression. It's tedious and makes the
conversation as pointless as talking to a wall.

> Several of the major Spins, for
>  example, the KDE Spin, even have a big button for it in the Application
>  Launcher widget. We don't need for it to be a blocker for it to be supported.
>  There are far too many things Fedora can do for each one to be a blocker. 
And likewise there are minimum expectations of reliability for
something to be enabled by default, and hibernation does not qualify.
https://lists.fedoraproject.org/archives/list/[e-mail].o...


>  > The hibernation image is not signed, thus malicious code could be
>  > injected into the image, and loaded and executed upon resume. Contrary
>  > to you merely saying things as if that makes them true, there is in
>  > fact a security issue with hibernation that is incongruent with the
>  > purpose of Secure Boot. It would be no different than allowing
>  > arbitrary loading of unsigned kernel modules, which is also disallowed
>  > by default on Secure Boot systems.
>
>  The purpose of Secure Boot is to limit what boots to vendor keys. We've
>  circumvented that, but that doesn't make it a "Secure" system.
>
>  It makes very little sense to disallow loading of unsigned kernel modules, or
>  resuming from an unsigned swap partition, so long as they're encrypted.
>  Whoever implemented this, in my opinion, was misguided. 
In the first paragraph you correctly state Secure Boot limits what
boots to code that's been signed by Fedora's signing key (or
alternatively user keys, if so configured). And in the second you
describe a means of thwarting Secure Boot by permitting arbitrary code
execution, and advocate for this by default, while also questioning
the decision making capacity of others.

What does encryption have to do with it? Do you think encryption
mimics or is akin to code signing? Does it provide error detection or
error correction? If you change a single block of encrypted data do
you think upon decryption there's EIO or some kind of warning?




>  > > What are you suggesting the UX is atrocious for? Modifying the swappiness
>  > > value? I have come across situations where a system without swap OOMs,
>  > > and
>  > > effectively freezes up as a result, causing the user to hard-boot the
>  > > system, but I have never seen that with a system where swap was at least
>  > > 1x the amount of RAM.
>  >
>  >
>  > The thread I cited contains an example of a consistently reproducible
>  > unprivileged compile that acts like a fork bomb that will take down
>  > the system, including one with swap size = 1x RAM. It reproduces on
>  > baremetal and in a VM. The time to OOM providing some chance of
>  > recovery is *extended* the bigger swap is. Thus the problem is
>  > actually made worse.
>
>  That's not a problem. That's the system doing what you've told it. If you
>  don't want it to do that, put quotas on that user. This is what we do in
>  enterprise environments, for example. 
You're making excuses for an unprivileged process fork bombing a
default installation. And you're also changing the goal post by
blaming the user.

The topic, set by you, is the assertion that you've never seen a
system freeze up when swap size is at least 1x RAM. I have provided a
reproducer that contradicts this. And instead of acknowledging that,
either at face value or testing it yourself, you proceed with totally
off topic distractions that also blame the user.

It's a debate style that is intended to generate more debate without
conclusion or progression of the issues, and I consider it
intellectually dishonest.


>  > > It doesn't really make any sense to dismiss this. If
> it's deemed necessary
>  > > for there to be a blocker, we can make a new blocker. That's a
>  > > non-issue.
>  >
>  > You asked who told me that it's not supported, I referenced you the
>  > thread discussing that point in detail, and yet you're still being
>  > dismissive. You have a hypocrisy problem when you accuse others of
>  > being dismissive, and yet being dismissive of others is your default
>  > position.
>
>  That's because it is supported. It works out of box, and several DEs even have
>  a button for it. I don't know if GNOME does, but the GNOME Spin has always
>  been a bit special. 
More private terminology, as if you think repeating it will make it
stick. The difference with my repetition is it's backed by dozens of
conversations among various developers and stakeholders in the Fedora
community considering it not supported, it isn't me personally
asserting a belief or fantasy.

It doesn't work out of the box with sufficient consistency or
predictability to consider it supported or supportable. You'll find
myriad upstream and downstream bug reports about hibernation that
languish indefinitely. Some do get fixed. Whether it works depends on
make/model, the firmware revision, and kernel version.

A common theme in the discussion thread I cite earlier in this email,
is corrupt hibernation images on resume. I have two computers that
exhibit this behavior. I do not consider that it works out of the box
at all. If I take a very selfish point of view about only my
experiences I would say it's 100% broken out of the box.

But being one to recognize the lay of the land is complex, I don't
take only my own experiences to be the  way of things, like you are.
I'm not dismissive of other people's experiences, as you are. I use an
inclusive language: it works for some, it doesn't work for others.
It's sufficiently unreliable and unpredictable that it cannot
reasonably be considered supported or supportable on Fedora without
either a lot more resources, or a white list of hardware.

Your style of debate is grating and can be summarized as: 'I am always
right and you are always wrong, you should do things my way because
you are doing it wrong and everyone doing things differently than I
want them is wrong and misguided.'

It's annoying.

>  The only time it wouldn't work seems to be in one of those special UEFI +
>  Secure Boot cases. 
It's not special. It happens to be the default firmware and
configuration of most new x86_64 hardware, and the default policy upon
installation by Fedora. And that means hibernation is not presently
possible by default on those systems. There is no agreement by
distributions how to handle hibernation image signing that upstream
will accept and Fedora isn't likely to carry out of tree patches for
such a thing.


-- 
Chris Murphy

[Lata Lante]

>  If you use LUKS/dm-crypt without dm-integrity and you have a clue
>  where things are located then you can change files without anything
>  being able to detect that. (On btrfs you might have some luck, since
>  it has data checksumming, but ext4 and other traditional file systems
>  do not). 
Of course Ext4 can.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit...
The question is when Fedora users will be able to use fs-verity.
Because for the encryption support package (including Adiantum) they can't wait for
support.
https://github.com/google/fscrypt

[Lennart Poettering]

On Fr, 06.12.19 18:58, Lata Lante (latalante(a)cock.li) wrote:

>  > If you use LUKS/dm-crypt without dm-integrity and you have a
> clue
>  > where things are located then you can change files without anything
>  > being able to detect that. (On btrfs you might have some luck, since
>  > it has data checksumming, but ext4 and other traditional file systems
>  > do not).
>  Of course Ext4 can.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit...
Uh? fs-verity is read-only integrity protection, i.e. akin to
dm-verity, not akin to dm-integrity.

Also fs-verity applies to individual files only, it thus only has very
specific usecases. You cannot sensibly do fs-verity across the whole
OS tree, you'd spent agres to set it up at boot...

Lennart

--
Lennart Poettering, Berlin

[Chris Murphy]

On Fri, Dec 6, 2019 at 8:28 AM Marius Schwarz <fedoradev(a)cloud-foo.de&gt; wrote:
>  Am 05.12.19 um 23:02 schrieb Chris Murphy:
>
>  read "LUKS by default"
>
>  https://pagure.io/fedora-workstation/issue/82
>
>  If you read the whole thing, you should come to understand why the
>  initial agreement to implement full disk encryption was suspended, and
>  also that this issue has a history proving it is being taken seriously
>  and deliberately.
>
>
>  First paragraph: 
I suggested reading the entire thread, not pulling it apart. If you
want to do that please start a new thread.


>  "Figure out intersection with current work to use the TPM to
> allow booting to GDM without entering the password."
>
>  Means, if someone steals the device, he can boot a system. Even if we assume that the
> systemcode is safe and there is no way to interrupt the bootprocess, we are now able to
> attack the login, which will be much easier than the encryption key, which is massive
> compared to the passwords in use.
>
>  So, NO: no booting without someone entering something.
>
>  Besides the already spoken out point, that not all users want encryption, because it
> takes into consideration to manage an additional passcode,
>  the entire discussion here was about "encrypt everything, or nothing, because partly
> does not help at all". 
This is not correct. /home only encryption is part of that discussion:
this includes a single home volume mounted at /home with a single LUKS
DEK, one or more KEKs (user passphrase stored in LUKS keyslot), as
well as individual separately encrypted ~/ per user.

Your position as stated is absurd because it assumes a compromised
system is inevitable in one case but not the other. Case 1 is ~/ only
is encrypted, and your assertion is that this does *not help at all*
improve user data confidentiality on the basis that without / and swap
being encrypted that ~/ is vulnerable to a targeted attack via / or
swap being compromised. Case 2 is present day Fedora "full disk
encryption" which does not lock down the bootloader,  /boot volume is
not encrypted, and thus the initramfs is vulnerable to a targeted
attack which could be used to deploy a key logger or whatever you're
worried about in Case 1.

It is not valid to use different goal posts for the different cases
under comparison. Right now Fedora's default is no encryption at all,
and the way you've worded your assertion, you propose user data would
become more susceptible to attack or exfiltration if ~/ alone is
encrypted. That must be hyperbole so I insist that you do a better job
of constraining your assertions to things we can all agree on.

Otherwise you are invited to describe exactly how encrypted ~/ alone
makes the user worse off than today's default, which is encrypting
nothing. Because that is the more valid comparison: what we are doing
now, versus what we should do as a next logical step. The next logical
step is not the final step, it probably will be a baby step. So try
not to get carried away with unrealistic demands for which resources
don't exist. Whatever happens requires a plan.



-- 
Chris Murphy

[Przemek Klosowski]

On 12/6/19 11:40 AM, John M. Harris Jr wrote:
> > Means, if someone steals the device, he can boot a system. Even
> if we
> > assume that the systemcode is safe and there is no way to interrupt the
> > bootprocess, we are now able to attack the login, which will be much
> > easier than the encryption key, which is massive compared to the
> > passwords in use.
>  Yeah, there are a contingent here that believe that it's not necessary to
>  ensure the person booting the device is actually authorized to access the
>  content of the laptop.. 
Which threat model do you consider here? I don't remember anyone 
suggesting that the person who physically boots the machine gets 
unimpeded access to the contents, without any authentication: the 
assumption is that system boots into an authentication login prompt.

We discussed the following threats:

- removing the physical unencrypted (or encrypted) disk, and reading and 
even modifying it in another system

- interrupting the boot process and bypassing authentication

- bypassing or bruteforcing the login authentication (Marius' concern)

Each threat requires a different mitigation. The Android model depends 
on the fact that the storage media is not easily removable, and is 
encrypted with securely stored keys (a la TPM), and the fact that the 
boot process is secure so you can't break into it after the storage is 
decrypted, so then the remaining threat vector is breaking the user 
login authentication shown when the system completes the boot process.

At some point you said that you don't believe that Android model is 
secure -- could you explain why do you believe that? This is relevant to 
our discussion because I believe that we should follow the Android/IOS 
model.

[Chris Murphy]

On Fri, Dec 6, 2019 at 9:41 AM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Friday, December 6, 2019 8:27:32 AM MST Marius Schwarz wrote: 
>  > "Figure out intersection with current work to use the TPM
> to allow
>  > booting to GDM without entering the password."
>  >
>  > Means, if someone steals the device, he can boot a system. Even if we
>  > assume that the systemcode is safe and there is no way to interrupt the
>  > bootprocess, we are now able to attack the login, which will be much
>  > easier than the encryption key, which is massive compared to the
>  > passwords in use.
>
>  Yeah, there are a contingent here that believe that it's not necessary to
>  ensure the person booting the device is actually authorized to access the
>  content of the laptop.. 
Is it your position that encrypting ~/ alone is not an incremental
improvement? Are you suggesting it's necessary to assume Fedora
Workstation users are subject to targeted attacks? And therefore
install time default must encrypt /, /home, swap? And that this
targeted attack, that applies to everyone, does not include targeted
attacks on unencrypted /boot or the bootloader for reasons you refuse
to elaborate on? And you propose that users should have to opt out of
this, rather than opt in?


>  And, because it makes things "easy" for the user, I get the
> feeling something
>  like this will wind up getting implemented. Oh well. 
It's already implemented. There is no encryption by default.

You've set up a false dilemma where the only two valid options are do
nothing and do what you want. You reject all intermediate options,
dismissing them out of turn without any meaningful evaluation. And
that's on top of having said you are unconcerned with GNOME and don't
care about the outcome. If you don't care, why are you still arguing?


--
Chris Murphy

[Kevin Kofler]

Chris Murphy wrote:
>  Hibernation is out of scope to rely on, let alone make a default,
> for
>  at least the following reasons: 
[snip]
>  b. It's disabled by kernel lockdown on UEFI Secure Boot systems.
This, in fact, is one more reason to disable Restricted Boot first thing, 
before doing anything else with YOUR computer. Because with Restricted Boot, 
it is effectively NO LONGER YOUR computer.

The fact that this "security" model is inherently incompatible with features 
as common and as frequently used as hibernation and that the "remedy" is to 
disallow the user from using those features shows that this model is 
inherently flawed and unacceptable for a Free Software operating system.

Treacherous computing needs to stop! Reclaim your computer! The user should 
own the computer, not the other way round!

        Kevin Kofler

[Kevin Kofler]

Chris Murphy wrote:
>  Is it your position that encrypting ~/ alone is not an incremental
>  improvement? Are you suggesting it's necessary to assume Fedora
>  Workstation users are subject to targeted attacks? And therefore
>  install time default must encrypt /, /home, swap? And that this
>  targeted attack, that applies to everyone, does not include targeted
>  attacks on unencrypted /boot or the bootloader for reasons you refuse
>  to elaborate on? 
Anaconda should encrypt /boot too. Calamares does it. GRUB supports 
prompting for a LUKS passphrase and decrypting LUKS with it. LUKS 1 has been 
supported by GRUB for a while (so Calamares still uses that for now), and 
there is now a patchset under review for LUKS 2 support:
https://lists.gnu.org/archive/html/grub-devel/2019-11/msg00000.html

Then (in the Calamares setup) the other partitions are unlocked 
automatically using a keyfile residing on the encrypted /boot, so that the 
user has to enter the passphrase only once (in GRUB).

        Kevin Kofler

[Kevin Kofler]

Marius Schwarz wrote:
>  "Figure out intersection with current work to use the TPM to
> allow
>  booting to GDM without entering the password."
>  
>  Means, if someone steals the device, he can boot a system. 
And conversely, if you move the hard disk to another computer, you can no 
longer read it. And if your motherboard breaks down, instant data loss.

In addition, I do not trust the TPM or any other Treacherous Computing 
component.

If you want to rely on a hardware key, it should at least be on a removable 
USB token (a keyfile on a plain mass-storage USB stick is enough!), not 
hard-wired into the computer like the TPM.

        Kevin Kofler

[Kevin Kofler]

Lennart Poettering wrote:
>  If you know where stuff is located you can change individual blocks
> in
>  files. You are not going to know what you are changing them to, but
>  you can change it and traditional files will not detect that you did that. 
Then you get unpredictable garbage as the result, which is useless if your 
goal (as the attacker) is to plant a trojan horse that steals encrypted data 
while it is decrypted. (And of course, you cannot directly decrypt the data 
either.) The only way to exfiltrate the data is to attack the system while 
it is running (online).

        Kevin Kofler

[John M. Harris Jr]

On Friday, December 6, 2019 10:05:42 AM MST Przemek Klosowski via devel wrote:
>  Many systems have 8, 16 or even 32GB of RAM now. Mine has 16GB, and
> and
>  I regularly run out of memory because some Chrome tab is open to a
>  website that keeps reloading ads and leaking memory, sometimes consuming
>  gigabytes per tab. 
I could only suggest not to use proprietary software, such as Chrome.

>  The disk speed being in the double digit MB/s, swapping multiple GB
>  takes minutes. During this time, the system is unresponsive,
>  unfortunately---the mouse is frozen, alt-tab does not switch between
>  apps, etc. Sometimes I can flip to a text console and kill chrome, but
>  most of the time the only remedy is to wait it out or force reboot. I am
>  not sure if the freezing is mostly kernel's fault or the display
>  subsystem's fault.
>  
>  For that reason, I don't believe that the old advice of swap = 2*RAM  is
>  relevant today. Even 1*RAM is of questionable utility---the main reason
>  for 1*RAM guideline is the ability to hibernate to swap, in my opinion.
>  Instead, I'd say that with the RAM prices being what they are, everyone
>  should try to buy as much RAM as appropriate for their regular use. 
That's not really an option for many users, such as myself. For example, the 
maximum amount of memory one could install in the system that I'm using to 
type this message on is 8 GiB. That is, a maximum of two slots of 4 GiB.

I'd rather just not use software that constantly leaks memory, and so I don't 
use web browsers often, but I use either Falkon or Firefox when I do need a 
web browser. This probably wouldn't work for most people, as it's common for 
folks to prefer to do everything in web browsers these days, and I get that. 
To each their own. I still build my systems with 1*RAM, and set the swappiness 
as appropriate. It seems to work out well for me, and so I can only recommend 
that others give it a try, to see if it works for them.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Friday, December 6, 2019 11:22:34 AM MST Chris Murphy wrote:
>  On Fri, Dec 6, 2019 at 7:46 AM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  wrote:
>  >
>  >
>  > On Thursday, December 5, 2019 8:12:13 PM MST Chris Murphy wrote:
>  > 
>  > > Using the word to be defined in the definition is insufficient and
>  > > vague. It's meaningless.
>  > >
>  > >
>  > >
>  > > Feature existence is not support. The community members make a thing
>  > > supported, and it's only by community effort and prioritization that
>  > > features are supported. The track record of hibernation support, such
>  > > as it is, is best effort, but not blocking. If it breaks, Fedora ships
>  > > with it broken. There are flat out not enough resources to treat it
>  > > with any higher priority than this - it's not a new issue either.
>  >
>  >
>  >
>  > Nonetheless, it is "supported" in Fedora.
>  
>  
>  And now you're using private terminology, and it amounts to denialism
>  and arguing rather than issue progression. It's tedious and makes the
>  conversation as pointless as talking to a wall. 
If anything, you're the one with a weird definition of the term. It's 
supported in Fedora. It's there. Out of box. It seems it's not supported on a 
specific configuration, from what you've provided, but it's supported on the 
vast majority of systems, where that specific configuration is not in use.

>  And likewise there are minimum expectations of reliability for
>  something to be enabled by default, and hibernation does not qualify.
>  https://lists.fedoraproject.org/archives/list/[e-mail]/
>  thread/Q5KQC2SZW42I7ABJGXOZNHQLIBLU5DFO/ 
And yet, it's enabled by default.

>  In the first paragraph you correctly state Secure Boot limits what
>  boots to code that's been signed by Fedora's signing key (or
>  alternatively user keys, if so configured). 
No, I describe it as relying on vendor keys. This is a fundamental flaw in 
Secure Boot.

>  And in the second you describe a means of thwarting Secure Boot by
>  permitting arbitrary code execution, and advocate for this by default, while
>  also questioning the decision making capacity of others. 
Bypassing a flawed system, which was originally designed to limit the 
operating systems that could be installed on hardware. Please do not forget 
the history of "Secure Boot", or it's original intentions.

>  What does encryption have to do with it? Do you think encryption
>  mimics or is akin to code signing? Does it provide error detection or
>  error correction? If you change a single block of encrypted data do
>  you think upon decryption there's EIO or some kind of warning? 
If the swap partition is encrypted, it's not possible to modify it in a manner 
that would compromise security, only in a manner which would make the data 
invalid, and only if using `discard` for that luks container.

>  You're making excuses for an unprivileged process fork bombing a
>  default installation. And you're also changing the goal post by
>  blaming the user. 
If the user chooses to run something, that's up to them. I've given you the 
solution.

>  The topic, set by you, is the assertion that you've never seen a
>  system freeze up when swap size is at least 1x RAM. I have provided a
>  reproducer that contradicts this. And instead of acknowledging that,
>  either at face value or testing it yourself, you proceed with totally
>  off topic distractions that also blame the user. 
That's simply not the case. I explained that what you provided is easily 
mitigated, with proper configuration. It is a non-issue.

>  It's a debate style that is intended to generate more debate
> without
>  conclusion or progression of the issues, and I consider it
>  intellectually dishonest. 
Again, a solution to the problem was provided. If you have an issue with it, 
we can discuss that off-list, or in a new thread specific to that issue. A 
more relevant mailing list for that would be fedora-users, where users 
commonly ask for assistance with configuration.

>  > That's because it is supported. It works out of box, and
> several DEs even
>  > have a button for it. I don't know if GNOME does, but the GNOME Spin has
>  > always been a bit special.
>  
>  
>  More private terminology, as if you think repeating it will make it
>  stick. The difference with my repetition is it's backed by dozens of
>  conversations among various developers and stakeholders in the Fedora
>  community considering it not supported, it isn't me personally
>  asserting a belief or fantasy. 
What are you suggesting is "private terminology", other than "GNOME
Spin"? You 
know that I'm referring to what others call "Workstation", which is a
misnomer 
in my opinion.

It's simply false to say that hibernation is not supported. Not only is it 
supported, there's a big button for it in the major DEs. I have not tested 
GNOME, but I'd be willing to be it's there, unless something has changed with 
the shutdown menu since the version of GNOME 3 used in RHEL 7. Please do let 
me know if GNOME is missing that button in Fedora, so that I may open a 
feature request on behalf of GNOME users in Fedora.

>  It doesn't work out of the box with sufficient consistency or
>  predictability to consider it supported or supportable. You'll find
>  myriad upstream and downstream bug reports about hibernation that
>  languish indefinitely. Some do get fixed. Whether it works depends on
>  make/model, the firmware revision, and kernel version. 
See above. It works out of box. I will take that further to say that it works 
consistently, so long as you don't select a different kernel image to resume. 
On some hardware, you would be correct that hibernation does not work, but 
that is not the case with most systems, and is irrelevant of the degree to 
which Fedora supports it, which is that the option is available for use in the 
major DEs and on the command line.

>  A common theme in the discussion thread I cite earlier in this
> email,
>  is corrupt hibernation images on resume. I have two computers that
>  exhibit this behavior. I do not consider that it works out of the box
>  at all. If I take a very selfish point of view about only my
>  experiences I would say it's 100% broken out of the box. 
I make no claims as to the reliability of hibernation, I cannot test that on 
all hardware. I make no claims to ones ability to even run the Linux kernel on 
all hardware. I don't have enough hardware to test support on a wide variety 
of systems, and I would not claim that it works or does not work based solely 
on the systems that I have available.

>  But being one to recognize the lay of the land is complex, I
> don't
>  take only my own experiences to be the  way of things, like you are.
>  I'm not dismissive of other people's experiences, as you are. I use an
>  inclusive language: it works for some, it doesn't work for others.
>  It's sufficiently unreliable and unpredictable that it cannot
>  reasonably be considered supported or supportable on Fedora without
>  either a lot more resources, or a white list of hardware. 
Well, hold on. I don't either, but I also don't claim that something which is 
clearly supported is not, simply because there is not a release blocker for 
it, an arbitrary criterion. It is supported in Fedora, and that's the extent 
of it. As Fedora contributors, we cannot possibly test all hardware 
configurations, and to create a whitelist of hardware to allow hibernation on 
would be absurd. Perhaps a blacklist, based on user reports, but that's all I 
could suggest there.

>  Your style of debate is grating and can be summarized as: 'I am
> always
>  right and you are always wrong, you should do things my way because
>  you are doing it wrong and everyone doing things differently than I
>  want them is wrong and misguided.' 
I make no claims at being right. You may notice that, in other threads, and at 
certain points in this thread, I have learned something about a part of the 
stack that I don't work with, like UEFI + Secure Boot specific kernel 
limitations. You were the one that brought that to my attention, which has led 
to my writing a note to open a bug report.

Unless I have a solution in mind, or the suggestion of somebody else would 
break either my workflow or the workflow of the users I support, or I view it 
as a breaking change for Fedora's silent majority userbase, I generally don't 
like to pipe in on these things, because people often see those taking issue 
with their suggestions as hostile. That seems to be the case here. I intend no 
hostility, I'm just trying to suggest a better way, that doesn't needlessly 
break things.

>  > The only time it wouldn't work seems to be in one of those
> special UEFI +
>  > Secure Boot cases.
>  
>  
>  It's not special. It happens to be the default firmware and
>  configuration of most new x86_64 hardware, and the default policy upon
>  installation by Fedora. 
That is simply not the case. While most new consumer x86_64 hardware comes 
with UEFI on by default, unless it came with Windows installed, Secure Boot is 
normally disabled.

As for "default policy upon installation by Fedora", what the GNOME Spin 
chooses to do is not the same as what Fedora as a whole does.

>  And that means hibernation is not presently possible by default on
> those
>  systems. 
Simply because somebody decided to disable the feature, as a "security" 
measure.

>  There is no agreement by distributions how to handle hibernation
> image
>  signing that upstream will accept and Fedora isn't likely to carry out of
>  tree patches for such a thing. 
There's no need to sign the hibernation image to
begin with. That is an 
arbitrary requirement that has been thrown in for absolutely no reason that I 
can think of. You're not booting from the hibernation image. It doesn't need 
to be signed to comply with the absurd requirements of "Secure Boot".

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Friday, December 6, 2019 3:22:48 PM MST Chris Murphy wrote:
>  Is it your position that encrypting ~/ alone is not an incremental
>  improvement? Are you suggesting it's necessary to assume Fedora
>  Workstation users are subject to targeted attacks? And therefore
>  install time default must encrypt /, /home, swap? And that this
>  targeted attack, that applies to everyone, does not include targeted
>  attacks on unencrypted /boot or the bootloader for reasons you refuse
>  to elaborate on? And you propose that users should have to opt out of
>  this, rather than opt in? 
There's a lot to unpack here, so let me break this down.

Encrypting $HOME would certainly be "an incremental improvement", but it 
shouldn't be done unless the user chooses to do it, and it probably shouldn't 
be done using the same passphrase they use for their user account. That should 
be up to the user to decide, of course. If they want to use the same 
passphrase, far be it from me to attempt to stop them.

A much better solution would be to push users towards giving full disk 
encryption a try. I'd recommend doing this by a prompt during partitioning 
that has no default option, but is simply a "Yes" or "No" as to
whether or not 
they want it encrypted, when using default automatic partitioning.

/boot should also be encrypted. I have never said otherwise.

I believe I've already answered the question as to "opt out of this, rather 
than opt in", but I'll make that a bit more verbose. I don't believe that 
either should be forced upon the user. It's an important decision, and one 
which should be made by the user, not by somebody else that thinks they know 
best. There are some that argue that more options make the installation 
"harder" or a "worse experience". I'd argue that those people are
understating 
the value of these important options.

>  It's already implemented. There is no encryption by default.
That's not what I was referring to. That was in reference to the use of keys 
stored on a TPM to automatically decrypt the system at boot time.

>  You've set up a false dilemma where the only two valid options
> are do
>  nothing and do what you want. 
I've not said anything which would indicate that to be the case, nor do I 
believe I have all of the answers. I've never stated that there are only two 
valid options. I've only stated that some things which have been suggested are 
not valid options, and I've attempted to provide ideas for potential 
solutions. That's the end goal, collaborative suggestions leading to the best 
potential solution.

>  You reject all intermediate options, dismissing them out of turn
> without any
>  meaningful evaluation. 
Do you have an example of this? I don't believe that's the case. If you're 
referring to systemd-homed, there are a myriad of issues with it, which I and 
others have brought up in this thread and elsewhere.

>  And that's on top of having said you are unconcerned with GNOME
> and don't
>  care about the outcome. If you don't care, why are you still arguing? 
GNOME is not the only desktop environment in Fedora.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Friday, December 6, 2019 5:14:24 PM MST Kevin Kofler wrote:
>  Marius Schwarz wrote:
>  
>  > "Figure out intersection with current work to use the TPM to allow
>  > booting to GDM without entering the password."
>  > 
>  > Means, if someone steals the device, he can boot a system.
>  
>  
>  And conversely, if you move the hard disk to another computer, you can no 
>  longer read it. And if your motherboard breaks down, instant data loss.
>  
>  In addition, I do not trust the TPM or any other Treacherous Computing 
>  component.
>  
>  If you want to rely on a hardware key, it should at least be on a removable
>   USB token (a keyfile on a plain mass-storage USB stick is enough!), not
>  hard-wired into the computer like the TPM. 
Agreed. What many people don't realize is that a TPM isn't some special 
security device. It's essentially a specialized storage device, that only 
stores keys, with a few extensions to use those keys. On many vendors, the TPM 
includes a key that CANNOT BE REMOVED, which belongs to Microsoft or an OEM.


-- 
John M. Harris, Jr.
Splentity

Suspend-to-Disk vs Suspend-to-RAM (was: Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default)

[James Cassell]

(New thread since this is unrelated to the original subject.)

On Fri, Dec 6, 2019, at 9:44 PM, John M. Harris Jr wrote:
>  On Friday, December 6, 2019 11:22:34 AM MST Chris Murphy wrote:
>  > On Fri, Dec 6, 2019 at 7:46 AM John M. Harris Jr <johnmh(a)splentity.com&gt;
>  > wrote: 
[...]
>  It's simply false to say that hibernation is not supported. Not
> only is it 
>  supported, there's a big button for it in the major DEs. I have not tested 
>  GNOME, but I'd be willing to be it's there, unless something has changed with 
>  the shutdown menu since the version of GNOME 3 used in RHEL 7. Please do let 
>  me know if GNOME is missing that button in Fedora, so that I may open a 
>  feature request on behalf of GNOME users in Fedora. 
I couldn't find the hibernate button in Gnome, but I'm still on F29.  Suspend is
unreliable on my system, so I manually type `sudo systemctl hibernate` when I need to put
my laptop in the bag, and it's very reliable in my 2018 ThinkPad.

(Apparently, it's hard to get the button to hibernate w/in Gnome Shell:
https://askubuntu.com/questions/61138/how-can-i-hibernate-from-gnome-shell )


>  > It doesn't work out of the box with sufficient consistency
> or
>  > predictability to consider it supported or supportable. You'll find
>  > myriad upstream and downstream bug reports about hibernation that
>  > languish indefinitely. Some do get fixed. Whether it works depends on
>  > make/model, the firmware revision, and kernel version.
>  
>  See above. It works out of box. I will take that further to say that it works 
>  consistently, so long as you don't select a different kernel image to resume. 
>  On some hardware, you would be correct that hibernation does not work, but 
>  that is not the case with most systems, and is irrelevant of the degree to 
>  which Fedora supports it, which is that the option is available for use in the 
>  major DEs and on the command line. 
My experience is that hibernate is more reliable than suspend.  Just this afternoon, I
performed a suspend-to-ram, and during the 6 or so hours since then, the system dropped
from 51% charge to 11% charge... it seems like something is not being put in its lowest
possible power state.  With hibernate, the system does not drain the battery while not in
active use.

Indeed, the primary hibernate issue I've seen is when a newer kernel has been
installed and I accidentally boot into that one instead of the one that was hibernated...
Seems like this should be easy to fix by having the hibernate process auto-select the
current kernel as default for the next boot.

The other issue is that the machine sometimes does not poweroff on its own upon
hibernation.  This seems to happen when I have or just had an external display attached
prior to hibernation.  I know to make sure the machine is off before putting it in my bag,
and the four-second poweroff works fine in this case.  It always boots up to just where I
left off when I get to my destination.


>  > > The only time it wouldn't work seems to be in one of
> those special UEFI +
>  > > Secure Boot cases.
>  > 
>  > It's not special. It happens to be the default firmware and
>  > configuration of most new x86_64 hardware, and the default policy upon
>  > installation by Fedora.
>  
>  That is simply not the case. While most new consumer x86_64 hardware comes 
>  with UEFI on by default, unless it came with Windows installed, Secure Boot is 
>  normally disabled. 
This reflects my experience.  When buying a Dell tower workstation with RHEL
pre-installed, Secure Boot was turned off in the BIOS out-of-the box.


>  > And that means hibernation is not presently possible by default
> on those
>  > systems.
>  
>  Simply because somebody decided to disable the feature, as a "security" 
>  measure.
>   
Indeed, I did turn off Secure Boot on my ThinkPad where hibernate is rock solid but
suspend quickly drains the battery.


>  > There is no agreement by distributions how to handle hibernation
> image
>  > signing that upstream will accept and Fedora isn't likely to carry out of
>  > tree patches for such a thing.
>  
>  There's no need to sign the hibernation image to begin with. That is an 
>  arbitrary requirement that has been thrown in for absolutely no reason that I 
>  can think of. You're not booting from the hibernation image. It doesn't need 
>  to be signed to comply with the absurd requirements of "Secure Boot".
>   
Disabling hibernation seems like an unreasonable loss of functionality in exchange for
Secure Boot to me.  How hard would it be to standardize on a signature/verification
method?  Is this a signature we could delegate to a TPM?  Is it more palatable to enable
it for MOK-signed kernels/modules, kind of like can be done for proprietary drivers?  (Not
sure if any nVidia distro package does this by MOK-signing by default, though...)


V/r,
James Cassell

[Kevin Kofler]

John M. Harris Jr wrote:
>  That is simply not the case. While most new consumer x86_64 hardware
> comes
>  with UEFI on by default, unless it came with Windows installed, Secure
>  Boot is normally disabled. 
Unfortunately, most hardware out there comes preinfected with Window$.

        Kevin Kofler

[Kevin Kofler]

John M. Harris Jr wrote:
>  On Friday, December 6, 2019 10:05:42 AM MST Przemek Klosowski via
> devel
>  wrote:
> > Many systems have 8, 16 or even 32GB of RAM now. Mine has 16GB, and and
> > I regularly run out of memory because some Chrome tab is open to a
> > website that keeps reloading ads and leaking memory, sometimes consuming
> > gigabytes per tab.
>  
>  I could only suggest not to use proprietary software, such as Chrome. 
I agree, but in this case, I doubt that it will be any better with Falkon 
(which is based on the same code), unless you block the ads (which you can 
also do with the proprietary Chrome, though I guess you need a third-party 
extension there, whereas Falkon supports it out of the box).

That said, I run with 16 GiB RAM and 32 GiB swap and I don't have websites 
eating any swap (with Falkon).

        Kevin Kofler

[David Kaufmann]

On Fri, Dec 06, 2019 at 07:58:07PM -0700, John M. Harris Jr wrote:
>  Encrypting $HOME would certainly be "an incremental
> improvement", but it 
>  shouldn't be done unless the user chooses to do it, and it probably shouldn't 
>  be done using the same passphrase they use for their user account. That should 
>  be up to the user to decide, of course. If they want to use the same 
>  passphrase, far be it from me to attempt to stop them. 
This could be quite dangerous - encrypting $HOME without encrypting the
whole system could lead to a false sense of security - if this is to be
enabled the user should be explicitely warned, that the system will be
unencrypted, if os encryption is not enabled too.

When encrypting both the os and $HOME this could be an improvement, as
this would disallow forcing access to userdata on request (e.g. access
by system administrator without informing users).
Access without user consent would require preparation and system
modification, which is a higher barrier.

Encrypting $HOME only should as far as I can see be enough to comply
with GDPR regulations, but this does only covers device loss, not more
advanced attacks.

All the best,
David

[Przemek Klosowski]

On 12/6/19 7:19 PM, Kevin Kofler wrote:
>  Lennart Poettering wrote:
> > If you know where stuff is located you can change individual blocks in
> > files. You are not going to know what you are changing them to, but
> > you can change it and traditional files will not detect that you did that.
>  Then you get unpredictable garbage as the result, which is useless if your
>  goal (as the attacker) is to plant a trojan horse that steals encrypted data
>  while it is decrypted. (And of course, you cannot directly decrypt the data
>  either.) The only way to exfiltrate the data is to attack the system while
>  it is running (online). 
It's like fuzzing: injecting garbage results in
unintended code paths 
being taken, which is a stepping stone to gaining execution control. Of 
course this happens when the system is started up, so it is a multi-step 
process, but if you include that in your threat model you have to worry 
about it.

[Chris Murphy]

On Mon, Dec 9, 2019 at 1:11 PM Przemek Klosowski via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  On 12/6/19 7:19 PM, Kevin Kofler wrote:
>  > Lennart Poettering wrote:
>  >> If you know where stuff is located you can change individual blocks in
>  >> files. You are not going to know what you are changing them to, but
>  >> you can change it and traditional files will not detect that you did that.
>  > Then you get unpredictable garbage as the result, which is useless if your
>  > goal (as the attacker) is to plant a trojan horse that steals encrypted data
>  > while it is decrypted. (And of course, you cannot directly decrypt the data
>  > either.) The only way to exfiltrate the data is to attack the system while
>  > it is running (online).
>  It's like fuzzing: injecting garbage results in unintended code paths
>  being taken, which is a stepping stone to gaining execution control. Of
>  course this happens when the system is started up, so it is a multi-step
>  process, but if you include that in your threat model you have to worry
>  about it. 
Exactly. Trojans, evil maids, ransomware, floor or fuzz attacks,
they're all totally reasonable things to be concerned about. But the
thing to keep in mind is what is Fedora recommending to most users, by
making it a default? Today we aren't doing any encryption by default.
So the idea that encrypting ~/ alone as a possible next step somehow
translates into meaning we don't care about other possible attack
vectors, or that such setups are somehow less secure, is not
convincing. It really is about prioritizing and balancing out security
with usability.

I'm not sure how people are worried about trojans being injected into
an unencrypted root, while also not at all concerned about bootloader
malware, or malware injected into the initramfs or the hibernation
image - which upon resume replaces everything in RAM in favor of
what's in the image.

The reality of non-Latin character and accessibility support being a
nogo in the initramfs and plymouth almost certainly means no resources
will go toward making that early boot environment more complex. If
anything the developers in this area want that environment simpler,
and reproducible. The alternative, to put a fine point on it, would
mean creating some small subset of the entire GNOME stack to stuff
into the initramfs in order to provide input, keymapping, and UI to
have the minimum a11y function and i18n expectations. That's a tough
sell. And then what of code reuse for other DE's? Right.


-- 
Chris Murphy

[Przemek Klosowski]

On 12/6/19 10:02 PM, John M. Harris Jr wrote:
>  On Friday, December 6, 2019 5:14:24 PM MST Kevin Kofler wrote:
> > Marius Schwarz wrote:
> >
> >> "Figure out intersection with current work to use the TPM to allow
> >> booting to GDM without entering the password."
> >>
> >> Means, if someone steals the device, he can boot a system.
> > And conversely, if you move the hard disk to another computer, you can no
> > longer read it. And if your motherboard breaks down, instant data loss.
> >
> > In addition, I do not trust the TPM or any other Treacherous Computing
> > component.
> >
> > If you want to rely on a hardware key, it should at least be on a removable
> >   USB token (a keyfile on a plain mass-storage USB stick is enough!), not
> > hard-wired into the computer like the TPM.
>  Agreed. What many people don't realize is that a TPM isn't some special
>  security device. It's essentially a specialized storage device, that only
>  stores keys, with a few extensions to use those keys. On many vendors, the TPM
>  includes a key that CANNOT BE REMOVED, which belongs to Microsoft or an OEM. 
I don't see why TPM is seen in such a bad light, as it is just a 
security tool that, in its current implementation, does not prevent 
third-party software like Linux. It has a potential to do that, but, 
like any other tool, can also be used beneficially.

Perhaps people don't have a problem with the TPM concept, but simply 
mistrust black-box TPM implementations?

i am sorry if all this is obvious to everyone, but this is how I 
understand TPM tech. I don't see a problem with the technology as 
described here:

1) TPM is a secure key storage device, designed to release keys only 
under very well specified condition, to prevent stealing of keys via 
physical access/removal of components. For TPM to make sense, it has to 
also secure the boot process, to prevent injection into the boot process 
after the keys are released to the OS; the OS has to boot without 
interruption all the way to the user authentication prompt.

2) TPM is supposed to store multiple keys, and allow adding new keys, as 
well as revoke them. I don't know if the OEM key is exempt from 
revocation on a typical TPM---I didn't think so but I could also see 
that they would prevent revocation for the OEM key, to prevent 
accidental revocation from bricking the system.

3) Multiple keys allow creating backup keys, preventing the data loss 
scenario Kevin is worried about. Of course this assumes that the UX for 
creating backup keys exists, and that people actually do that---but it's 
possible in principle.

[John M. Harris Jr]

On Monday, December 9, 2019 1:42:01 PM MST Chris Murphy wrote:
>  I'm not sure how people are worried about trojans being injected
> into
>  an unencrypted root, while also not at all concerned about bootloader
>  malware, or malware injected into the initramfs or the hibernation
>  image - which upon resume replaces everything in RAM in favor of
>  what's in the image. 
Because, as we've explained, that cannot be done when those are stored on 
encrypted partitions.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Monday, December 9, 2019 1:42:01 PM MST Chris Murphy wrote:
>  The alternative, to put a fine point on it, would
>  mean creating some small subset of the entire GNOME stack to stuff
>  into the initramfs in order to provide input, keymapping, and UI to
>  have the minimum a11y function and i18n expectations. 
You want GNOME in initramfs?! Why? You don't need that, and that'd make it 
more complex for absolutely no reward. It's better, from a UX perspective, to 
simply enter a passphrase using your system-wide keyboard layout, than to have 
to wait for all the bloat that is GNOME to load.

-- 
John M. Harris, Jr.
Splentity

[Chris Murphy]

On Mon, Dec 9, 2019 at 6:33 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Monday, December 9, 2019 1:42:01 PM MST Chris Murphy wrote:
>  > I'm not sure how people are worried about trojans being injected into
>  > an unencrypted root, while also not at all concerned about bootloader
>  > malware, or malware injected into the initramfs or the hibernation
>  > image - which upon resume replaces everything in RAM in favor of
>  > what's in the image.
>
>  Because, as we've explained, that cannot be done when those are stored on
>  encrypted partitions. 
The installer doesn't support such a configuration. No portion of the
bootloader nor the boot volume, can be encrypted.

While the hibernation image could be encrypted, it's not by default.
So where's your pre-existing complaint and feature request that this
should have been enabled by default a long time ago? Why are you only
complaining about things when people have a proposal that doesn't
align with what you want, almost as if you just want to argue for the
sake of arguing?

What's on the table in the near future is encrypting ~/ by default.
And somehow because that's not good enough, in your view, you want to
shitcan encrypting ~/ at all, while waiting for a perfect solution?
How is that even remotely logical?


-- 
Chris Murphy

[Chris Murphy]

On Mon, Dec 9, 2019 at 6:35 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Monday, December 9, 2019 1:42:01 PM MST Chris Murphy wrote:
>  > The alternative, to put a fine point on it, would
>  > mean creating some small subset of the entire GNOME stack to stuff
>  > into the initramfs in order to provide input, keymapping, and UI to
>  > have the minimum a11y function and i18n expectations.
>
>  You want GNOME in initramfs?! Why? 
You have a reading comprehension problem. It is not advocacy. It is an
illustration of the sophisticated environment needed to support the
use cases desired.

> You don't need that, and that'd make it
>  more complex for absolutely no reward. 
You've made abundantly clear that you don't care about other people's
use cases and workflows.

You already stated that you do not care about GNOME. You are so
dismissive, you've even dismissed yourself.

> It's better, from a UX perspective, to
>  simply enter a passphrase using your system-wide keyboard layout, than to have
>  to wait for all the bloat that is GNOME to load. 
By all means keep doing what you are doing, however it works best for
you and the use cases you care about. I do not find your contribution
in this discssion constructive. It's emotional, opinionated,
demanding, stubborn, and lacks facts, diversity, persuasion, and
logic.


-- 
Chris Murphy

[David Kaufmann]

On Mon, Dec 09, 2019 at 09:25:06PM -0700, Chris Murphy wrote:
>  The installer doesn't support such a configuration. No portion of
> the
>  bootloader nor the boot volume, can be encrypted. 
I do consider this a bug, but as there is no stable solution for that
right now we can't just "fix it".

>  While the hibernation image could be encrypted, it's not by
> default.
>  So where's your pre-existing complaint and feature request that this
>  should have been enabled by default a long time ago? Why are you only
>  complaining about things when people have a proposal that doesn't
>  align with what you want, almost as if you just want to argue for the
>  sake of arguing? 
There is no need for a pre-existing complaint - if there is some new
proposal coming up and someone sees a fundamental flaw that does not
automatically make the person pointing that out responsible for fixing
the issue the proposal tries to fix.

A proposed fix for an issue is only good if it fixes more stuff than it
breaks - and the opinions about this seem to diverge for now.

There is always the option "let us just try it and see what happens",
but as it covers a very sensitive area there is a natural tendency to
being more careful about introducing change than usual.

>  What's on the table in the near future is encrypting ~/ by
> default.
>  And somehow because that's not good enough, in your view, you want to
>  shitcan encrypting ~/ at all, while waiting for a perfect solution?
>  How is that even remotely logical? 
This is quite dangerous to do without encryption of the whole disk. That
would break a lot of user expectations if not properly communicated.
If encrypting ~/ also entails full disk encryption that would be okay,
but not separately.
Not meeting user expectations when it comes to security *always* leads
to bad things.

Some examples:

User expects no encryption, as they did not select anything regarding
encryption or did not select full disk encryption:

- Something breaks the system, they try to restore it and now they can't
  access their data anymore.

User does expect encryption, but it's not labelled as encryption for ~/
only - and therefor only ~/ is encrypted:

- User stores data somewhere else than in /home (e.g. sensitive internal
  programs in /opt or /usr/local, secrets/keys/vpn-keys/.. in /etc) ->
  on device loss that user might still think the data is safe anyway, as
  they think it is encrypted

- Attacker scenario: there is physical access to the device for a few
  minutes - installing a trojan is super easy to be done in <10 minutes,
  without the need for any tool, writing the trojan on site.

  Having the full disk encrypted at least moves this to either about
  half an hour to one hour and having a live-usb-stick ready or to
  having a trojan ready anyways.

So please be careful in case this feature gets introduced, as "less than
expected security" is usually worse than "less security". Wording in the
installer is super critical in regard to ~/ only encryption.

All the best,
David

[John M. Harris Jr]

On Tuesday, December 10, 2019 12:24:17 AM MST David Kaufmann wrote:
>  On Mon, Dec 09, 2019 at 09:25:06PM -0700, Chris Murphy wrote:
>  > The installer doesn't support such a configuration. No portion of the
>  > bootloader nor the boot volume, can be encrypted.
>  
>  I do consider this a bug, but as there is no stable solution for that
>  right now we can't just "fix it". 
Actually, as pointed out in this thread, we do have support, just not using 
Anaconda. There is, however, another installer that is available within Fedora 
called Calamares, which does support encrypted /boot. GRUB has full support 
for encrypted /boot as well.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Monday, December 9, 2019 9:50:30 PM MST Chris Murphy wrote:
>  By all means keep doing what you are doing, however it works best
> for
>  you and the use cases you care about. I do not find your contribution
>  in this discssion constructive. It's emotional, opinionated,
>  demanding, stubborn, and lacks facts, diversity, persuasion, and
>  logic. 
Would you rather require that every Fedora installation is re-installed from 
scratch to be able to support a few hundred megabyte initramfs with an entire 
desktop environment shoved into it?

This just doesn't make much sense. How many users do you believe legitimately 
change their system-wide keyboard layout often enough to require that kind of 
infrastructure in a pre-boot environment? If it's less than once an hour, we 
can just rebuild initramfs for their selected keyboard layout. Most users, 
just like most American and UK users, set their keyboard layout to their 
primary layout, and then don't change it, unless it's to try out Dvorak, 
Colemak, or another alternative keyboard layout for a bit, at which point they 
can change their system-wide layout to that and rebuild initramfs.

-- 
John M. Harris, Jr.
Splentity

[Nicolas Mailhot]

Le mardi 10 décembre 2019 à 07:36 -0700, John M. Harris Jr a écrit :
>  Most users, 
>  just like most American and UK users, set their keyboard layout to
>  their primary layout, and then don't change it, 
Actually, most non western users spend their time switching between
several input methods, one for their primary language, the other to
deal with all the latinicisms pushed on them by the ways computers work
today.

American and UK users are the only ones the low-level computer tech has
been designed for. Don’t take them as exemple, they are not
representative.

-- 
Nicolas Mailhot

[Andreas Tunek]

Den tis 10 dec. 2019 kl 15:36 skrev John M. Harris Jr <johnmh(a)splentity.com
> : 
>  Most users, just like most American and UK users, set their keyboard
>  layout to their
>  primary layout, and then don't change it, unless it's to try out Dvorak,
>  Colemak, or another alternative keyboard layout for a bit, at which point
>  they
>  can change their system-wide layout to that and rebuild initramfs.
>
>  
Do you have any data to back these statements up? They seem to go counter
to what I have experienced.

/Andreas



>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Kevin Fenzi]

So, this thread is now 175 posts long... 

The Orig change proposal has been rejected by FESCo. 

Perhaps we should just let this thread go now?

kevin

[Kevin Kofler]

Przemek Klosowski via devel wrote:
>  3) Multiple keys allow creating backup keys, preventing the data
> loss
>  scenario Kevin is worried about. Of course this assumes that the UX for
>  creating backup keys exists, and that people actually do that---but it's
>  possible in principle. 
The backup key is useless in that scenario if you cannot export it to 
another TPM, and isn't preventing such an export the whole point of the TPM 
technology?

        Kevin Kofler

[Kevin Kofler]

Chris Murphy wrote:
>  I'm not sure how people are worried about trojans being injected
> into
>  an unencrypted root, while also not at all concerned about bootloader
>  malware, or malware injected into the initramfs or the hibernation
>  image - which upon resume replaces everything in RAM in favor of
>  what's in the image. 
The bootloader itself getting attacked is a concern, but for the initramfs, 
encrypting /boot is actually a solved problem, Anaconda just needs to 
support it. (That said, it means that you have to type the passphrase into 
GRUB, so you are stuck with its limited input capabilities.)

>  The alternative, to put a fine point on it, would mean creating some
> small
>  subset of the entire GNOME stack to stuff into the initramfs in order to
>  provide input, keymapping, and UI to have the minimum a11y function and
>  i18n expectations. That's a tough sell. 
IMHO, Qt for the LinuxFB (fbdev) or EGLFS (if you really need OpenGL) 
platform would be a much better fit for this purpose than the GNOME stack, 
if you really think we cannot do without the convenience of a GUI toolkit 
for a passphrase prompt on bootup. (That said, this approach precludes 
encrypting /boot, unfortunately.)

        Kevin Kofler

[Przemek Klosowski]

On 12/10/19 1:04 PM, Kevin Kofler wrote:
>  Przemek Klosowski via devel wrote:
> > 3) Multiple keys allow creating backup keys, preventing the data loss
> > scenario Kevin is worried about. Of course this assumes that the UX for
> > creating backup keys exists, and that people actually do that---but it's
> > possible in principle.
>  The backup key is useless in that scenario if you cannot export it to
>  another TPM, and isn't preventing such an export the whole point of the TPM
>  technology? 
Of course, the primary private key cannot be extracted from the original 
TPM. The easiest key recovery scheme would have two encrypted copies of 
the media encryption keys, one encrypted with the TPM-secured key and 
another encrypted with the backup/recovery key that you keep in a 
separate 'enterprise' key backup system. Here's one paper describing TPM 
key backup/recovery:

https://www.infineon.com/dgdl/Infineon-TPM_Key_Backup_and_Recovery-AP-v01...

>           Kevin Kofler
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
> https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fe...
>  List Guidelines:
> https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
>  List Archives:
> https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...

Suspend-to-Disk vs Suspend-to-RAM

[Gordon Messmer]

On 12/6/19 10:49 PM, James Cassell wrote:
>  I performed a suspend-to-ram, and during the 6 or so hours since
> then, 
>  the system dropped from 51% charge to 11% charge... it seems like 
>  something is not being put in its lowest possible power state. With 
>  hibernate, the system does not drain the battery while not in active use.  

Check /sys/power/mem_sleep to see which suspend mode is being used.  I 
suspect it will be s2idle, which resumes more quickly but costs more 
power during suspend.  I have read that the default value is taken from 
firmware settings, and reflects the preference of the OEM, but I'm not 
sure how you'd verify that.  In any case, on my Dell laptop, I set 
"mem_sleep_default=deep" as a boot parameter for better battery life 
during suspend.

[John M. Harris Jr]

On Tuesday, December 10, 2019 10:53:39 AM MST Andreas Tunek wrote:
>  Den tis 10 dec. 2019 kl 15:36 skrev John M. Harris Jr
> <johnmh(a)splentity.com
>  
>  > Most users, just like most American and UK users, set their keyboard
>  > layout to their
>  > primary layout, and then don't change it, unless it's to try out Dvorak,
>  > Colemak, or another alternative keyboard layout for a bit, at which point
>  > they
>  > can change their system-wide layout to that and rebuild initramfs.
>  
>  Do you have any data to back these statements up? They seem to go counter
>  to what I have experienced. 
This was just my experience from $WORK, were I support en_US, en_GB and de_DE.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Tuesday, December 10, 2019 12:05:52 PM MST Przemek Klosowski via devel 
wrote:
>  On 12/10/19 1:04 PM, Kevin Kofler wrote:
>  
>  > Przemek Klosowski via devel wrote:
>  > 
>  >> 3) Multiple keys allow creating backup keys, preventing the data loss
>  >> scenario Kevin is worried about. Of course this assumes that the UX for
>  >> creating backup keys exists, and that people actually do that---but it's
>  >> possible in principle.
>  > 
>  > The backup key is useless in that scenario if you cannot export it to
>  > another TPM, and isn't preventing such an export the whole point of the
>  > TPM technology?
>  
>  
>  Of course, the primary private key cannot be extracted from the original 
>  TPM. The easiest key recovery scheme would have two encrypted copies of 
>  the media encryption keys, one encrypted with the TPM-secured key and 
>  another encrypted with the backup/recovery key that you keep in a 
>  separate 'enterprise' key backup system. Here's one paper describing TPM 
>  key backup/recovery:
>  
>  https://www.infineon.com/dgdl/Infineon-TPM_Key_Backup_and_Recovery-AP-v01_00
>  -EN.pdf?fileId=db3a304412b407950112b41656d7203a 
To clarify a bit, the most common method of extracting a key from a TPM has 
been to simply desolder the TPM from the system and solder it onto another 
system. This works with the popular implementations.

-- 
John M. Harris, Jr.
Splentity

[Kevin Kofler]

John M. Harris Jr wrote:
>  To clarify a bit, the most common method of extracting a key from a
> TPM
>  has been to simply desolder the TPM from the system and solder it onto
>  another system. This works with the popular implementations. 
Surely that is not a process that you want to advertise to end users!

I stay by what I wrote: a TPM, or anything with the same security model, is 
not an acceptable place for a LUKS key token. Either use a plain keyfile on 
a removable USB mass storage stick, or if that does not provide acceptable 
security in your setup, find another solution (such as a passphrase).

        Kevin Kofler

[Marius Schwarz]

Am 06.12.19 um 17:33 schrieb John M. Harris Jr:
> > But plymouth ui needs to be changed anyway to get a working OSK,
> or
> > tablets and mobiles are not be able to use encryption.
>  What you're asking for would be incredibly difficult. It could be done, but 
>  not with Plymouth, and not without increasing the size of initramfs by several 
>  10s of not 100s of MB. Right now, Plymouth doesn't handle input. Well, it 
>  does, but not most things. It's actually the underlying vtty that handles 
>  input of the passphrase.
>  
You mean, that when plymouth comes on, there is no real UI system that
could handle mouse events, which are needed
to simulate a osk. But that can't honestly be so much hassle, as we
don't need a full featured mouse handler, a simple one would be enough:
leftclick, mouse move thats it.

A font to render all the possible keyboardlayouts will take much more
space and should be limited to the one the system uses+ a default one
with "most used language" support.

M$ has added a simple OSK on boot in it's bios, so you  can select
things in touchmode before the real os is running. Not very shiny, not
perfect, but there if needed. A little bit better should "our" system
be, but i don't expect complains, if it isn't a super smooth running
system with cutting edge graphics ;)

On the other hand, as android is capable of FDE, they must have made
some importanted changes that can be of use here.

Best regards,
Marius

[Marius Schwarz]

Am 06.12.19 um 17:40 schrieb John M. Harris Jr:
> > If the vm is paravirtualized ( i.e. Xen ) you can't even enter a
> > plymouth password to unlock a drive.
>  Well, you can. Why wouldn't you be able to? 
because I already tried it ;) it's a tty problem with high secure ttys,
hvcsomething. Thats the only one, the system accepts input from at
start, but with QEMU that tty isn't present. Adding the normal ttys to
the trusted list of ttys did not fix the issue. I had a br running years
ago, but it got never solved afaik.

Maybe i should try again, as the last test was approx. 5 years ago.

>  Well, VMs are not generally stored on the drive of the host OS,
> except in one-
>  offs and on consumer desktops/laptops. 
If you have an offhost storage, as mass storage at a cloudhoster would
be, the transport from the storage to the host needs to be secured too,
which i don't think it is. So i don't think we need to even consider VMs
to be encryptable, as securing the entire path is very tough and out of
our league.


> > decrypt the disk."
> >
> > Add: grub needs an OSK too, or how do you select the matching kernel?
>  Adding an on-screen keyboard to GRUB would be even more difficult than adding 
>  it to the initramfs environment. GRUB simply cannot support that. It'd have to 
>  be rewritten from the ground up to support that sort of thing. 
Android did it and M$ helped out with a "on-boot-without-os" OSK in it's
surface bios.

I guess it's time, to take some stuff back from android to mainstream
linux ;)

> > Skipping the rest of it, the simple solution to the problem
> discussed
> > would be to ask for encryption more prominent, with a tiny bit of
> > background for the user.
> >
> > Before i forget, there can be multiply passwords for a luks key, so
> > there is no need to wipe a disk, just have a good OSK with all installed
> > and or system selected languages at hand.
>  Are you suggesting "translating", for lack of a better term, the passphrase 
>  between all available keyboard layouts? That would decrease the effective 
>  security of your system considerably.. 
No, i mean, there can be two different
passcodes for the same key. Luks
offers 10 slots for them.
On can be plain ascii as it's now, the other one can be the one the
system had been installed with.

See it as a "Reserve- or Backuppassword", but in no way it should be a
none-interactive password aka controlled by the installer. We don't need
backdoors.

Best regards,
Marius

[Marius Schwarz]

Am 06.12.19 um 23:22 schrieb Chris Murphy:
>  Is it your position that encrypting ~/ alone is not an incremental
>  improvement? Are you suggesting it's necessary to assume Fedora
>  Workstation users are subject to targeted attacks? And therefore
>  install time default must encrypt /, /home, swap? And that this
>  targeted attack, that applies to everyone, does not include targeted
>  attacks on unencrypted /boot or the bootloader for reasons you refuse
>  to elaborate on? And you propose that users should have to opt out of
>  this, rather than opt in? 
If the drive stays stolen, it does no longer matter if the entire system
got changed or not, you never will see your drive again anyway.

But, in the case your laptop is running, and an attacker can manipulate
the os, the moment you relogin, you lost everything.
That would not happen, if the drive is powered down, as the os is
untamperable in that moment.

/boot,bootloader and bios can be removed, by swapping the hw the drive
resides in. As the owner of a device, you will know if someone did it
when you where on the toilet ;) and to make it that hard to trick
someone, /boot, bios and bootloader should also be protected :) That
forces the attacker to use a level of effort, it's easier to just shoot
you while the drive is unlocked.


best regards,
Marius

[Marius Schwarz]

Am 07.12.19 um 01:09 schrieb Kevin Kofler:
>  Anaconda should encrypt /boot too. Calamares does it. GRUB supports it
>  
FULL ACK.

Marius

[Marius Schwarz]

Am 06.12.19 um 21:04 schrieb Chris Murphy:
>  swap being compromised. Case 2 is present day Fedora "full disk
>  encryption" which does not lock down the bootloader,  /boot volume is
>  not encrypted, and thus the initramfs is vulnerable to a targeted
>  attack which could be used to deploy a key logger or whatever you're
>  worried about in Case 1. 
Not encrypting /boot may be the default in the installer, but does not
mean, you can't go the full way.

You can simply activate /boot/ encryption. Grub will ask you for your
luks password while booting.

But pls see the other message, I won't repeat myself. But your right, It
really depends on the threadmodel you wanne counter.

My point is, make it as hard as possible, otherwise you way just think,
your safe, when your not.

sincerly,
Marius

[Simo Sorce]

On Thu, 2019-12-12 at 03:09 +0100, Kevin Kofler wrote:
>  John M. Harris Jr wrote:
>  > To clarify a bit, the most common method of extracting a key from a TPM
>  > has been to simply desolder the TPM from the system and solder it onto
>  > another system. This works with the popular implementations.
>  
>  Surely that is not a process that you want to advertise to end users!
>  
>  I stay by what I wrote: a TPM, or anything with the same security model, is 
>  not an acceptable place for a LUKS key token. 
This is far from the original topic, but you make a baseless claim.

Like any other security feature, it's successful (or not) use depends
on the threat model and the sue you make of it.

If you want to make sure that the hard drive *cannot* be use by
plugging it into any random computer using a TPM chip with LUKs is
absolutely a good idea.

Of course if you do not make external backups then having a backup key
add to LUKS that you store offline is definitely a good idea for
recovery in case your TPM chip becomes unavailable for whatever reason.

>   Either use a plain keyfile on 
>  a removable USB mass storage stick, or if that does not provide acceptable 
>  security in your setup, find another solution (such as a passphrase). 
You are making a blanket statement about the security of a solution
without any analysis of the requirements, uniquely on a personal and
arbitrary distaste for a technology, that is not really useful, please
refrain.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

[Przemek Klosowski]

On 12/12/19 6:56 AM, Marius Schwarz wrote:
>  On the other hand, as android is capable of FDE, they must have made
>  some importanted changes that can be of use here. 
Right, because Android has full control of the entire boot process, so 
they only need the user input  at the end where all the moving pieces 
are in place. I think bulletproofing the boot process is the right 
approach for Linux as well---but it's hard because the PC platform 
interface between the firmware (BIOS/UEFI)  and the OS is brittle, 
variable and poorly defined---and if you really lock it up, inevitably 
someone will get locked out from repairing their system.

Note that ~/ encryption is actually a nice compromise: the boot/OS 
environment needs integrity more than confidentiality, and maybe could 
be more maintainable if left unencrypted, while the $HOME would be kept 
encrypted and confidential.

If you can't rely on an uninterruptible boot, you need I18n support 
early on, and there are only two possibllities: either use whatever the 
platform firmware provides (I think that's what you refer when you talk 
about MS OSK BIOS support), or you arrange for the OS i18n support to be 
available early enough. The reality of the PC platform is that in 
general we can't rely on the BIOS support.

[John M. Harris Jr]

On Thursday, December 12, 2019 4:56:04 AM MST Marius Schwarz wrote:
>  You mean, that when plymouth comes on, there is no real UI system
> that
>  could handle mouse events, which are needed
>  to simulate a osk. But that can't honestly be so much hassle, as we
>  don't need a full featured mouse handler, a simple one would be enough:
>  leftclick, mouse move thats it. 
There is no subsystem for anything like that. Most input at Plymouth is 
handled by the vtty, not Plymouth itself.

>  A font to render all the possible keyboardlayouts will take much
> more
>  space and should be limited to the one the system uses+ a default one
>  with "most used language" support. 
This would be an issue even with the concept below. File sizes for initramfs 
would definitely grow, perhaps too much to handle on lower-end systems. It'd 
definitely need to be optional, and only on systems that are getting a 
graphical install.

>  M$ has added a simple OSK on boot in it's bios, so you  can
> select
>  things in touchmode before the real os is running. Not very shiny, not
>  perfect, but there if needed. A little bit better should "our" system
>  be, but i don't expect complains, if it isn't a super smooth running
>  system with cutting edge graphics ;) 
Where have you seen this? I haven't seen this on any of Dell's recent 
touchscreen laptops with the latest Windows 10 nor Windows 10 Enterprise. This 
may be provided by the device vendor or OEM, rather than Microsoft.

>  On the other hand, as android is capable of FDE, they must have made
>  some importanted changes that can be of use here. 
Does Android use Plymouth? Last I checked, they did not. I'm not saying that 
we can't implement this, it's possible, but not with Plymouth.

The way to do it would be to pick the smallest of the graphical toolkits, Qt 
vs GTK+. Considering embedded environments are a target for Qt, I'd wager Qt 
would be the best option for this, as it doesn't require X11 or Wayland. Then 
throw together a little graphical app for that, if such a thing is really 
needed.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Thursday, December 12, 2019 6:04:55 AM MST Marius Schwarz wrote:
>  because I already tried it ;) it's a tty problem with high secure
> ttys,
>  hvcsomething. Thats the only one, the system accepts input from at
>  start, but with QEMU that tty isn't present. Adding the normal ttys to
>  the trusted list of ttys did not fix the issue. I had a br running years
>  ago, but it got never solved afaik.
>  
>  Maybe i should try again, as the last test was approx. 5 years ago. 
I'd have to take a look at a test system, I'm running a Xen setup with CentOS 
7 DOM0, have no issues with Plymouth on other domains.

>  If you have an offhost storage, as mass storage at a cloudhoster
> would
>  be, the transport from the storage to the host needs to be secured too,
>  which i don't think it is. So i don't think we need to even consider VMs
>  to be encryptable, as securing the entire path is very tough and out of
>  our league. 
Well, luckily, that's not necessary. VMs have a lot of issues when it comes to 
security, but using LUKS is sufficient on a drive or partition, as no 
unecrypted data would go across the SAN. It's just what would be written to 
disk. Well, if you're using a block device from SAN, that is. I'm not 
accounting for NFS here, which can be secured using NFSv4.

>  > Are you suggesting "translating", for lack of a better
> term, the
>  > passphrase  between all available keyboard layouts? That would decrease
>  > the effective security of your system considerably..
>  
>  No, i mean, there can be two different passcodes for the same key. Luks
>  offers 10 slots for them.
>  On can be plain ascii as it's now, the other one can be the one the
>  system had been installed with.
>  
>  See it as a "Reserve- or Backuppassword", but in no way it should be a
>  none-interactive password aka controlled by the installer. We don't need
>  backdoors. 
Ah, gotcha! That's a neat idea. I like it. That'd be a very nice way to handle 
it, potentially with an option in the installer to export that to a removable 
device for safe-keeping.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Thursday, December 12, 2019 6:54:38 AM MST Marius Schwarz wrote:
>  Am 06.12.19 um 21:04 schrieb Chris Murphy:
>  
>  > swap being compromised. Case 2 is present day Fedora "full disk
>  > encryption" which does not lock down the bootloader,  /boot volume is
>  > not encrypted, and thus the initramfs is vulnerable to a targeted
>  > attack which could be used to deploy a key logger or whatever you're
>  > worried about in Case 1.
>  
>  
>  Not encrypting /boot may be the default in the installer, but does not
>  mean, you can't go the full way.
>  
>  You can simply activate /boot/ encryption. Grub will ask you for your
>  luks password while booting.
>  
>  But pls see the other message, I won't repeat myself. But your right, It
>  really depends on the threadmodel you wanne counter.
>  
>  My point is, make it as hard as possible, otherwise you way just think,
>  your safe, when your not. 
Actually, it turns out you can accomplish this with blivet-gui in the current 
Anaconda ISOs, so current images do actually offer the option for real FDE.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Wednesday, December 11, 2019 7:09:41 PM MST Kevin Kofler wrote:
>  John M. Harris Jr wrote:
>  
>  > To clarify a bit, the most common method of extracting a key from a TPM
>  > has been to simply desolder the TPM from the system and solder it onto
>  > another system. This works with the popular implementations.
>  
>  
>  Surely that is not a process that you want to advertise to end users! 
Of course not. It's just an example of the most common way to get around the 
TPM holding the keys.

>  I stay by what I wrote: a TPM, or anything with the same security
> model, is
>   not an acceptable place for a LUKS key token. Either use a plain keyfile
>  on a removable USB mass storage stick, or if that does not provide
>  acceptable security in your setup, find another solution (such as a
>  passphrase).  
Agreed, as it's simply susceptible to attack at too many levels.

-- 
John M. Harris, Jr.
Splentity