On Fri, Jul 24, 2026 at 5:48 AM Ondrej Kozina <[email protected]> wrote: > > On 24/07/2026 12:15, Peter Robinson wrote: > > 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. > > But, it is not what Justin replied, right? I read: "I do plan to disable > it completely for F46." It seems pretty clear to me Fedora will go > further than upstream kernel.
Yes, that is the plan, but it is not this proposal. That would be an F46 proposal, and it is clearly dependent on userspace being ready for it. But I do want to take these steps first to get things moving in the right direction. > > > >> 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. > > Yes. People use various ciphers. I do not recommend that, but do not see > any issue with them doing that. cryptsetup is algorithm agnostic as much > as possible. > > > > > 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? > > It breaks images (LUKS2 in files) handling with non AES ciphers without > CAP_SYS_ADMIN. Again, there's use case for it in systemd-repart, I > mentioned in the beginning of the thread. I can't speak for systemd to > assess how important or widely used feature it actually is (the no > CAP_SYS_ADMIN required part). > > > > >> - No Adiantum in userspace crypto libraries currently supported by > >> libcryptsetup. The fallback via dm-crypt will again need CAP_SYS_ADMIN. > >> Affects LUKS2.> > >> - 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. > > It's supported libcryptsetup feature. No reason to break it in community > based distro in my opinion. > > > > >> 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. > > Again, the restricted mode with allow list seems to be the new upstream > default so far. If there's some other discussion in upstream kernel to > remove it completely without the /proc/sys/crypto/af_alg_restrict > switch, point me to it, please. > > Otherwise the switch, I think, answers your concerns about being stuck > mid release with whatever upstream decides to do later. > > O. > -- _______________________________________________ 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
