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