Hi Ondrej, > >> Ok, public awareness aside (which I agree with), are there any Fedora > >> specific steps planned above what the upstream kernel plans to do? > > > > Somewhat. I do plan to disable it completely for F46. If upstream > > doesn't do so first, it can still be enabled in F45, but that will be > > the last release. > > The upstream has a plan for restricted mode with allow list for AF_ALG > and there's a clear justification for it (links below). I currently do > not follow why this is not enough for Fedora going forward, so I'd like > to hear more if we want to go further then that.
And that is what the primary part of this will implement, as already described. > My arguments against turning the AF_ALG _completely_, without > replacement are as follows: There's not going to be a kernel replacement. > - there's no xts mode implemented for camellia, serpent and twofish > ciphers in openssl (I mention only the most used AES alternatives). So > the cryptsetup (in Fedora) will loose userspace access to those ciphers > without CAP_SYS_ADMIN. Affects LUKS2. Can you provide details of where they are used in Fedora? I believe these would only be used if a user when out of their way to use those, generally via a manual install process. In the case of requiring CAP_SYS_ADMIN that wouldn't affect standard boot partition unlocking but I believe would affect user drives that are encrypted correct where they use non default cyphers? > - No Adiantum in userspace crypto libraries currently supported by > libcryptsetup. The fallback via dm-crypt will again need CAP_SYS_ADMIN. > Affects LUKS2. Again I believe this is a non default Fedora option that users would have to go out of their way to select, if not can you link to explicit details please. > - Limited support for truecrypt/veracrypt containers. Only ciphers > available in userspace crypto libraries remains usable. No dm-cryt > fallback possible. Again, look at missing support for xts mode above. Again please provide details of where truecrypt/veracrypt containers are used in Fedora. > The AES is default and will be, but there are use cases where AES is not > a good fit (low end embedded devices with no HW support) and if you turn > the AF_ALG off completely, it will cause headache. That's likely true for low end android phones but even the vast majority of low end aarch64 have some level of accelerated AES even if it's only via the NEON optimised kernel code. > - no cryptsetup benchmark for block ciphers (no replacement even with > CAP_SYS_ADMIN). Though, I'd not personally deem it critical. It's something I've used myself but I would sooner the reduced attack vector. Ultimately this interface is going to go away whether we like it or not, this change is very much about preparing Fedora users so that people are aware there is change coming where we have some runway to deal with any of the fall out rather than just waiting for an upstream kernel just drops it at which point users may end up being stuck mid release with a very unexpected change. Peter -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
