Talk:Security

Todo

• Update "Lockout user after three failed login attempts", file mentioned no longer contains those lines ? (relevant lines were moved to system-auth, see these two commits)
• descriptions/rationale for all the links to other articles (MAC)
• base64 /dev/urandom | dd bs=1 count=10 2>/dev/null
• use (enhanced?) ACL on partitions
• quotas
• limits/cgroups
• sudo timeout
• DNSSEC
• Securely Wipe HDD
• Using File Capabilities Instead Of Setuid
• VNC, proxies, ssl, etc
• rvim/rgvim
• browser security (requestpolicy, noscript, sand-boxing browser)
• PAX/grsecurity
• stack protector gcc flag: Put some text in the page indicationg Archlinux has it by default (See: FS#18864)
• run services as non-root (mention that Arch does this where possible by default - but it needs improvement via feature requests)
• run services in clean namespaces
• run services in chroots
• mention issues with sudo (any X11 application can grab the password, and it is a large setuid binary with potential vulnerabilities)
• describe password expiry policies (chage, passwd -X, etc.)

--thestinger 18:09, 11 January 2011 (EST), --Det (talk) 11:35, 3 January 2013 (UTC), --Flu (talk) 13:49, 19 April 2013 (UTC) -- Ndt (talk) 22:45, 12 August 2013 (UTC) --Compwiztobe (talk) 06:15, 7 September 2020 (UTC)

CentOS Wiki OS Protection Article

Hello,

This seems to be a good article to cross-reference or to use as a basis to pull in more content here. CC BY SA rights so I suspect it is compatible with the Arch Wiki. http://wiki.centos.org/HowTos/OS_Protection

I am hoping to pull some content in myself, but I am by no means a security guy. I figured some wiser heads might be able to make better use of it than I or correct any mistakes I might make while attempting to contribute.

Cheers, AdamT (talk) 22:29, 1 August 2013 (UTC)

Of course the information itself is not licensed/licenseable, however the way it is presented is, so you either study the original article and present the same information here in an original way, or you actually adapt some content from that article, but in that case the licence clearly states that you have to credit the original authors, and I guess you can do it by mentioning the original article in the Summary of your edits, and adding a link to Security#See also.

Just as a clarification, I know that Help:Style#Hypertext metaphor states "If the upstream documentation for the subject of your article is well-written and maintained, prefer just writing Arch-specific adaptations and linking to the official documentation for general information", however in this case we can't talk about "upstream documentation", that's why the rule doesn't apply and duplication of information is allowed, being CentOS's and Arch's wikis on the "same level" with respect to the information provided.

-- Kynikos (talk) 02:33, 3 August 2013 (UTC)

Let's first compare the sections in the two articles and see how they relate:

• Modifying fstab -> Security#Partitions.
• Package installs -> We have Security#Authenticating_packages and a note at the bottom of Security#Partitions.
  • We definitely should talk about Pacman#Package_security in more depth. That is, we should have a general overview of the function of Pacman-key and why it is important from a security perspective. Pacman-key mentions the function of the utility, but not its importance from a security perspective.
• Physical protection -> Security#Physical_security
• Restricting root -> We have Security#Use_sudo_instead_of_su which is a good start, but does not mention Ssh#Deny_root_login. File system permissions on /root, which I think by default are not 700 (they should be) should be added to Security#Filesystem permissions.
• Umask restrictions -> We should talk about umask in Security#Filesystem permissions.
• Pam modifications -> Realtime process management, a wiki page in desperate need of editing.
• Reaping idle users -> We should cover this in Security#User_setup.
• Restricting cron and at -> We have no equivalent.
• Wireless has to go -> Maybe worth talking about, but this is low-priority unless we are willing to write a more detailed section called "Wireless security" that is about more than just "turn off wireless."
• Sysctl Security -> Covered in Sysctl#TCP/IP stack hardening, maybe we should just link to this.
• Using TCP Wrappers -> I could not find anything on ArchWiki discussing general security practices for /etc/hotss.
• Beefing up IPTables -> Should be adapted into Iptables, but perhaps Simple Stateful Firewall (an article that has good information, but I am not sure if its name makes sense).
• Tamper Resistance -> We should have a section on logging in general and incorporate tools like this, probably.

Comments highly appreciated.

-- Ndt (talk) 05:09, 3 August 2013 (UTC)

If you want to start working in this direction, go for it! :) -- Kynikos (talk) 11:04, 5 August 2013 (UTC)

Nobody as script user

Systemd/cron_functionality#The_pkgstats_service article says that it is better to use noboby for some tipe of scripts. Is there any person who can explain further and add a note in this article?

-- Flu (talk) 11:29, 13 September 2013 (UTC)

Following the principle of least privilege it is logical to run as many scripts as possible as an unprivileged user. But this is not possible always, e.g. when the script needs (write) access to some file(s) to function properly, you need to provide those privileges. -- Lahwaacz (talk) 13:32, 13 September 2013 (UTC)

It's not actually a good idea to do this. Processes running as nobody can ptrace each other, so there is a loss of security if more than one thing is run as that users. Ideally, individual users would be created for each case. thestinger (talk) 10:52, 31 March 2014 (UTC)

Improving the password section

This is a call for ideas and community effort to improve the password recommendations here. I think it's generally agreed that the password section needs (and has, for a long time, needed) some work.

What does the password section need? Is it even necessary - does it make sense for someone to get this information from a wiki? How can we back up our statements, so that we know that the password recommendations made aren't just totally arbitrary (e.g, "at least one number ...")?

Citing sources, I think, is useful here - even though there's an element of password generation that is a matter of opinion, there are many recommendation that can be made that are not opinion. Just my two cents. - Ndt (talk) 21:51, 29 August 2014 (UTC)

A part I question is:

Insecure passwords include... Phrases of known words (e.g., all of the lights, correct horse battery staple), even with character substitution.

How about Diceware (mentioned in Disk_encryption#Choosing_a_strong_passphrase, which is linked to at the end of the section) ? --Alad (talk) 23:48, 31 August 2014 (UTC)

I've added some clarifications to that sentence: [1].

The whole problem comes down to the bits of entropy of a passphrase: if calculated against brute-force attacks, every character from the chosen set counts, because in general they are not releated to each other. In case of Diceware, the characters inside each word are related to each other, and instead what is independent are the words themselves, so the bits must be calculated on a per-word basis (it's vulnerable to dictionary attacks, which can be seen as a form of brute-force attack with every word representing a character in a set of 7776). Now, as you can see from the table in Wikipedia:Password strength, a set of 5 Diceware words is equal to e.g. 10 ASCII characters (64 bits); 7 words == 13 ASCII. Nowadays you'd need more than that to be "safe", but in the end it mostly depends on the importance of what you want to protect. Of course if you choose a phrase of words that are also grammatically related with each other, you're exposing it to some smart dictionary attacks, which would further lower the total bits of entropy.

Actually, that whole section could be questioned, in fact I could make a strong password even with "Root words or common strings followed or preceded by added numbers, symbols, or characters", if I chose enough "root words" and numbers; I could even make a strong password with dictionary words grammatically related, if the sentence was long enough :) I hope it makes it clearer.

-- Kynikos (talk) 14:34, 1 September 2014 (UTC)

Thanks for clarifying. Maybe add Wikipedia:Password strength to the article (it's already linked in Wikipedia:Password_cracking, but it wouldn't hurt here)? -- Alad (talk) 01:32, 2 September 2014 (UTC)

Link added after merging Disk_encryption#Choosing_a_strong_passphrase. Still, the whole section is very unorganized :( but at least now all the info is gathered in one place. -- Kynikos (talk) 03:16, 3 September 2014 (UTC)

First time I ever edit or contribute to a Wiki. I added an example of enforcing a password policy using pam_cracklib Redsolja (talk) 15:48, 26 April 2015 (UTC)

Thank you, very well done for a first edit! — Kynikos (talk) 02:34, 27 April 2015 (UTC)

Is it OK to add mention of secpwgen^AUR (for generating diceware passwords)? I'm the maintaner of that package. Kirillnow (talk) 22:12, 16 May 2019 (UTC)

In the Choosing secure passwords section, I'd like to point out that we're linking to an unencrypted webpage for testing password entropy... phil.r.dubois (talk) 23:30, 18 April 2018 (UTC)

Thanks, I originally removed that part without thinking too much, however that test is completely done on the client in Javascript, so theoretically safely, but still I don't see the point of using a website to do that when proper password managers such as Keepass* do the same right where you should be doing it. -- Kynikos (talk) 15:23, 20 April 2018 (UTC)

That explains why it was there in the first place. But yeah, that's a fair assessment. I'd prefer to choose a password manager over trusting the browser any day. phil.r.dubois (talk) 15:30, 20 April 2018 (UTC)

I'd like to point out that the first paragraph of this section ends with a reference to the Wikipedia article on "Entropic security", while it seems it should be pointing to the article "Password strength". I believe there's some confusion between "entropic security" and "password entropy". According to Wikipedia, entropic security is a property of certain encryption schemes, whereas "password entropy" is close to "information entropy", which indeed can be taken as a measure of password strength. Materia-nigra (talk) 08:42, 17 March 2023 (UTC)

In my opinion, the password section is too long. It would be better to either find an external source that gives good password generation practices or else create a dedicated wiki article to passwords, and let the article focus on suggestions about how and when to use/change passwords. I think most people who would check the Arch Wiki for information about security are looking for tips specific to Arch on how to make Arch more secure or hardened. Benm (talk) 02:20, 9 June 2024 (UTC)

Using systemd for more secure services

I saw this article that lists several options for systemd units to help protect one's system. I think some of these should be added to our article. In particular systemd.exec(5) recommends setting/enabling ProtectHome, ProtectSystem, ProtectKernelTunables, ProtectControlGroups, RestrictRealtime for most long-running services. Some of these are simple boolean options. Others have different levels that can be set. Lennart lists these and others here. -- Rdeckard (talk) 19:40, 3 January 2017 (UTC)

Working on a draft of some ideas here: User:Rdeckard/Secure Systemd -- Rdeckard (talk) 14:10, 5 January 2017 (UTC)

This is very useful, I wonder if it should be mandated for maintainers to ship unit files with hardening enabled, like Fedora does.

Otherwise, it is really up to the user for every installed package and most users do not even know about this. IPlayZed (talk) 17:01, 6 June 2024 (UTC)

Scope

I feel like security is a too big topic to be covered by a single page and I would prefer information on how to secure something to reside in the respective article and Security to be more like General recommendations (shorter sections linking other articles).

Rough proposal:

• Merge sections with respective articles
  • Security#File systems with File systems
  • Security#Use sudo instead of su with sudo
  • Security#DNS with Domain name resolution
  • Security#SSH with Secure Shell
  • Security#Managing SSL certificates with Transport Layer Security
• Move sections with enough content to dedicated articles
  • Security#Kernel hardening to Kernel hardening
  • Security#Physical security to Physical security
  • Security#Passwords and List of applications/Security#Password managers to Password management
• Create new articles for article-worthy topics
  • Mandatory access control, expanding on Security#Mandatory access control
  • Sandboxing, expanding on Security#Sandboxing applications
  • Firewall, expanding on Security#Firewalls and Category:Firewalls

--Larivact (talk) 18:31, 4 January 2019 (UTC)

I don't think it's a good idea to force out information just because some section is longer than a few sentences or doesn't conform to the overview-only style.

• Security#File systems is already short enough, moving Security#Mount options to File systems would make it loose all context (you can change the formatting to shorten the lists)
• Security#Use sudo instead of su → sudo: I agree
• Security#DNS is already short enough
• Security#SSH is already short enough
• Security#Managing SSL certificates → Transport Layer Security: I agree
• Security#Kernel hardening → Kernel hardening: I think that section alone would make a rather boring page, it is fairly short (except a few longish code blocks)
• Security#Physical security is short enough to be kept on this page
• Security#Passwords and List of applications/Security#Password managers → Password management: I agree, but some people may prefer the list staying in List of applications, in which case the split wouldn't make much sense
• Mandatory access control, Sandboxing, Firewall - I think that the new pages would be just another overview pages, the current sections are short enough to be expanded on this page

-- Lahwaacz (talk) 23:20, 5 January 2019 (UTC)

Nice to see you agreeing to some merges. Yes Security#SSH is short but I think the section fits better into an article about SSH. Security#DNS contains too much details, that duplicate Domain name resolution, for my taste. --Larivact (talk) 15:42, 6 January 2019 (UTC)

Regarding Security#DNS you marked the relevant DNS sections for rewrite or expansion. It's better if that is finished first. Looking at [[DNS] now, my conclusion is that it would totally overwhelm a reader to understand the main points summarised in two paras here. With Security#SSH I see it a little different, but crosslinks would get more out of context and may be redacted out by someone unsuspecting. For example, linking Google Authenticator, is more useful in this article, not? --Indigo (talk) 21:49, 6 January 2019 (UTC)

The rewrites of Domain name resolution seem to be finished, so how would you shorten Security#DNS exactly? I agree that the details should be in one place, but the referencing section shouldn't be just "See Domain name resolution for details." -- Lahwaacz (talk) 21:56, 9 January 2019 (UTC)

The DNS protocol is inherently insecure because it is unencrypted and unauthenticated. For a summary of the risks, recommended practices and available technology, refer to Domain name resolution#Privacy and security.

If you own a domain name, set a Sender Policy Framework policy to combat email spoofing.

--Larivact (talk) 06:54, 10 January 2019 (UTC)

Looks good to me. -- Lahwaacz (talk) 22:22, 16 January 2019 (UTC)

To me this article is not purely 'overview-only' but indeed to provide security context where a topic article may have a more general focus. For example, regarding Security#Managing SSL certificates that was the reason for my original edit comment in [2]. It sure can be reworded/maybe shortened, but again the target should be finished before it makes sense to approach such.

With the rest of the points I agree. --Indigo (talk) 21:49, 6 January 2019 (UTC)

Enforce a delay after a failed login attempt

Would it be worth to mention that auth optional pam_faildelay.so delay=4000000 intended to first login to the system only. And doesn't work when you unlocking screen later.

Webcapcha (talk) 19:27, 5 March 2020 (UTC)!

The additional configuration line has to be inserted as first line of the configuration file. Otherwise it has no effect.

Langfingaz (talk)

proc hidepid

If hidepid is enabled there is a minor issue with rtkit-daemon errors showing up in syslog.

Dmgcontrol (talk) 14:36, 5 March 2020 (UTC)

systemd unit hardening and system.conf tweaks

As described in systemd#Sandboxing application environments, it is possible to sandbox/harden service units using systemd (also see systemd.exec(5)). I think it is well worth mentioning this under Security#Sandboxing applications and maybe moving the section from the systemd article to this one.

Especially because it is so trivial to do so it should be added in my opinion. As always, it depends, but a few directives (see below) can make a unit significantly more secure. The "highlights" in my opinion are:

• NoNewPrivileges, basically prevents privilege escalation. See also RestrictSUIDSGID
• ProtectSystem and ProtectHome, this is configurable and an easy way to prohibit an application from manipulating things that it should not touch. Also prevents them from doing too much damage when they explode.
• AmbientCapabilities (and CapabilitiyBoundingSet), there is no need to run e.g nginx as root anymore if you can assign the unit CAP_NET_BIND_SERVICE, so it can bind port 80/443. This is just an example, there might be cases where it makes more sense to let the application handle the dropping of privileges.
• PrivateTmp, PrivateDevices, PrivateNetwork, PrivateUsers, restricts the things the unit can see and use.
• certain performance-related directives from systemd.resource-control(5), e.g MemoryMax. "Prevents" running of (with one of the CPU-related directives, of course) crypto miners. This is not really a "real" argument but restricting the resources a process can devour also has a few positive security-related side effects.

There are many, many more directives but I think that only the most important ones should be mentioned in the section.

Another thing I want to mention are some /etc/systemd/system.conf (systemd-system.conf(5)) tweaks:

• Set SystemCallArchitectures to native. This prevents running 32-bit binaries (because it blocks these syscalls), so unfortunately not every user can set this globally. As far as I know there are some (relatively) minor security implications from allowing 32-bit syscalls. However it is possible to override this for individual units, so the user can set this and make separate units for the (graphical) 32-bit binaries they need to run. This is quite tedious though.
• Set Default{CPU,IO,IP,BlockIO,Memory,Tasks}Accounting to yes. This is mostly a nice "performance monitoring" feature but it might be useful to see when a process used quite a bit of bandwidth. This gets logged into the journal and will be visible in the systemctl status output.

Yes, I saw the other entry for this, but it is quite old and does not include system.conf

NetSysFire (talk) 02:20, 25 February 2021 (UTC)

I'm against moving any of these instructions to Security, it would make the page unnecessarily detailed and long. I think it would be better to split off systemd#Sandboxing application environments into e.g. systemd/Sandboxing, merge Arch package guidelines/Security#Systemd services there and then add all other hardening stuff. The new page could then linked from Security#Sandboxing applications. -- nl6720 (talk) 09:34, 25 February 2021 (UTC)

Adding this just for reference; NetSysFire's proposed draft is at User:NetSysFire/systemd sandboxing. -- nl6720 (talk) 06:21, 14 October 2021 (UTC)

I don't see any objections coming in, against moving and merging systemd sandboxing stuff into systemd/Sandboxing. Why not create @NetSysFire systemd-sandboxing proposal there? Probackup-nl (talk) 07:52, 22 January 2024 (UTC)

The reason it was not merged yet are (1) lack of time (2) concerns of mine about the "chroot" not being done properly. If you want to help, help validate and test these instructions. I can use more eyeballs. NetSysFire (talk) 09:37, 22 January 2024 (UTC)

Sections up to 1.3 were used together with unbound.service as an example for my first .service hardening. 1.4 "chroot" looked to complex to me, so I skipped that part. Anyway: my overall exposure level for my-first.service hardening is: 2.1 OK. Probackup-nl (talk) 10:07, 22 January 2024 (UTC)

Why do you list Diceware as an insecure method to generate passwords?

Your article states:

Insecure passwords include those containing:

(...)

• Common phrases or strings of dictionary words (e.g. photocopyhauntbranchexpose) including with character substitution (e.g. Ph0toc0pyh4uN7br@nch3xp*se)

And it further elaborates:

Formerly, it was effective to use a memorable long series of unrelated words as a password. The theory is that if a sufficiently long phrase is used, the gained entropy from the password's length can counter the lost entropy from the use of dictionary words. This xkcd comic demonstrates the entropy tradeoff of this method. However, password crackers have caught on to this trick and will generate wordlists containing billions of permutations and variants of dictionary words, reducing the effective entropy of the password.

I'm not sure if I understand this line of reasoning?

There are 95 printable ASCII characters. There are 95^16 (~= 4*10^31) possible passwords consisting of 16 random characters drawn from the pool of 95 printable ASCII characters. Likewise, there are 95^15 (~= 5*10^29) possible 15-character passwords.

A standard Diceware dictionary consists of 6^5 = 7776 words. This means there are 7776^8 (~= 1*10^31) possible 8 word Diceware passwords. This means that a Diceware password is somewhat less secure than a 16 character random password, but more secure than a 15 character random password.

It doesn't seem to matter if 'passwords crackers have caught on this trick' or not. If password crackers are going to mount a brute force attack using 'wordlists containing bilions of permutations and variants of dictionary words' they will still have to try about as many combinations as if they were cracking a 15 or 16 character fully random password. And that is assuming that the crackers are using the same dictionary that was used to generate the password (and we should assume this, as per the Kerckhoffs's principle).

If this password strength is unsatisfactory then there is no need to limit ourselves just to 7776 words. There are many more words in the language to choose from. For example, on my bookshelf I have a dictionary titled '100000 necessary words'. I'm sure we can find digital dictionaries of that many or even more words, faciliting automated generation of secure Diceware passwords. If this method was used we would end up 100000^8 = 10^40 possible passwords; this is even slightly better than if we were using a 20 character random password, as there are 95^20 ~= 4*10^39.

On the other hand, I'm pretty sure that an 8 word password, even one that uses obscure words, is easier to remember & type than a 20 or even 16 character random password. Kmph (talk) 17:39, 1 March 2021 (UTC)

Just to add more context, the 7776 word limits comes from the number of permutation available with throwing 6 sided dices ( times, that's how you get the words. Either you keep this method as base, add another dice throw and you need to have a 46656 word list (I mean, I'm all for multilingual lists!), or you somehow reduce the value of the last throw (with a modulo 3 for example).

Otherwise, I agree with your reasoning. It doesn't matter if the word list is public or not (I mean, you could create your own word list for all that matters).

Also, one thing to take into account is the threat model. Who are you trying to protect yourself from? The government? They have much more effective method of getting your password if they really want to that just blindly bruteforcing it. From script kiddies hacking websites? You need a password stronger than the one from your neighbor and mainly unique (that's the big problem).

I also can't wait to have emojis in my passwords (and a way to type them easily on my computer too!). You blend in emojis in the mix and your character list jumped from 95 to 3616. Until then, passphrases are king in my kingdom.

Gromain (talk) 09:42, 12 May 2021 (UTC)

I fully agree with Kmph. The justification for rejecting Diceware doesn't prove anything. Also the article recommends using a mnemonic phrase (“the girl is walking down the rainy street”) to remember a password where one word encodes one character in the password. This method is inferior to Diceware since a Diceware word contains 2 times more entropy than a character. The phrase “strings of dictionary words” and the justification for rejecting Diceware should be removed. --Beroal (talk) 12:33, 16 October 2021 (UTC)

You should only use this type of password when you can not use a password manager, e.g as your LUKS or password manager passphrase since you have to enter these manually. Most other things can have a 128-char random password or similar.

Those things also tend to be harder to bruteforce as these are usually not accessable via the internet. The main concern here is actually shoulder surfing, so longer xkcd-style passphrases may help with that.

-- NetSysFire (talk) 12:50, 16 October 2021 (UTC)

hidepid and systemd

The hidepid section says:

This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all

However, this is not entirely true, because systemd happily exposes some of this data with commands such as:

$ systemctl status service-name
$ loginctl list-sessions
$ loginctl user-status username

If there is an "official" way to fix this leak, it would be good to see it in the article.

I'm trying to block "unsafe" D-Bus methods as suggested by this answer on Stack Overflow, but I'm not sure if this method is complete or correct.

-- andreymal (talk) 12:56, 14 March 2023 (UTC)

Which defaults use packages?

Are compiled with Position Independent Execution (PIE)? If we recommend to rebuild packages, what benefits are from these from defaults?--Xan (talk) 20:53, 19 June 2023 (UTC)

The default build flags are in /etc/makepkg.conf. The motivation for rebuilding is described in Security#Rebuilding packages. — Lahwaacz (talk) 11:21, 24 June 2023 (UTC)

This section is kind of counterintuitive, because using packages from the official repos is more secure if you trust the Arch maintainers (which you probably do by using Arch as your OS), but by using the AUR or other sources you significantly reduce the potential integrity of the system anyway. Also, you probably do not rebuild all packages anyway because you are probably using stuff like ls, gcc, and especially your desktop. from the main repos.

It should be mentioned that this has these changes are probably very limited in scope looking at the bigger picture. IPlayZed (talk) 16:57, 6 June 2024 (UTC)

Use of hardened-malloc with Firefox

This thread from tor-dev suggests that hardened-malloc is only effective at hardening Firefox if the default jemalloc is disabled during the build. AFAICT, the official Arch Linux firefox package does include jemalloc. I was unable to find a lot of discussion online regarding the use of this flag, outside of some mention on the Firefox Source Docs wiki about it being needed for instrumentation and debugging. Dwu21 (talk) 09:19, 8 January 2024 (UTC)

firefox, specially the one shipped with arch, will not work at all with hardened-malloc. Gcb (talk) 09:56, 27 March 2024 (UTC)

I wrote that a while back. I can confirm now too, that the official Arch build suffers from frequent crashes if used with hardened-malloc.

I modified the official build script for the firefox package to include "ac_add_options --disable-jemalloc" into mozconfig, and I have yet to run into crashes. Dwu21 (talk) 10:14, 27 March 2024 (UTC)

Outdated lockdown info?

I'm not a specialist on this, but the paragraph on lockdown says:

> All officially supported kernels initialize the LSM, but none of them enforce any lockdown mode.

yet the man page https://man.archlinux.org/man/kernel_lockdown.7 says

> On an EFI-enabled x86 or arm64 machine, lockdown will be automatically enabled if the system boots in EFI Secure Boot mode.

which i can somewhat validate

vanila-arch $ cat /sys/kernel/security/lsm
capability,landlock,lockdown,yama,bpf

Gcb (talk) 09:59, 27 March 2024 (UTC)

Security#Kernel lockdown mode is not outdated, the kernel_lockdown(7) man page is simply wrong. /sys/kernel/security/lsm shows the initialized LSMs (just as the tip says), nothing more. It's /sys/kernel/security/lockdown that shows if a lockdown mode is in effect. -- nl6720 (talk) 11:40, 27 March 2024 (UTC)

Rebuilding packages

The Open Source Security Foundation has a pretty good guide for recommended hardening options to use with GCC and Clang. Perhaps this could replace the current paragraph for rebuilding packages? It currently has a note that it is based on a blog post from Red Hat from 2018. These OpenSSF recommendations are much more recent.

There is also a -fhardened option for GCC to include some basic hardening options: https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fhardened

https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++ Jeroen0494 (talk) 13:33, 22 June 2024 (UTC)