- 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
- sudo timeout
- Securely Wipe HDD
- Using File Capabilities Instead Of Setuid
- VNC, proxies, ssl, etc
- browser security (requestpolicy, noscript, sand-boxing browser)
- 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
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.
- 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.
- 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
umaskin 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
- 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)
- Let's first compare the sections in the two articles and see how they relate:
We now have three sections devoted only to Grsecurity. What can we do about this?
The addition of Security#Grsecurity RBAC seems to be redundant. However, I agree that "RBAC" is a better name for Grsecurity's MAC implementaiton than Security#Access Control Lists. In technical terms ACLs are a subset of RBAC and Grsecurity implmeents both. The Grsecurity patchset only had ACLs[PDF] back in 2005, and the cited case study mentions (it also refers to SELinux as a RBAC implementation, so perhaps SELinux should also be mentioned there):
- This implementation of ACLs creates a form of process-based mandatory access control. It is possible to restrict what a process can and cannot do. Additionally, access can be restricted to an object for any user, even root. Further, these restrictions cannot be changed by normal users. The system will soon offer role-based access control as well.
Probably the right solution for this is:
- Rename Security#Grsecurity RBAC to Security#Role-Based Access Control.
- Discuss both SELinux/Grsecurity implementations there. There is no need for the RBAC section to be Grsecurity-specific.
- I think it is best to give general recommendations here rather than something like "install Grsecurity to make your kernel secure".
- The right solution is probably to expand Security#Kernel Hardening and discuss Wikipedia:PaX and whatnot more generally, mentioning Grsecurity as an implementation.
- I do think Security#Kernel Hardening should probably be moved lower on the page, closer to Security#Mandatory access control/Security#Network and Firewalls/Security#Authenticating packages since that seems to better suit the logical flow of the article.
- I can't comment on the content since I don't know much about it, but allow me to add some notes:
- The different security models (RBAC, MAC, DAC, ACL, ...) should be compared/described separately from the individual implementations (SELinux, Tomoyo, AppArmor, ...). Meaning there should be separate sections for each group, but mainly "RBAC is significantly faster then SELinux." does not make much sense.
- There should always be provided alternatives, not just 1:1 mapping (like in case of RBAC and Grsecurity).
- Descriptions of both groups can be provided from multiple perspectives. From my experience, in these situations a comparison table is often the best solution.
- I'm not sure about the Security#Kernel Hardening section, should it focus only on security options that require patching the Arch kernel, or also those included in Arch kernel but not activated?
- I hope it makes sense...
- -- Lahwaacz (talk) 22:09, 4 September 2013 (UTC)
- +1, also on mentioning the other options. I further agree with Ndt, moving Security#Kernel Hardening down to below (or above?) Security#Mandatory_access_control and merging the bits for Security#Kernel_parameters into it is better flow, then any other options that are avail without patching into it, followed by PAX and the existing Grsecurity so those get mentioned just before MAC. If someone wants to work on that: I like the comparison/table here maybe it gives some inspiration how to expand. If not, maybe good for See also. (further comparisons are at the bottom of the link). --Indigo (talk) 18:05, 5 September 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?
- 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)
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: .
- 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)
- 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)
Removal of incorrect warning
Greetings, I have removed the warning regarding SHA512 on the password hashing section. It's true that one shouldn't use plain sha512 for password hashing, but that isn't what arch (or other Linux distributions) use or are even able to use. What they call "sha512" is crypt_sha512, analogous to cryptmd5 but with the hash function replaced. Crypt_sha512 is a strong sequential function with a configurable iteration parameter. Normal configurations are fairly slow by default and are configurable to be arbritarily slow. I also updated the text to make it clear that it used an iterated sha512 so that others would be less likely to suffer from your confusion. Cheers. --Gmaxwell (talk) 23:39, 24 December 2014 (UTC)
- I was fully aware that it runs a configurable number of sha512 iterations when I made the change. It's not enough iterations to make up for how cheap it is relative to bcrypt/scrypt and it requires very little memory so it does nothing to counter doing billions of hashes per second on a GPU. I don't care enough to argue about it but you shouldn't assume that it had anything to do with confusion. -- thestinger 23:48, 24 December 2014 (UTC)
- I have rephrased the first sentence of the following paragraph to "The default Arch hash sha512 is, however, different than plain SHA512. It is very strong and there is no need to change it." in an attempt to remove the inconsistency. Please proof-read this, since I am a no cryptography expert - the only source I was using was this very discussion. Also I am not native to English, so I can't guarantee I was grammatically correct. Here is the diff to my edit:  Kmph (talk) 20:30, 24 August 2015 (UTC)
- One more thing. Your phrasing does not state whether or not these 5000 iterations, in association with storing passwords in /etc/shadow, actually are secure. With the nearby warning, an impression is made that in might not be enough and that the wiki advises the user to use something else. You have removed this important sentence: "It is very strong and there is no need to change it". If this is appropriate, could you kindly explicitly state whether or not this default Arch's hashing is considered secure enough for normal desktop use? Kmph (talk) 21:00, 24 August 2015 (UTC)
- I'm not the expert, but I'd assume 5000 iterations is "not enough". However I don't know if 999 999 999 or any arbitray high amount is "enough" either. This assessment likely changes as hardware gets more powerful, or more efficient methods are discovered.
- The fact that the hashes are stored in
/etc/shadowshould be sufficient, but I don't know how to accurately word that ("can't be copied or cracked" is vague at best). -- Alad (talk) 21:05, 24 August 2015 (UTC)
- I have practically rewritten the section with these 3 edits, adding lots of links so that people can try to better understand this complicated process.
- Functions like bcrypt and scrypt are indeed aimed at making it more expensive to brute-force passwords with custom-hardware attacks, but if we don't tell people how to decide what function to use, and how to set it up, a warning like that is only FUD...
- — Kynikos (talk) 15:29, 28 November 2015 (UTC)
Let's forget about limits.conf?
Look rapidly at this blog post.
In short: limits.conf is useless for systemd daemons, because systemd has it's own LimitNOFILE=123456, LimitETC=50K.
This is also an issue for desktop users, because users implemented via slices, services and User Manager.
To set per-user resource-limits, now do the following:
mkdir -p /email@example.com/ cat > /firstname.lastname@example.org/limits.conf << EOF [Service] LimitNFILE=131072 EOF systemd daemon-reload systemd restart user@1000
1000 -- is a user's uid. Optional.
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 recommends setting/enabling
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)
grsecurity End of Support
There was a proposal to archive, I think this is a mistake until we know more about how this shakes out. There have been some rumblings that Gentoo Hardened may take over primary development of a branch of the 3.1 patchset. Alternatively, I've already reached out to the Grsecurity team to ask about individual licensing. As Arch is an open source community, it's not unreasonable that there could be some very reasonable individual license. If so, we could probably move the package to the AUR, and users would need to buy a license.
Finally, the last released patch was for 4.9, which is a stable kernel branch -- there's no reason to kill the wiki just yet, as 4.9 will not be EOL for a long time.
- 3.1 doesn't work on Arch since systemd requires at least 3.14 or higher, and I somehow doubt that the Arch developers or TUs are willing to cash out for a grsecurity license. Regarding the stance on 4.9, see this post by the maintainer: https://lists.archlinux.org/pipermail/arch-general/2017-April/043612.html —This unsigned comment is by Alad (talk) 19:05, 27 April 2017. Please sign your posts with ~~~~!
- There's a gradm ABI version included in the version, but it doesn't have the importance that they think it does. The grsecurity version is the kernel version + the grsecurity timestamp. That 3.1 version is only relevant to RBAC / gradm, and RBAC certainly has a lot of improvements without that version changing since I think it's only for breaking changes to the ABI. -- thestinger 16:22, 29 April 2017 (UTC)
- If things change and grsecurity is available in some form to Arch Linux users, I don't think it would be hard to resurrect the page (or parts of it) from the archive. -- Rdeckard (talk) 23:33, 28 April 2017 (UTC)
- There isn't going to be individual licensing. If someone takes over maintenance, it needs to be renamed from PaX and grsecurity so there will need to be a new name for this page and a bunch of configuration and tool naming may end up being updated to match the new name if it's a true fork with active development. Maintaining the 4.9 patch is a dead end and if that's all that happens, it's over. Either way, I'm not maintaining it anymore including paxd and the exceptions being a dead project. I saw this coming for a long time, so I haven't been putting much work into it for a while and now it's over. The most I'll consider is a package enabling the Kernel Self Protection Project features... which is such a tiny portion of what was provided. Key features like RAP are going to be unavailable for 5+ years if they even land at all. -- thestinger 16:17, 29 April 2017 (UTC)
Kernel hardening - disabling jit compiler
Currently, this page advises to disable bpf jit compiler by setting net.core.bpf_jit_enable to 0. Doing so causes error:
$ sudo sysctl -w net.core.bpf_jit_enable=0 sysctl: setting key "net.core.bpf_jit_enable": Invalid argument net.core.bpf_jit_enable = 0
This commit in the linux repo from January seems to indicate that disabling the jit compiler is not longer possible (or desirable): commit on Github torvalds/linux. There is however a net.core.bpf_jit_harden flag available. I do not have the necessary knowledge to decide on what the best course of action is and edit the pages. Should the Keep BPF JIT compiler disabled section be removed? Is thebpf_jit_harden flag advisable? Gthau (talk) 18:34, 26 March 2018 (UTC)
I don't see why periodically changing the master password would improve anything.
- I agree. If the password is cryptographically secure and no one else has access to it, it would be best to leave it unchanged.
- The reasoning would be that you can't 100% control whether your master pw leaks anywhere, e.g. you may type it by mistake when asked for another password, or even a username field, and get it logged somewhere, or you may paste it somewhere where you didn't want to, and you may not realize that, or it may get recorded by a keylogger etc. This may not mean that somebody else finds the pw immediately, it may lie there for a while before that happens, but if meanwhile you changed it, it won't be a problem anymore.
- Anyway yes, that's paranoid mode, the statement may need expansion with the reasoning.
- -- Kynikos (talk) 22:52, 1 July 2018 (UTC)
- If you know your master password by heart and your master password is significantly different than your other passwords, you should be able to rule out leaking it by mistakenly entering it, provided that you have the minimum of discipline required by computer security. You should obviously only enter you master password in your password manager on devices that you trust. A keylogger means either someone had physical access to your computer or you have a malware, in either case on this level of paranoia you have lost the game and changing your master password won't help you.
- --Larivact (talk) 04:26, 2 July 2018 (UTC)
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).
- Merge sections with respective articles
- Move sections with enough content to dedicated articles
- Create new articles for article-worthy topics
- 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)
- 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)
- If you own a domain name, set a Sender Policy Framework policy to combat email spoofing.
- 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 . 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)
Restricting loadable module to those signed in the kernel source tree.
By setting the kernel parameter `module.sig_enforce=1`, only modules that are shipped with the package that provides the kernel (linux, linux-hardened, etc...) can be loaded.
On the other hand, if someone hacks the build directory where is built the linux package, he can retrieve the file cert/signing_key.pem and sign its own modules. It would be the responsibility of the Archlinux maintainer that build the linux package to make sure this file is not accessible.
This considered, may it be a good idea to add a section about restricting addable modules to those compiled with the kernel?
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.
If hidepid is enabled there is a minor issue with rtkit-daemon errors showing up in syslog.
pam_tally and pam_tally2 deprecation
These are all deprecated according to this commit https://github.com/linux-pam/linux-pam/commit/f49166c7d8f3ae2c9d337154f7e5dc50d41ab6bf
This deprecation extends to sections like 'Enforcing strong passwords using pam_cracklib', 'Enforce a delay after a failed login attempt' and such.