Difference between revisions of "Talk:Security"

From ArchWiki
Jump to: navigation, search
m
m (pam_tally: re)
 
(65 intermediate revisions by 15 users not shown)
Line 3: Line 3:
 
*descriptions/rationale for all the links to other articles (MAC)
 
*descriptions/rationale for all the links to other articles (MAC)
 
*base64 /dev/urandom | dd bs=1 count=10 2>/dev/null
 
*base64 /dev/urandom | dd bs=1 count=10 2>/dev/null
*[[SSH]]/[[fail2ban]]
 
 
*use (enhanced?) ACL on partitions
 
*use (enhanced?) ACL on partitions
 
*[[Disk quota|quotas]]
 
*[[Disk quota|quotas]]
 
*limits/cgroups
 
*limits/cgroups
*TMOUT for root shell
 
 
*sudo timeout
 
*sudo timeout
 
*DNSSEC
 
*DNSSEC
Line 15: Line 13:
 
*rvim/rgvim
 
*rvim/rgvim
 
*browser security (requestpolicy, noscript, sand-boxing browser)
 
*browser security (requestpolicy, noscript, sand-boxing browser)
*PAX/grsecurity
+
*PAX/<s>grsecurity</s>
*merge [[Hardening Guides]] into this article
+
*stack protector gcc flag: Put some text in the page indicationg Archlinux has it by default (See: [https://bugs.archlinux.org/task/18864 FS#18864])
*kernel options (which could be added as FRs on the bug tracker)
+
* run services as non-root (mention that Arch does this where possible by default - but it needs improvement via feature requests)
*[[DeveloperWiki:Package signing|Package signing]]
+
* run services in clean namespaces
*<s>stack protector gcc flag</s> (See: [https://bugs.archlinux.org/task/18864 FS#18864])
+
* run services in chroots
* document hidepid mount option?
+
* mention issues with sudo (any X11 application can grab the password, and it is a large setuid binary with potential vulnerabilities)
 
--[[User:Thestinger|thestinger]] 18:09, 11 January 2011 (EST), --[[User:Det|Det]] ([[User talk:Det|talk]]) 11:35, 3 January 2013 (UTC),
 
--[[User:Thestinger|thestinger]] 18:09, 11 January 2011 (EST), --[[User:Det|Det]] ([[User talk:Det|talk]]) 11:35, 3 January 2013 (UTC),
 
--[[User:Flu|Flu]] ([[User talk:Flu|talk]]) 13:49, 19 April 2013 (UTC)
 
--[[User:Flu|Flu]] ([[User talk:Flu|talk]]) 13:49, 19 April 2013 (UTC)
 +
-- [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 22:45, 12 August 2013 (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,
 +
[[User:AdamT|AdamT]] ([[User talk: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.
 +
:-- [[User:Kynikos|Kynikos]] ([[User talk: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 {{ic|/root}}, which I think by default are not {{ic|700}} (they should be) should be added to [[Security#Filesystem permissions]].
 +
::* '''Umask restrictions''' -> We should talk about {{ic|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 {{ic|/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.
 +
::-- [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 05:09, 3 August 2013 (UTC)
 +
:::If you want to start working in this direction, go for it! :) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:04, 5 August 2013 (UTC)
 +
 +
== Grsecurity sections ==
 +
 +
We now have three sections devoted only to Grsecurity. What can we do about this?
 +
 +
The [https://wiki.archlinux.org/index.php?title=Security&diff=272330&oldid=272327 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 [https://www.cs.virginia.edu/~jcg8f/GrsecuritySELinuxCaseStudy.pdf 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.
 +
 +
[[Security#Kernel Hardening]] is only about [[Grsecurity]] but I am not sure if it should be merged into [[Security#Mandatory access control|Mandatory access control]] as suggested.
 +
 +
* 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.
 +
 +
-- [[User:Ndt|Ndt]] ([[User Talk:Ndt|talk]]) 21:36, 4 September 2013‎ (UTC)
 +
 +
: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...
 +
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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 [http://www.cyberciti.biz/tips/selinux-vs-apparmor-vs-grsecurity.html 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). --[[User:Indigo|Indigo]] ([[User talk: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 {{ic|noboby}} for some tipe of scripts. Is there any person who can explain further and add a note in this article?
 +
 +
-- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 11:29, 13 September 2013 (UTC)
 +
 +
: Following the [[Wikipedia:Principle of least privilege|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. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:32, 13 September 2013 (UTC)
 +
::It's not actually a good idea to do this. Processes running as {{ic|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. [[User:Thestinger|thestinger]] ([[User talk: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. - [[User:Ndt|Ndt]] ([[User talk: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 [http://world.std.com/~reinhold/diceware.html Diceware] (mentioned in [[Disk_encryption#Choosing_a_strong_passphrase]], which is linked to at the end of the section) ? --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 23:48, 31 August 2014 (UTC)
 +
 +
::I've added some clarifications to that sentence: [https://wiki.archlinux.org/index.php?title=Security&diff=333453&oldid=333379].
 +
::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.
 +
::-- [[User:Kynikos|Kynikos]] ([[User talk: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)? -- [[User:Alad|Alad]] ([[User talk: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. -- [[User:Kynikos|Kynikos]] ([[User talk: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 [[User:Redsolja|Redsolja]] ([[User talk:Redsolja|talk]]) 15:48, 26 April 2015 (UTC)
 +
 +
::::::Thank you, very well done for a first edit! — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:34, 27 April 2015 (UTC)
 +
 +
== Removal of incorrect warning ==
 +
 +
:''Moved from [[User_talk:thestinger]].'' -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:01, 25 February 2015 (UTC)
 +
 +
Greetings, I have removed [https://wiki.archlinux.org/index.php?title=Security&diff=307743&oldid=307742 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. --[[User:Gmaxwell|Gmaxwell]] ([[User talk: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. -- [[User:thestinger|thestinger]] 23:48, 24 December 2014 (UTC)
 +
 +
::Reverted OP's removal a while ago, so this can be closed. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:23, 19 January 2015 (UTC)
 +
 +
:::It may not be wrong, but it’s still misleading, and conflicts with the immediately following paragraph. Is there a nice way to change each to satisfy everyone? -- [[User:Charmander|Charmander]] ([[User talk:Charmander|talk]]) 19:12, 19 January 2015 (UTC)
 +
 +
:: I have rephrased the first sentence of the following paragraph to "''The default Arch hash [[SHA_password_hashes|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: [https://wiki.archlinux.org/index.php?title=Security&type=revision&diff=393653&oldid=383265] [[User:Kmph|Kmph]] ([[User talk:Kmph|talk]]) 20:30, 24 August 2015 (UTC)
 +
 +
::: I don't understand what this changes - how is the SHA512 sum ''different'' (considering thestinger's argument above) ? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:36, 24 August 2015 (UTC)
 +
 +
:::: AFAIK the Arch's SHA512 iterates, while plain SHA512 doesn't? Anyway, if what I wrote is wrong, please revert it. But if you do, please do fix the inconsistency in a more competent way. The original phrasing is misleading and just cannot last any more. [[User:Kmph|Kmph]] ([[User talk:Kmph|talk]]) 20:42, 24 August 2015 (UTC)
 +
 +
::::: See [https://wiki.archlinux.org/index.php?title=Security&diff=393663&oldid=393653]. Perhaps we should also add how the number of iterations could be increased (maximum is 999 999 999, according to man passwd). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:49, 24 August 2015 (UTC)
 +
 +
:::::: Added with [https://wiki.archlinux.org/index.php?title=Security&type=revision&diff=393665&oldid=393663]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:56, 24 August 2015 (UTC)
 +
:::::: edit: going to undo this since I don't know what's meant above with "not enough". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:57, 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? [[User:Kmph|Kmph]] ([[User talk: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 {{ic|/etc/shadow}} should be sufficient, but I don't know how to accurately word that ("can't be copied or cracked" is vague at best). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:05, 24 August 2015 (UTC)
 +
 +
::::::::: I'm honestly unsure if I'm nitpicking or if this is a serious problem. Anyway I [https://wiki.archlinux.org/index.php?title=Security&type=revision&diff=393676&oldid=393670 have put] a Template:Expansion. Hope that's OK? [[User:Kmph|Kmph]] ([[User talk:Kmph|talk]]) 21:23, 24 August 2015 (UTC)
 +
 +
:::::::::: Sure, thanks. :) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:02, 24 August 2015 (UTC)
 +
 +
:::::::::::I have practically rewritten the section with [https://wiki.archlinux.org/index.php?title=Security&diff=410426&oldid=409966 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...
 +
:::::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:29, 28 November 2015 (UTC)
 +
 +
== Let's forget about limits.conf? ==
 +
 +
Look rapidly at [https://sskaje.me/systemd-ulimit/ 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:
 +
<pre>
 +
mkdir -p /etc/systemd/system/user@1000.service.d/
 +
cat > /etc/systemd/system/user@1000.service.d/limits.conf << EOF
 +
[Service]
 +
LimitNFILE=131072
 +
EOF
 +
systemd daemon-reload
 +
systemd restart user@1000
 +
</pre>
 +
 +
'''1000''' -- is a user's uid. Optional.
 +
 +
The archwiki is full of useless limits.conf documentation, it is time to update it, or i've missing something? [[User:Shahid|Shahid]] ([[User talk:Shahid|talk]]) 09:51, 16 December 2015 (UTC)
 +
 +
:: Oops, looks like all this info valid only for dbus-activated user apps like gnome-terminal.
 +
[[User:Shahid|Shahid]] ([[User talk:Shahid|talk]]) 14:14, 16 December 2015 (UTC)
 +
 +
== pam_tally ==
 +
 +
According to the PAM SAG pam_tally is deprecated and should be replaced by pam_tally2. I suggest to update the page accordingly. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 20:20, 7 February 2016 (UTC)
 +
 +
:Is the information in the manpage for pam_tally2 accurate? I don't know PAM, and I'm not fully comfortable with changing the page without asking first. [[User:Crashlog|Crashlog]] ([[User talk:Crashlog|talk]]) 00:01, 18 June 2016 (UTC)
 +
 +
::Good you ask, such should indeed be tested before updating. Please check [https://bugs.archlinux.org/task/42120#comment148179] as input when you go about changing the section. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:58, 18 June 2016 (UTC)
 +
 +
:::If pam_tally2 is going to be deprecated soon anyway in favour of pam_faillock, then updating the page right now seems a bit pointless. [[User:Crashlog|Crashlog]] ([[User talk:Crashlog|talk]]) 11:28, 18 June 2016 (UTC)
 +
 +
::::Well, the faillock module has not landed in the package for years, that part remains to be seen. Updating is useful I think, because due to the nature of the pam project they rarely remove modules (since that can severly break existing installations). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:40, 19 June 2016 (UTC)
 +
 +
::I've run into a couple of problems:
 +
::#pam_tally, the original one, seems to have a default configuration in place, and I'm not sure what steps are needed to completely disable it. Is it enough to remove its line from {{ic|/etc/pam.d/system-login}}, or is there something more to be done?
 +
::#In [https://bugs.archlinux.org/task/42120#comment148179] it's mentioned that pam_tally2 should be added to account pam_tally2.so in the stack as well, but I don't know this should be done. I've gathered that I need to add the line {{ic|account required pam_tally2.so}} to some account section somewhere, but I don't know which file specifically I should be editing.
 +
::I would suggest that this be left to someone who has a better understanding of how PAM works. --[[User:Crashlog|Crashlog]] ([[User talk:Crashlog|talk]]) 16:37, 21 June 2016 (UTC)

Latest revision as of 16:37, 21 June 2016

Todo

  • Update "Lockout user after three failed login attempts", file mentioned no longer contains those lines ?
  • 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)

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

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:
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)

Grsecurity sections

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:

Security#Kernel Hardening is only about Grsecurity but I am not sure if it should be merged into Mandatory access control as suggested.

-- Ndt (talk) 21:36, 4 September 2013‎ (UTC)

I can't comment on the content since I don't know much about it, but allow me to add some notes:
  1. 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.
  2. There should always be provided alternatives, not just 1:1 mapping (like in case of RBAC and Grsecurity).
  3. 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?

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

Removal of incorrect warning

Moved from User_talk:thestinger. -- Alad (talk) 16:01, 25 February 2015 (UTC)

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)
Reverted OP's removal a while ago, so this can be closed. -- Alad (talk) 12:23, 19 January 2015 (UTC)
It may not be wrong, but it’s still misleading, and conflicts with the immediately following paragraph. Is there a nice way to change each to satisfy everyone? -- Charmander (talk) 19:12, 19 January 2015 (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: [2] Kmph (talk) 20:30, 24 August 2015 (UTC)
I don't understand what this changes - how is the SHA512 sum different (considering thestinger's argument above) ? -- Alad (talk) 20:36, 24 August 2015 (UTC)
AFAIK the Arch's SHA512 iterates, while plain SHA512 doesn't? Anyway, if what I wrote is wrong, please revert it. But if you do, please do fix the inconsistency in a more competent way. The original phrasing is misleading and just cannot last any more. Kmph (talk) 20:42, 24 August 2015 (UTC)
See [3]. Perhaps we should also add how the number of iterations could be increased (maximum is 999 999 999, according to man passwd). -- Alad (talk) 20:49, 24 August 2015 (UTC)
Added with [4]. -- Alad (talk) 20:56, 24 August 2015 (UTC)
edit: going to undo this since I don't know what's meant above with "not enough". -- Alad (talk) 20:57, 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/shadow should 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'm honestly unsure if I'm nitpicking or if this is a serious problem. Anyway I have put a Template:Expansion. Hope that's OK? Kmph (talk) 21:23, 24 August 2015 (UTC)
Sure, thanks. :) -- Alad (talk) 22:02, 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 /etc/systemd/system/user@1000.service.d/
cat > /etc/systemd/system/user@1000.service.d/limits.conf << EOF
[Service]
LimitNFILE=131072
EOF
systemd daemon-reload
systemd restart user@1000

1000 -- is a user's uid. Optional.

The archwiki is full of useless limits.conf documentation, it is time to update it, or i've missing something? Shahid (talk) 09:51, 16 December 2015 (UTC)

Oops, looks like all this info valid only for dbus-activated user apps like gnome-terminal.

Shahid (talk) 14:14, 16 December 2015 (UTC)

pam_tally

According to the PAM SAG pam_tally is deprecated and should be replaced by pam_tally2. I suggest to update the page accordingly. -- Nudin (talk) 20:20, 7 February 2016 (UTC)

Is the information in the manpage for pam_tally2 accurate? I don't know PAM, and I'm not fully comfortable with changing the page without asking first. Crashlog (talk) 00:01, 18 June 2016 (UTC)
Good you ask, such should indeed be tested before updating. Please check [5] as input when you go about changing the section. --Indigo (talk) 09:58, 18 June 2016 (UTC)
If pam_tally2 is going to be deprecated soon anyway in favour of pam_faillock, then updating the page right now seems a bit pointless. Crashlog (talk) 11:28, 18 June 2016 (UTC)
Well, the faillock module has not landed in the package for years, that part remains to be seen. Updating is useful I think, because due to the nature of the pam project they rarely remove modules (since that can severly break existing installations). --Indigo (talk) 10:40, 19 June 2016 (UTC)
I've run into a couple of problems:
  1. pam_tally, the original one, seems to have a default configuration in place, and I'm not sure what steps are needed to completely disable it. Is it enough to remove its line from /etc/pam.d/system-login, or is there something more to be done?
  2. In [6] it's mentioned that pam_tally2 should be added to account pam_tally2.so in the stack as well, but I don't know this should be done. I've gathered that I need to add the line account required pam_tally2.so to some account section somewhere, but I don't know which file specifically I should be editing.
I would suggest that this be left to someone who has a better understanding of how PAM works. --Crashlog (talk) 16:37, 21 June 2016 (UTC)