FedoraWorkstation default firewall rules unsafe
Hi all, Yesterday, while assisting a user with connecting a printer, I noticed that the default firewall zone on Fedora Workstation is set to "FedoraWorkstation". This zone has ports 1025-65535 open by default [0]. Is there a historical reason for this, just an oversight, or am I missing something? This configuration doesn't seem ideal for typical users and developers. For example, I often run dev servers that I assume are secure due to the default firewall settings, but it appears that even the Home zone is more restrictive. I'm considering to open a change request to remove these firewall rules for better security but want to ensure I'm not overlooking anything. Thanks in advance! Kind regards, Arthur Bols fas: principis [0]: https://src.fedoraproject.org/rpms/firewalld/blob/c2e602b9fa037b10c843f43afbb2d1d3fc9b612a/f/FedoraWorkstation.xml#_8 -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: FedoraWorkstation default firewall rules unsafe
On 28/07/2024 11:20, Björn Persson wrote: Arthur Bols via devel wrote: I often run dev servers that I assume are secure due to the default firewall settings This practice of blindly assuming that somebody else is protecting you from your own negligence is a common source of security breaches. Björn Persson Aside that this does not contribute to the discussion at all, I believe it is reasonable to assume that the default firewall rules are strict enough to not open all ports above 1024... That being said, it's an example, and those servers are listening on localhost. -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: FedoraWorkstation default firewall rules unsafe
On 28/07/2024 11:33, Adam Williamson wrote: On Sun, 2024-07-28 at 10:25 +0200, Arthur Bols via devel wrote: Hi all, Yesterday, while assisting a user with connecting a printer, I noticed that the default firewall zone on Fedora Workstation is set to "FedoraWorkstation". This zone has ports 1025-65535 open by default [0]. Is there a historical reason for this, just an oversight, or am I missing something? This configuration doesn't seem ideal for typical users and developers. For example, I often run dev servers that I assume are secure due to the default firewall settings, but it appears that even the Home zone is more restrictive. I'm considering to open a change request to remove these firewall rules for better security but want to ensure I'm not overlooking anything. It's intentional. It's been that way since the first release of Workstation. Sure. But why do those ports need to be open by default at all? What is the benefit of adding those extra 2 lines? Does it enhance user friendliness? I doubt it, as users will still need to open ports for e.g. slp or mdsn. What it does is put users at risk. I wouldn't have this conversation if we had no firewall rules like arch or Debian, but we do. We even go as far as install and enable Firewalld by default. As far as I know Fedora is positioning itself as a beginner-friendly Linux distro, thus we should strive to protect users. Enabling a firewall that blocks traffic up to port 1024 is strange and confusing, especially for security minded beginners. It's called "Workstation". If you want to run a server, install the one called "Server". I would if I want to run a server, not a developer machine. And that would also incite me to enable and configure the firewall. Arthur-- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: FedoraWorkstation default firewall rules unsafe
On 28/07/2024 13:20, Michael Catanzaro wrote: On Sun, Jul 28 2024 at 11:37:15 AM +02:00:00, Arthur Bols via devel wrote: Aside that this does not contribute to the discussion at all, I believe it is reasonable to assume that the default firewall rules are strict enough to not open all ports above 1024... That being said, it's an example, and those servers are listening on localhost. This discussion comes up every few years. Suffice to say: a firewall that blocks users from using software is a firewall that's not suitable for Fedora Workstation. Unlike server users, desktop users don't know what ports are and don't expect to have to modify firewall rules to run a new service. You say "unsafe" but it's only unsafe if you have software listening on those ports. And if you have software listening on those ports, surely you want it to work rather than be blocked? If you have software listening that you *don't* want to work, then why do you have it listening in the first place! Thank you for the insight. When I posted, I assumed other distributions had stricter default configurations. However, it seems Fedora is one of the few that blocks some traffic by default (even Ubuntu accepts everything by default). I understand the reasoning behind the current configuration, but I think the reality doesn't quite match the idea. The firewall does prevent users from using certain software. For example, if you're trying to set up an HP printer, you'll need to enable the SLP/MDNS services to get it working if you're following the setup wizard. Also, why do we even have any rules if nothing is listening? One could argue that it's a security tradeoff, but I wonder if it might do more harm than good by giving users a false sense of security. It's been about 10 years since we established this firewall configuration, and I haven't seen much interest in developing a smarter stricter firewall, so this is what we're left with. Maybe you're right; without a smarter firewall, there isn't a better solution. Fedora has always been about being "first". Perhaps there's a way to educate users on configuring the firewall when needed (for most things it should just be checking a box in firewall-config)? However, I have no idea how much it would hinder the average Fedora user, as the only thing listening on my pc is KDE Connect... Unfortunately, security is always the first thing to go out the window. Arthur -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: FedoraWorkstation default firewall rules unsafe
On 28/07/2024 23:11, Samuel Sieb wrote: MDNS works by default. Users don't need to open the port. It seems you are correct, due to the fact that ports 1025-65535 are open by default. I must've changed to the default zone to home for my network when I tried this years ago. Thanks for the correction. I wouldn't have this conversation if we had no firewall rules like arch or Debian, but we do. We even go as far as install and enable Firewalld by default. As far as I know Fedora is positioning itself as a beginner-friendly Linux distro, thus we should strive to protect users. Enabling a firewall that blocks traffic up to port 1024 is strange and confusing, especially for security minded beginners. Fedora enables firewalld by default as well. I guess you mean OpenSUSE? -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning eza (rust-eza - maintained fork of exa)
Hi Fabio, On 31/10/2024 19:38, Fabio Valentini wrote: Hi all, TL;DR: I am planning to orphan rust-eza later today. Be warned - it's a lot of work to keep up with upstream (~1 release per week), keeping it up-to-date in epel8 is a bit painful (because RHEL 8, duh), and there are license shenanigans afoot since the v0.20.0 release (package is currently at v0.19.3). Given that I don't even use eza myself and just packaged it because it was on some people's wishlist as the maintained fork of exa, I really cannot justify the ongoing cost of maintaining this package to myself. I'm interested in maintaining eza since I use it on multiple systems. I'm a bit hesitant, though. First, I won't have time to keep up with every upstream release, but I'll do my best to keep it updated. Also, because of the large dependency tree, I think joining the rust-sig would be helpful so I can update dependencies as needed (and of course, I'll try to help others out where I can). Finally, my experience with Rust is limited, but I am quite familiar with the packaging process. Do you think this is a good idea or would it be better to leave it for someone else? It might be of note that the project was relicenced from MIT to EUPL-1.2 without much fanfare as of the 0.20.0 release, in this mess-of-a-PR:https://github.com/eza-community/eza/pull/1155 - I'm not a lawyer, but the maintainer unilaterally slapping a different license onto a project that's been around since 2017 in some form without asking other contributors (or the original author of exa) doesn't pass the smell test for me. Seriously... https://github.com/eza-community/eza/releases/tag/v0.20.0 The PR mentions dual-licensing, but it's now a mess of only MIT, MIT or EUPL-1.2, and only EUPL-1.2... Arthur fas: principis-- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning eza (rust-eza - maintained fork of exa)
On 05/11/2024 21:39, Fabio Valentini wrote: On Tue, Nov 5, 2024 at 9:33 PM Arthur Bols wrote: Hi Fabio, On 31/10/2024 19:38, Fabio Valentini wrote: Hi all, TL;DR: I am planning to orphan rust-eza later today. Be warned - it's a lot of work to keep up with upstream (~1 release per week), keeping it up-to-date in epel8 is a bit painful (because RHEL 8, duh), and there are license shenanigans afoot since the v0.20.0 release (package is currently at v0.19.3). Given that I don't even use eza myself and just packaged it because it was on some people's wishlist as the maintained fork of exa, I really cannot justify the ongoing cost of maintaining this package to myself. I'm interested in maintaining eza since I use it on multiple systems. I'm a bit hesitant, though. First, I won't have time to keep up with every upstream release, but I'll do my best to keep it updated. Also, because of the large dependency tree, I think joining the rust-sig would be helpful so I can update dependencies as needed (and of course, I'll try to help others out where I can). Finally, my experience with Rust is limited, but I am quite familiar with the packaging process. Well .. I guess it depends on how much time you can invest into this? And if you want to deal with the licensing mess mentioned below? :) Difficult to say right now, but I believe enough. It might be of note that the project was relicenced from MIT to EUPL-1.2 without much fanfare as of the 0.20.0 release, in this mess-of-a-PR:https://github.com/eza-community/eza/pull/1155 - I'm not a lawyer, but the maintainer unilaterally slapping a different license onto a project that's been around since 2017 in some form without asking other contributors (or the original author of exa) doesn't pass the smell test for me. Seriously...https://github.com/eza-community/eza/releases/tag/v0.20.0 The PR mentions dual-licensing, but it's now a mess of only MIT, MIT or EUPL-1.2, and only EUPL-1.2... Yes. I wasn't joking when I said it was a mess-of-a-PR :) That mess alone would make me hesitant to want to continue maintaining (or using) this project. :( I can understand that. Unfortunately it is a great tool... :/ I'm going to sleep on 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
pkcs11-provider update breaks eduroam
Hi all, A few days ago pkcs11-provider-0.5-3.fc41 update was pushed to Fedora 41. Unfortunately, this update breaks eduroam and possibly many other WPA2-Enterprise wifi networks. There are multiple threads on Fedora Discussion, mainly [0], and a bug report [1]. I understand that the maintainers implemented this change with the best intentions, however, could someone clarify why this provider was enabled so abruptly in this update? Wouldn’t such a change typically require a change proposal? Given how many users are affected, would it make sense to consider rolling back the update until there’s a fix? Kind regards, Arthur Bols fas: principis [0]: https://discussion.fedoraproject.org/t/unable-to-connect-to-wpa2-enterprise-after-upgrading-to-fedora-41/134889 [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2326839 -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: pkcs11-provider update breaks eduroam
On 21/11/2024 13:06, Davide Caratti wrote:
yes. The problem is in md4_vector() [1], the legacy provider has a
non-NULL pointer and EVP_md4() fetches correctly. However, when
pkcs11-provider is installed,
EVP_DigestInit_ex() fails. I tried this patch [2] on upstream
wpa_supplicant, and it seem to fix at least my local test. The patch
loads the default provider after loading the legacy provider (and
unloads it before exiting), and took inspiration from [3] and [4].
@Dmitry Belyavskiy , does it make sense for you? if so I could submit
it to upstream wpa_supplicant. Or maybe it deserves a test in eduroam
first.
--- a/src/crypto/crypto_openssl.c
+++ b/src/crypto/crypto_openssl.c
@@ -188,15 +188,21 @@ static int EC_GROUP_get_curve(const EC_GROUP
*group, BIGNUM *p, BIGNUM *a,
#if OPENSSL_VERSION_NUMBER >= 0x3000L
static OSSL_PROVIDER *openssl_legacy_provider = NULL;
+static OSSL_PROVIDER *openssl_default_provider = NULL;
+
#endif /* OpenSSL version >= 3.0 */
void openssl_load_legacy_provider(void)
{
#if OPENSSL_VERSION_NUMBER >= 0x3000L
if (openssl_legacy_provider)
- return;
+ goto load_default_provider;
openssl_legacy_provider = OSSL_PROVIDER_try_load(NULL,
"legacy", 1);
+load_default_provider:
+ if (openssl_default_provider)
+ return;
+ openssl_default_provider = OSSL_PROVIDER_try_load(NULL,
"default", 1);
#endif /* OpenSSL version >= 3.0 */
}
@@ -208,6 +214,10 @@ static void openssl_unload_legacy_provider(void)
OSSL_PROVIDER_unload(openssl_legacy_provider);
openssl_legacy_provider = NULL;
}
+ if (openssl_default_provider) {
+ OSSL_PROVIDER_unload(openssl_default_provider);
+ openssl_default_provider = NULL;
+ }
#endif /* OpenSSL version >= 3.0 */
}
thanks,
Thank you for your work on this!
Could you create a scratch build? I don't use it myself anymore, but I
know some people who can test 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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
