desktop December 2018

desktop@lists.fedoraproject.org

15 participants
8 discussions

Any feedback about howdy
by Luya Tshimbalanga 24 Jan '19

24 Jan '19

I recently packaged[1] an application named howdy[2], a bionic facial authentication similar to Windows Hello. Laptop like HP Envy x360 have an Intel RealSense Depth Camera[3] which are currently restricted on 640x480 resolution when running on Fedora 29 using amdgpu in my case. Will it possible to integrate on the workstation with some improvement? Reference -------------- [1]https://copr.fedorainfracloud.org/coprs/luya/howdy/ [2]https://github.com/boltgolt/howdy [3]https://www.windowscentral.com/complete-list-laptops-support-windows-hello Luya

3 4

[Fedocal] Reminder meeting : Workstation WG
by stickster＠gmail.com 29 Dec '18

29 Dec '18

Dear all, You are kindly invited to the meeting: Workstation WG on 2018-12-31 from 09:00:00 to 10:00:00 America/New_York At fedora-meeting-2(a)irc.freenode.net The meeting will be about: Regular meeting for the Workstation Working Group. Agenda: https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting Chair: * Dec 03 - Michael Catanzaro * Dec 17 - Matthias Clasen * Jan 14 - Rex Dieter * Jan 28 - (devconf) * Feb 11 - Paul Frields * Feb 25 - Kalev Lember * Mar 11 - Ryan Lerch * Mar 25 - Jens Petersen * Apr 08 - Christian Schaller * Apr 22 - Owen Taylor More information available at: https://fedoraproject.org/wiki/Workstation Source: https://apps.fedoraproject.org/calendar/meeting/6411/

1 0

wg meeting logs for December 17
by Matthias Clasen 17 Dec '18

17 Dec '18

https://meetbot.fedoraproject.org/fedora-meeting-2/2018-12-17/workstation.2…

1 0

[Fedocal] Reminder meeting : Workstation WG
by stickster＠gmail.com 15 Dec '18

15 Dec '18

Dear all, You are kindly invited to the meeting: Workstation WG on 2018-12-17 from 09:00:00 to 10:00:00 America/New_York At fedora-meeting-2(a)irc.freenode.net The meeting will be about: Regular meeting for the Workstation Working Group. Agenda: https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting Chair: * Dec 03 - Michael Catanzaro * Dec 17 - Matthias Clasen * Jan 14 - Rex Dieter * Jan 28 - (devconf) * Feb 11 - Paul Frields * Feb 25 - Kalev Lember * Mar 11 - Ryan Lerch * Mar 25 - Jens Petersen * Apr 08 - Christian Schaller * Apr 22 - Owen Taylor More information available at: https://fedoraproject.org/wiki/Workstation Source: https://apps.fedoraproject.org/calendar/meeting/6411/

1 0

Re: encryption, partitioning, was: Workstation WG meeting recap 2018-Dec-03
by Chris Murphy 11 Dec '18

11 Dec '18

On Thu, Dec 6, 2018 at 3:13 AM Javier Martinez Canillas <javierm(a)redhat.com> wrote: > > On 05-12-18 23:58, Chris Murphy wrote: > >> b. Windows laptops have TPM 2.0 which I can't get to work on Linux > >> (works fine on Windows 10). > >> https://bugzilla.kernel.org/show_bug.cgi?id=185631 > This seems to be a driver issue. Bugzilla usually is not the best channel to > report kernel issues but instead the subsystem mailing list. For TPM this is > linux-integrity(a)vger.kernel.org. Could you please post your issue there? Yes. > > >> c. Can a TMP be reliably shared by both Windows and Fedora in a dual > >> boot configuration? > > > > Javier, Peter, can you answer this please ? > > > > This is a two part question I think. First is the measurements and since the > BitLocker seals against a PCR state when booting with the Windows bootloader > this means that we can't chain-load Windows from grub2 since the measurements > would be different and prevent BitLocker to unlock the encrypted disk. > > So for this case Windows has to be booted using the EFI firmware and having a > separate boot entry. This is my understanding at least, I don't have a Windows > installation to test. > > The second part is the key management. Clevis currently expects that the key > hierarchies are not password protected. This is because asking the user for a > password would defeat the purpose of automatically unlocking the LUKS volume. Why bother encrypting anything if it's going to be automatically unlocked just by booting? If the login window is a sufficient barrier to exfiltrating and modifying user files on an unlocked volume, then it's a sufficient barrier for an unencrypted volume because it is in effect a plaintext volume, automatically without a passphrase, merely when powered on. > Also fscrypt is only supported by ext4, right? It would be better fo find a > solution that wouldn't impose a specific filesystem to the user. fscrypt is today supported by ext4, f2fs, and UBIFS. There are plans to support XFS and Btrfs but I have no idea what their time frames are, reflinks and snapshots add complications. -- Chris Murphy

5 8

Re: encryption, partitioning, was: Workstation WG meeting recap 2018-Dec-03
by Hans de Goede 10 Dec '18

10 Dec '18

Hi, On 06-12-18 11:04, Javier Martinez Canillas wrote: > Hello, > > On 12/5/18 9:20 PM, Hans de Goede wrote: > > [snip] > >> >> Javier and Peter (added to the Cc) have been working on making >> full-disk encryption storing the secret in the tpm work. >> >> This is what Windows with bitlocker does and what most smart phones >> do now (more or less). >> > > Yes. The clevis project has TPM2 support since Fedora 28, so you can bind > a LUKS volume to a TPM2 and it will automatically be unlocked on boot but > only on that machine. > >> The idea here is (Javier / Peter please correct me if I'm wrong) that >> the firmware send a hash of itself to the tpm and a hash of the bootloader, >> and the bootloader sends a hash of the kernel + initrd to the tpm. >> >> The tpm hashes all these hashes together and when the kernel wants to >> access the encrypted root filesystem, it asks the tpm for the key, >> if all the hashes together match what the tpm expects it will give >> the key. This means that even if someone steals the entire laptop >> he cannot modify anything, the rootfs is crypted so it cannot be >> modified without the key and everything which comes before it is >> hashed so it cannot be replaced either. This leaves the attacker >> essentially stuck at the gdm login prompt. An advanced adversary >> will certainly be able to find a way around this, but it is a good >> level of security to start with. >> >> This gives us full disk encryption without the need to ask for a >> diskcrypt password from plymouth (in the initrd) or from grub at all. >> Thus avoiding all downsides wrt keymaps and the lack of other advanced >> input methods like having e.g. a pinyin input method. This also avoids >> other internationalization issues like font-rendering of non western >> scripts. >> > > This is correct, but we still don't have all the needed pieces. Both shim > and grub2 currently measures all the components in the boot path: Secure > Boot configuration, all certificates from the cert databases, shim, grub2 > binaries, grub commands executed, kernel, kernel cmdline and the initrd. > > What we are missing is a robust mechanism to to re-seal the LUKS key every > time that one of these components is updated. If this process is fragile, > you may end with an unbootable system (you always have the pass-phrase as > fallback though). > > Until we have a way to re-seal the secrets, binding to a TPM will make the > system less secure since it means that an attacker could just replace the > initramfs or your kernel cmdline an unlock your encrypted disk easily. > > It's useful though for other use cases like VM or servers. > > Also, the measurements will change if you boot different kernels so it has > to support multiple valid PCR states. We could for example have a different > LUKS key sealed against different PCR sates for each kernel. But that means > a maximum of 7 as Chris pointed out (since slot 0 will be the fallback key). > > My understanding is that even Windows doesn't do this, but instead what they > do is to seal the KEK only against PCR7 that contains the Secure Boot policy: > > https://docs.microsoft.com/en-us/previous-versions/windows/hardware/hck/jj9… > > So basically what they do is to combine TPM measurements with Secure Boot to > make sure that your encrypted disk is only decrypted if all the binaries are > signed. > > We could also do the same but the problem is the initramfs. My guess is that > Windows doesn't have that limitation and their plain text boot partition has > everything that's needed to decrypt the root partition. So they can just sign > the kernel and drivers to make sure that the system has not been tamper with. Hmm, so if we sign the initramfs and make grub or the kernel check this, then we could do what Windows does without the re-sealing issue, right? We've discussed moving to an initramfs which is pre-generated on the buildsystem in the past, if we do a separate initramfs for network boots, then this will actually not grow the initrams all that much (*) and this would allow signing the initramfs. To me this sounds like a saner path then trying to hash all boot path components and re-seal all the time. One thing which would still be an issue with this is the kernel commandline. But the kernel commandline does not change on kernel updates, so we could perhaps use a combination of Secure Boot policy + kernel commandline hash to unlock the disk encryption key? *) And we could spend some time to see if we can cut down the size a bit > This is a guess though, I know nothing about Windows internals. > >> On top of this we could do what Ubuntu does and encrypt home directories >> at the filesystme level using the password the user uses to login to >> protect/unlock the key for this. The downside of this is that all the file >> metadata (filename, size) is not encrypted, but the contents is and >> this would come *on top of* the full disk encryption using the tpm. >> The advantage of using filesystem level per file encryption this way >> is that it avoids the diskspace problem entirely. >> > > Ubuntu does not support this anymore btw. They used to support encrypting the > home directory using ecryptfs and decrypting automatically through PAM login, > but now they dropped that and support encrypting the root volume using dm-crypt > and LUKS like we do in Fedora. I don't know why they decided to change that but > this launchpad says that ecryptfs-utils is "buggy, under-maintained, not a fit": > > https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1756840 Ah, right so it seems that we would need to use fscrypt and not ecryptfs, my bad. fscrypt still has an active upstream and is very much supported by its upstream AFAICT. Regards, Hans

3 3

Workstation WG meeting recap 2018-Dec-03
by mcatanzaro＠gnome.org 06 Dec '18

06 Dec '18

Minutes: https://meetbot.fedoraproject.org/fedora-meeting-2/2018-12-03/workstation.2… Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-2/2018-12-03/workstation.2… Log: https://meetbot.fedoraproject.org/fedora-meeting-2/2018-12-03/workstation.2… ================================= #fedora-meeting-2: Workstation WG ================================= Meeting started by stickster at 14:05:00 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2018-12-03/workstation.2… . Meeting summary --------------- * Roll call (stickster, 14:05:08) * Agenda: https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting (stickster, 14:08:52) * Default disk partitioning layout for Workstation (mcatanzaro, 14:11:08) * ACTION: otaylor form a subgroup to look at LUKS issue -- WG is not taking any specific actions until subgroup recommends something (stickster, 14:41:48) * LVM and /home partioning issues will depend on subgroup report recommendation for LUKS (stickster, 14:44:00) * Websites issues (stickster, 14:45:43) * LINK: https://pagure.io/fedora-workstation/issue/76 (stickster, 14:45:49) * ACTION: otaylor will follow up on this ticket, as noted (stickster, 14:46:47) * Docs site for Workstation WG (stickster, 14:47:50) * LINK: https://pagure.io/fedora-workstation/issue/69 (stickster, 14:47:52) * AGREED: use https://pagure.io/fedora-workstation repo to store Workstation WG docs and have them included in overall docs.fp.o site (+1: 6, 0: 0, -1: 0) (stickster, 14:55:05) * ACTION: stickster send proposal to list on docs to move to repo for antora use (stickster, 14:55:46) * Open floor (mcatanzaro, 14:56:36) Meeting ended at 15:02:57 UTC. Action Items ------------ * otaylor form a subgroup to look at LUKS issue -- WG is not taking any specific actions until subgroup recommends something * otaylor will follow up on this ticket, as noted * stickster send proposal to list on docs to move to repo for antora use Action Items, by person ----------------------- * otaylor * otaylor form a subgroup to look at LUKS issue -- WG is not taking any specific actions until subgroup recommends something * otaylor will follow up on this ticket, as noted * stickster * stickster send proposal to list on docs to move to repo for antora use * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * mcatanzaro (55) * stickster (54) * otaylor (28) * zodbot (15) * mclasen (15) * kalev (10) * ryanlerch (3) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

8 15

[Fedocal] Reminder meeting : Workstation WG
by stickster＠gmail.com 01 Dec '18

01 Dec '18

Dear all, You are kindly invited to the meeting: Workstation WG on 2018-12-03 from 09:00:00 to 10:00:00 America/New_York At fedora-meeting-2(a)irc.freenode.net The meeting will be about: Regular meeting for the Workstation Working Group. Agenda: https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting Chair: * Monday Jun 18 - Michael Catanzaro * Monday Jul 02 - (deferred) * Monday Jul 16 - Matthias Clasen * Monday Jul 30 - Rex Dieter * Monday Aug 13 - (deferred, Flock) * Monday Aug 27 - Paul Frields * Monday Sep 10 - Kalev Lember * Monday Sep 24 - Ryan Lerch * Monday Oct 08 - Jens Petersen * Monday Oct 22 - Christian Schaller * Monday Nov 05 - Owen Taylor More information available at: https://fedoraproject.org/wiki/Workstation Source: https://apps.fedoraproject.org/calendar/meeting/6411/

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop December 2018