- Arch-devops - lists.archlinux.org

Request For Insights On Kernel Security Hardening Practices In Arch Linux
by Yinhao Hu 18 Dec '24

18 Dec '24

Dear All, We are academic researchers from Huazhong University of Science and Technology, China. To foster a healthier Linux kernel community and enhance the overall security of Linux distributions, we are conducting a study on kernel security hardening deployments across various Linux distributions. In our research, we analyzed kernel config files and the /proc filesystem by installing and running multiple distribution ISO images. This allowed us to enumerate the default deployment of kernel defense mechanisms at runtime. So far, we have cataloged over 50 kernel security hardening features and documented inconsistencies in their deployment across different distributions. The results of our analysis are accessible via the following link: https://docs.google.com/spreadsheets/d/17QRr04pqK1K4-VoHXW2-9KgPd4uV8Q4I-NN…. Given Arch Linux’s reputation for exceptional performance and rich features, we conducted a detailed investigation into its kernel security hardening strategies. To further deepen our understanding, we would greatly appreciate your input on the following questions: 1. Effectiveness of Kernel Security Hardening 1.1 Do you consider deploying kernel security hardening features to be an effective strategy for ensuring operating system security? 2. Configuration Strategy for Default Kernel Security Hardening Options 2.1 What are the primary criteria for selecting kernel security hardening options in your distribution? 2.2 How are configurable security hardening features (e.g., unprivileged_bpf_disabled) typically set (e.g., 0, 1, or 2), and what are the main considerations involved? 2.3 How do you balance the trade-off between side-effects (e.g., performance overhead) and the enhanced security introduced by kernel security hardening? 2.4 Does the tolerance for performance overhead vary across different application scenarios? 2.5 Are there other negative factors, such as compatibility issues, that are considered when enabling security hardening features? 3. Customized Configurations 3.1 Do you provide different kernel security hardening configurations tailored to specific user groups? 4. Best Practices and Recommendations 4.1 Are there any best practices or recommendations you can share regarding kernel security hardening? 4.2 Are there relevant documents or materials available for reference? The purpose of these questions is to gain a deeper understanding of your security protection strategies. Your insights would be immensely valuable to our study. Thank you for taking the time to review our questions. We look forward to your response. Best regards, Yinhao Hu, PhD candidate huyinhaodd(a)gmail.com Huazhong University of Science and Technology

1 0

Getting a small Hetzner dedicated server for buildbtw development and testing
by Sven-Hendrik Haase 26 Nov '24

26 Nov '24

Hey guys, I intend to get a small Hetzner box (most probably AX41-NVMe) for buildbtw development and testing, trying a bunch of things in the capacity of a proof-of-concept. We don't exactly know where we're going with this yet. We need a hardware machine as we need it to be able to do virtualization. Hetzner cloud VMs can't do virtualization. It will be a special gitlab-runner executor. The idea is to fork the libvirt runner and add a bunch of buildbtw-specific stuff to it. It will not be managed by devops. I will give root to people involved in the buildbtw project. Costs will be <€40/month. It will be decommissioned after development. Any thoughts or objections?

3 4

A Mumble server for Arch Linux
by Sven-Hendrik Haase 26 Nov '24

26 Nov '24

Hello everyone, I would like to suggest we set up a Mumble server for Arch Linux staff. Time and time again, it's been useful for Arch people to come together for a longer time to hack on various projects or to plan stuff like Arch Summit. Often times, people use Jitsi for such things. However, I think Mumble is a more suitable alternative for people hanging out for a longer time as it: - allows you to have multiple channels for dedicated topics and you can see who's currently meeting where - is more stable than Jitsi in my experience - has better desktop integration for muting - has better quality - can more easily be used over slow networks The idea is to use mumble-server, put it on the smallest Hetzner VPS and call it a day. I've been operating Mumble servers for years and it requires maintenance basically never. We cannot connect it to SSO so we'll run it like we run the IRC channels: have a password and ask people to not tell people outside of staff. We'll have a bunch of moderators (not necessarily devops, just whoever wants to do create some channels now and then) that can set up channels and such but apart from that I think we can just run it. Thoughts? Sven

7 9

Cannot register new security keys on accounts.archlinux.org
by Frederick Zhang 29 Sep '24

29 Sep '24

Hi all, I was trying to replace my security keys on accounts.archlinux.org however the page [1] seemed to be broken due to a missing base64url.js script [2]. Here's the Copy as cURL command I got from Firefox dev tools and its output: $ curl 'https://accounts.archlinux.org/resources/l7rth/login/archlinux/js/base64url…' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:131.0) Gecko/20100101 Firefox/131.0' -H 'Accept: */*' -H 'Accept-Language: en-GB,en-US;q=0.8,en;q=0.5,ja;q=0.3' -H 'Accept-Encoding: gzip, deflate, br, zstd' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Sec-Fetch-Dest: script' -H 'Sec-Fetch-Mode: no-cors' -H 'Sec-Fetch-Site: same-origin' -H 'TE: trailers' -D- HTTP/2 404 server: nginx date: Tue, 10 Sep 2024 11:47:04 GMT content-length: 0 referrer-policy: no-referrer strict-transport-security: max-age=31536000; includeSubDomains x-content-type-options: nosniff x-xss-protection: 1; mode=block strict-transport-security: max-age=31536000; includeSubdomains; preload Could someone who has access please look into this issue? And of course let me know if this is the wrong list. Thank you! [1] https://accounts.archlinux.org/realms/archlinux/login-actions/required-acti… [2] https://accounts.archlinux.org/resources/l7rth/login/archlinux/js/base64url… -- Frederick Zhang PGP: 8BFB EA5B 4C44 BFAC C8EC 5F93 1F92 8BE6 0D8B C11D

2 2

becoming member of the infrastructure team
by khaliid caliy 18 Sep '24

18 Sep '24

I am a sysadmin and i would like to participate in Arch Linux infrastructure team with my skills and expertise and i willing and eager to learn more. Thanks all and apologies for inconvienance

3 4

Christian Heusel is now a full DevOps!
by Kristian Klausen 11 Feb '24

11 Feb '24

Hi all, Christian has been a Junior DevOps for nearly 4 months but has been consistently contributing for way longer than that. He has proven himself to be hard-working and reliable, the DevOps team has therefore decided to promote him to full DevOps with all responsibilities and privileges that come with that. Welcome aboard, Christian! Cheers, Kristian

1 0

Rebasing other users' MRs for packages
by Brett Cornwall 11 Jan '24

11 Jan '24

Not sure if this is intentional but trying to rebase the branch in this MR is giving me a "something went wrong": https://gitlab.archlinux.org/archlinux/packaging/packages/sway/-/merge_requ… I would guess that the person just didn't check the "let the maintainer edit the commits" or something but I'd expect a less generic error message. Is this intentional behavior or broken behavior?

3 2

Automatic mailman onboarding
by Jelle van der Waa 07 Jan '24

07 Jan '24

Hey all, We have been wanting to onboard folks automatically via Keycloak to all our services. Mailman being one of them: Gluebuddy seems to be the best fit for this, as it a) knows keycloak and b) can also talk to mailman eventually (as it's just a REST API). For this I made an issue in Gluebuddy and a WiP branch for Gluebuddy which can do onboarding. [1] There are however several issues left to solve as we have many different usages of our mailing list. I for example on Keycloak use jelle(a)vdwaa.nl for my account and my arch email is jelle(a)archlinux.org (same as keycloak username). However this is not always the case, we have folks who have: - Different Keycloak email from Arch - Different Arch mail address from login name ie. svenstaro => sven(a)archlinux.org - May not use Arch email for mailing lists but their own. So in Keycloak I've used the beta feature of profile attributes, to add arch_email. And I think we should set this for all staff to be their archlinux email address. Even if it's the same as their username. With that solved we can onboard all arch email addresses. Would this also help for onboarding users into mail.archlinux.org? At least we can maybe replace the hardcoded mailmap? Now I know a lot of us subscribe with their personal email, how do we want to handle that from gluebuddy? Just mass subscribe and allow users to unsubscribe? Or at least allow sending? I haven't implemented onboarding, that likely has to request all users from mailman and match them against known keycloak staff's email/arch_email attributes. [1] https://gitlab.archlinux.org/archlinux/gluebuddy/-/issues/4 [2] https://gitlab.archlinux.org/archlinux/gluebuddy/-/merge_requests/17 P.S. the irony, I am not subscribed with my @archlinux.org address to this list.

2 1

Proposal about AUR affairs
by Evan Greenup 10 Dec '23

10 Dec '23

Hello, AUR is a unique feature for Arch Linux (include derived distros). It significantly expand the Arch ecosystem. However, for the current infrastructure and workflow for AUR, there are some drawbacks. 1. Difficult to feedback and difficult to contribute (to already existed package). If have any ideas or report, user need to send email to maintainer via email personally. This is not convenient for both maintainers and users. 2. Lack of Peer review, audience supervise. Some packages even if updated frequently by its maintainer, but it doesn't following good practice and not built from source (Not Java, native program), It retrieve from Debian or Ubuntu or Fedora packages, and extract or repackage it in Arch Linux package. And some packages may failed to build, or some of its dependencies are forgotten added by maintainer. 3. The entry with a specific name in AUR is always occupied by the Maintainer who firstly register the package. If there is another maintainer who has better practice than the previous one, This maintainer has to rename his/her package as `xxx-bin` or some sophisticated name else. This is unfair. It lack of refreshing mechanism. 4. upstream software author is difficult to directly contribute to the AUR packaging contribution. For a great number of upstream software author, they are willing to participate in downstream redistribution process. Especially for those young software. But the current AUR workflow block their way to contribute on downstream stuff. 5. Currently,to evaluate whether a AUR package is eligible to move in Arch Linux official packages (extra repo), It only depend on votes and popularity and whether there is a maintainer willing to pick it up. However, those factors is too lack of details. To evaluate the robustness of the eco-position of a package, It should evaulate the discussion, issue report, contribution, and ... And it should be evaluated case by case. I have some ideas to resolve or mitigate the problems above. 1. Create a git repo on gitlab.archlinux.org named aur-meta (Or whatever names which maker users understand easily). This git repo keep a list (table of content) which point to the git repo URI of the AUR packages. 2. For the AUR package, it can be placed on anywhere (github.com, gitlab.com, gitlab.archlinux.org, gitlab.gnome.org ...), the only things needed are these URIs are public accessible (can be git cloned by anyone who know this URI). And it need to keep its PKGBUILD on the top level of git repo. 3. The issue and affairs related to which upstream software is included and which PKGBUILD git repo is selected, goes to issues section of aur-meta. For packaging specific problems, it goes to the AUR package git repo. 4. If a package is orphaned or too broken/bad practice, the contributor who has access to aur-meta can simply change the pointer to a alternative PKGBUILD git repo which is better in practice and liveliness. 5. If user find there is package which need to be improved, it can firstly report it to PKGBUILD maintainer via the issue section of git repo. If the maintainer long time not response or insist to keep bad practice. The user can write a proposal in aur-meta to change the pointer to another alternative. This is what a community driven packaging method should be. 6. The name of entry in aur-meta is the package name, not the name of PKGBUILD git repo. (git repo can have different name). Many upstream software author would create a separate git repo along with their software repo which is dedicated for PKGBUILD. The design above, is just for demonstrate ideas, improvements can be made further. Evan

4 3

Handle recompilation of dependent packages, on breaking-changes
by Veldora 02 Nov '23

02 Nov '23

Hi there I'm having an issue with the ABS and how it's working. I've read, that the ABS is based on a similar concept such as *BSD's ports system. On e.g. FreeBSD, I can use poudriere to handle the ports and it's dependents recompilation. E.g. ffmpeg provides libavcodec.so, libavdevice.so, libavfilter.so, libavformat.so, libavutil.so Firefox depends on ffmpeg and poudriere handles like so: if a .so file get's changed, it recompiles ffmpeg to provide the .so and recompiles all dependent packages. (within also firefox). Has the official Arch build server anything similar to poudriere, so a rebuild of packages e.g. ffmpeg would trigger a recompilation of e.g. firefox, to match with the latest version again. The reason for this is, I would like to use a repo-snapshot of the Arch archive as main-repo and backport security-patches from the gitlab sources to a custom repo. While I could just do it manually, which would be a pain to manage and packages which depend on it hard to find, I'm asking, if there is anything comparable to poudriere on FreeBSD for Arch Linux, which I can selfhost? Thanks.

1 0