subject:"Re\: Fedora 32 System\-Wide Change proposal\: Disallow Empty Password By Default"

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-12 Thread Przemek Klosowski via devel


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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-12 Thread 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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

FULL ACK.

Marius
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-11 Thread 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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  
> > 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-10 Thread Przemek Klosowski via devel


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



 Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=02%7C01%7Cprzemek.klosowski%40nist.gov%7C0133d99d248a4045337e08d77d9b8251%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637115979168313120sdata=6VVp5O2EJMhkeno925pm4C5L1Pg7B0QwFBmswkpxNRo%3Dreserved=0
List Guidelines: 
https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=02%7C01%7Cprzemek.klosowski%40nist.gov%7C0133d99d248a4045337e08d77d9b8251%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637115979168313120sdata=q2LQbyjb%2BhFHarqGyNt0RD7EYr7654XS3lhpgNJ66gw%3Dreserved=0
List Archives: 
https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedoraproject.org%2Farchives%2Flist%2Fdevel%40lists.fedoraproject.orgdata=02%7C01%7Cprzemek.klosowski%40nist.gov%7C0133d99d248a4045337e08d77d9b8251%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637115979168323115sdata=RzErc5fsj71PqLBXvizU%2BuBH54KyyionG%2B9f1IB%2FsLU%3Dreserved=0


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-10 Thread 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-10 Thread 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-10 Thread 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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-10 Thread Andreas Tunek

Den tis 10 dec. 2019 kl 15:36 skrev John M. Harris Jr :

> 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-10 Thread Nicolas Mailhot via devel

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-09 Thread 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

signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-09 Thread Chris Murphy

On Mon, Dec 9, 2019 at 6:35 PM John M. Harris Jr  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-09 Thread Chris Murphy

On Mon, Dec 9, 2019 at 6:33 PM John M. Harris Jr  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-09 Thread 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-09 Thread 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-09 Thread Przemek Klosowski via devel


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.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-09 Thread Chris Murphy

On Mon, Dec 9, 2019 at 1:11 PM Przemek Klosowski via devel
 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-09 Thread Przemek Klosowski via devel


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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-07 Thread 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

signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-07 Thread 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-07 Thread 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-06 Thread 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 
> > 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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 
> 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/devel@lists.fedoraproject.org/
> 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,

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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/msg0.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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-06 Thread Chris Murphy

On Fri, Dec 6, 2019 at 9:41 AM John M. Harris Jr  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-06 Thread Przemek Klosowski via devel


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.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-06 Thread Chris Murphy

On Fri, Dec 6, 2019 at 8:28 AM 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:

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-06 Thread Lennart Poettering

On Fr, 06.12.19 18:58, Lata Lante (latala...@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/?id=f60c55a94e1d127186566f06294f2dadd966e9b4

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-06 Thread 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/?id=f60c55a94e1d127186566f06294f2dadd966e9b4
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-06 Thread Chris Murphy

On Fri, Dec 6, 2019 at 7:46 AM John M. Harris Jr  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/devel@lists.fedoraproject.org/thread/Q5KQC2SZW42I7ABJGXOZNHQLIBLU5DFO/

>
> > 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

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

2019-12-06 Thread Lennart Poettering

On Fr, 06.12.19 16:42, Marius Schwarz (fedora...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-06 Thread 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-06 Thread Przemek Klosowski via devel

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.io%2Ffedora-workstation%2Fissue%2F98data=02%7C01%7Cprzemek.klosowski%40nist.gov%7C3d5d788008a44389a37608d779ddc820%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637111865776892532sdata=cBuSZsTyR6EIHF0y45%2B6cLbHiHH%2FgQm0rIdFxSjdGio%3Dreserved=0

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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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,  > 
> > > 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

On Friday, December 6, 2019 1:02:04 AM MST Lennart Poettering wrote:
> On Do, 05.12.19 16:33, John M. Harris Jr (joh...@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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

Am 05.12.19 um 21:21 schrieb Andreas Tunek:
> On Thu, 5 Dec 2019, 02:11 John M. Harris Jr,  > 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-06 Thread Nico Kadel-Garcia

On Fri, Dec 6, 2019 at 3:02 AM Lennart Poettering  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-06 Thread Lennart Poettering

On Do, 05.12.19 16:33, John M. Harris Jr (joh...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

On Fr, 06.12.19 00:39, Kevin Kofler (kevin.kof...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-05 Thread Nico Kadel-Garcia

On Thu, Dec 5, 2019 at 9:02 AM John M. Harris Jr  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

On Thu, Dec 5, 2019 at 6:40 PM John M. Harris Jr  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.00] 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

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

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 
> 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

On Thu, Dec 5, 2019 at 4:49 PM John M. Harris Jr  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/ker...@lists.fedoraproject.org/message/TLTA6HAYJWQYHV3ZHFXUIXM4IJVWBEJJ/

> > 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/devel@lists.fedoraproject.org/message/XUZLHJ5O32OX24LG44R7UZ2TMN6NY47N/

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

On Thursday, December 5, 2019 3:02:48 PM MST Chris Murphy wrote:
> On Thu, Dec 5, 2019 at 4:03 AM Marius Schwarz 
> 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-05 Thread 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

On Thu, Dec 5, 2019 at 4:03 AM Marius Schwarz  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

On Thu, Dec 5, 2019 at 5:07 AM 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.

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

On Thu, Dec 5, 2019 at 8:57 AM Marius Schwarz  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-05 Thread Andreas Tunek

On Thu, 5 Dec 2019, 02:11 John M. Harris Jr,  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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

On Thu, Dec 5, 2019 at 8:04 AM Lennart Poettering  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-05 Thread 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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-05 Thread Przemek Klosowski via devel


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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-05 Thread 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



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

On Do, 05.12.19 15:23, Kevin Kofler (kevin.kof...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-05 Thread 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-05 Thread 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-05 Thread Neal Gompa

On Thu, Dec 5, 2019 at 9:02 AM John M. Harris Jr  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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 
> 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

On Thursday, December 5, 2019 5:35:09 AM MST Lennart Poettering wrote:
> On Do, 05.12.19 04:30, John M. Harris Jr (joh...@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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-05 Thread Nico Kadel-Garcia

On Wed, Dec 4, 2019 at 9:24 PM John M. Harris Jr  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

2019-12-05 Thread Nico Kadel-Garcia

On Wed, Dec 4, 2019 at 6:01 AM Lennart Poettering  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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

On Do, 05.12.19 04:30, John M. Harris Jr (joh...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

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