Difference between revisions of "Talk:Security"

From ArchWiki
Jump to: navigation, search
(more)
(Todo: kernel options are now covered a bit - suggest specific ones if there are more)
Line 16: Line 16:
 
*browser security (requestpolicy, noscript, sand-boxing browser)
 
*browser security (requestpolicy, noscript, sand-boxing browser)
 
*PAX/<s>grsecurity</s>
 
*PAX/<s>grsecurity</s>
*kernel options (which could be added as FRs on the bug tracker)
 
 
*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])
 
*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])
 
* document hidepid mount option
 
* document hidepid mount option

Revision as of 10:09, 31 March 2014

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
  • SSH/fail2ban
  • use (enhanced?) ACL on partitions
  • quotas
  • limits/cgroups
  • TMOUT for root shell
  • 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)
  • document hidepid mount option
  • 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)