Talk:Security-Enhanced Linux

message: setenforce 0 command does not disable SELinux. Simply enable permissive mode where all policy violations are logged. When selinux is disabled nothing is done, no policy is loaded, no logs are generated, nothing is blocked.  — Preceding unsigned comment added by 186.212.154.237 (talk) 21:11, 9 October 2011 (UTC)
thread_title:  Usage 

message: A version of this article contained text originally derived from the public domain NSA website at http://www.nsa.gov/selinux/faq.htm
As text from a U.S. Federal Government agency without any copyright notice, this can be regarded as a public domain resource that can be copied into Wikipedia, or used for any other purpose. --The Anome
:The FAQ has since moved to http://www.nsa.gov/selinux/info/faq.cfm. Twinxor t 06:20, 4 October 2005 (UTC)
thread_title:  Text's License 

message: Anyone who has a clue what FLASK is probably already knows that Security-Enhanced Linux is an an example of this.  As it stands, without explanation, it just serves to confuse the reader.  It is the sort of comment that you'd expect someone to write in an exam to demonstrate their knowledge.Dejvid 10:16, 9 April 2006 (UTC)
thread_title: FLASK is jargon

message: I added a criticism section that included a the statement "SELinux has been criticized as departing from traditional Unix security concepts, because its permissions are based on labels rather than using file paths." Someone reverted it, pointing out that traditional Unix security is not based on paths. 
I agree that the wording could have been clearer, but I was trying to note that people have criticized SELinux labels as unfamiliar and different from the traditional DAC. Using DAC permissions can be managed with commands like "chmod ug+rw /path/to/file". So although the actual permission is stored at the inode, there is still an interface based on the file path.
I realize that there are advantages to SELinux's labels; I just wanted to say that this has been a criticism. Feel free to clarify the article if you still think it's misleading, but I don't think the section should be removed entirely. -- Wmahan. 16:42, 11 May 2006 (UTC)
thread_title: Labels vs. file paths

message: Someone put this sentence in the end if the "Implementations" section.
 it has been available
I don't know what that is and why was it there, but I've removed it.-- Ido50 11:07, 23 August 2006 (UTC)
thread_title: "It has been available"

message: two quotes:
 (SELinux has been integrated into version 2.6 series of the Linux kernel, and 
 separate patches are now unnecessary; the above is a historical quote.)
 It has no concept of a "root" super-user...
from this i could conclude that no linux using a 2.6 or above kernel has super-user rights. i'm not a linux guy, but i don't think this is correct. could someone please clarify which components of SELINUX exactly have been integrated into the standard linux kernel, and which are still up to the distribution to choose?
What this states is that SELinux security access controls does not automatically map to Unix user-spaces.  This means that even the root user may be hindered by SELinux from performing certain tasks.  This would be useful in the event that a system administrator is working with a system that contains classified information they shouldn't be able to access.  Perhaps this should be clarified. Spacez320 (talk) 03:30, 8 May 2009 (UTC)
thread_title:  no root in linux any more? 

message: I have uploaded a photo of Russell Coker if people want to create an article about him or use it later. - SimonLyall 12:12, 27 January 2007 (UTC)
thread_title:  Russell Coker photo 

message: The criticism section of the main page is marked as NPOV-disputed, but there is no explanation on this talk page of what is the matter (I guess that friends of path-based solutions could find the section controversial, but it doesn't make it violating NPOV). Removing the mark as it isn't applied properly. Ceplm 22:33, 25 March 2007 (UTC)
thread_title:  NPOV disputed? 

message: I do not believe this section and its companion in AppArmor represent a neutral point of view, but instead both appear to be written to promote the view that SELinux's object-based model is preferable to AppArmor's path-based model.  
Furthermore, I do not see how abstract reasoning of the form "the kernel does this and not that" is relevant or even factually accurate.  And while the article says "the access control enforcement mechanisms of Unix kernels have never relied upon pathnames as their basis, as paths are ambiguous identifiers in Unix systems and do not identify the real objects (the inodes)", in fact, whether a process can read or alter a file is very much pathname-dependent in UNIX.  The strength of an SELinux approach might well lie in the fact that it provides a mechanism that differs from the pathname-based approach that so much of UNIX uses.
In its current form, I do not see the section or discussion contributing anything to the article, so I would suggest simply deleting the "Criticism" section and have each article mention that an alternative approach exists and reference the alternative approach.  
The technical advantages and drawbacks of each approach can easily and more usefully be discussed without specific reference to the other by discussing design tradeoffs ("the designers of methods Q wanted to have property X even if that made property Y harder to achieve") and specific examples ("method Q can handle specific example A, but not specific example B").  Of course, statements of such tradeoffs and examples should be based on references to the literature, not the imagination of the Wikipedia contributors.
Jcarnelian 00:12, 5 May 2007 (UTC)
thread_title:  NPOV disputed 

message: The last paragraph in the preceding section "AppArmor was created in part as an alternative to SELinux, which critics claim is difficult for administrators to set up and maintain. Unlike SELinux, which is based on applying labels to files, ..." seems fairly biased as well. Which critics are we talking about? Which administrators found it difficult? I could not find a reference on the AppArmor website that said it was created as an alternative to SELinux. Why are path-based controls easier to manage than file-based?
A better approach would be to describe how mandatory access controls have been implemented in AppArmor, along with the strengths and weaknesses of this approach. —The preceding unsigned comment was added by 140.142.198.82 (talk) 01:08, 8 May 2007 (UTC)
thread_title:  NPOV Disputed 

message: Since there haven't been any objections, I deleted the "Criticism" section.  I think such a section would make sense in principle, but would need to be written from a NPOV and document its statements with references to credible sources (not blog postings).  I hope someone will take the time to do that. Jcarnelian 11:10, 15 July 2007 (UTC)
thread_title:  Replaced "Criticism" section 

message: Please provide evidence that Unix and Linux use a combination of path-based and inode-based access control if you are going to make such a claim in the Other Systems section.  Only the inode's attributes (ownership, mode, optionaly ACL) are relevant to Unix or Linux discretionary access control decisions, not the pathname by which the inode was accessed.
One might argue that path matters in the sense that one must have search access to each directory in the path in order to access the file at all, but those are still inode-based checks, on each directory inode in the path.  Further, if one can reach the file at all by any path, the permissions granted do not depend on the path by which the file was accessed, so the decision is not dependent on the pathname. (anonymous)
Only the inode's attributes (ownership, mode, optionaly ACL) are relevant to Unix or Linux discretionary access control decisions, not the pathname by which the inode was accessed.
Whether a file is accessible depends on the accessibility of all its path components.   Moving a file from one directory to another can make it readable or unreadable without any permissions changing in any inode.  
If a security policy is to be analysed to prove that it meets the required security goals then all hard links must have the same access control.
I have no problem proving that AppArmor meets my required security goals.  It has its own semantics, but they can be reasoned about easily and formally.  Jcarnelian (talk) 20:55, 21 June 2008 (UTC)
thread_title:  Unix and Linux use a combination of path-based and inode-based control? 

message: Most of the items listed within the Features section seem subjective and not tied to any real SELinux functionality. Spacez320 (talk) 03:32, 8 May 2009 (UTC)
thread_title:  Features 

message: What does SELinux do exactly? What can MACs restrict? System calls, what about them? In its present shape the article is all about buzzwords and unsubstantiated claims. 85.221.142.5 (talk) 23:31, 9 November 2009 (UTC)
thread_title:  full of buzzwords 

message: There is a citation needed that says that SELinux was dropped from Familiar Linux due to JFFS2 issues.  I can't find this anywhere.  I can't really find anything with Familiar Linux and SELinux in the same place at the same time.  Not being that familiar with Familiar Linux is this true?  Can we remove that paragraph until a citation exists?  --W4otn (talk) 18:55, 23 November 2009 (UTC)
thread_title:  Familiar Linux and SELinux 

message: The NSA put much shit in software systems last years. The "work factor reduction field" in Lotus or the NSAKEY in Windows are only few examples. Did noone critizise that the NSA wrote security code in the Linuxkernel? Bad documentation, noone excactly knows what is does. Everywhere buzzwords... The article said it "bypassing of application security mechanisms" and it is in every linux distribution? eh???
I'm a paranoid idiot? 92.206.57.47 (talk)
Yes, you're a paranoid idiot.  — Preceding unsigned comment added by 200.83.142.195 (talk) 22:50, 27 February 2021 (UTC)
replies: text: It's open source, so anything they put in it you can see. Such software has intelligence uses but it's not as simple as assuming there's a backdoor in there, any backdoor in open source software would be visible to everyone.2601:140:9500:7F00:4CD4:EFEC:152C:3D52 (talk) 21:39, 19 January 2023 (UTC)
thread_title:  NSA wrote SELinux?! 

message: I removed the controversy section. All it provided was a couple of quotes, neither of which provide any evidence that the NSA deliberately compromised SELinux. I don't mind the section, I just think it should be more interesting than somebody with no apparent credentials in cryptography saying, "I have a long bet that SELinux is an NSA backdoor". 76.230.227.175 (talk) 13:20, 31 December 2010 (UTC)
replies: text: I removed the section again. I've added a see also link. Widefox; talk 17:00, 29 May 2014 (UTC)
replies: text:  Totally agreed, much better when left to a "See also" link. — Dsimic (talk | contribs) 18:02, 1 June 2014 (UTC)
replies: text: I removed the see-also link to Linus Torvalds because it was removed in this revision (in case anyone wants to put some of it back here). GreenReaper (talk) 22:13, 21 January 2016 (UTC)
thread_title:  Controversy 

message: The sentence:
"On the other hand, data that is inaccessible in SELinux may become accessible when applications update the file by replacing it with a new version — a frequently used technique — while AppArmor would continue to deny access to the data."
seems incorrect to me. Perhaps what was meant was:
"On the other hand, data that is accessible in SELinux may become inaccessible when applications update the file by replacing it with a new version — a frequently used technique — while AppArmor would continue to allow access to the data."
,which I believe is correct.
Can anyone defend the original statement? 121.45.218.101 (talk) 22:19, 1 November 2012 (UTC)
thread_title:  Dubious sentence on hard links 

message: As far as I know (and as it is described within the introduction) SELinux is an optional security module, which can be "plugged in" to the kernel. Instead of SELinux, any other Linux Security Module could be used, or even none. So from my point of view, SELinux has not been integrated into the kernel (it's just an optional plugin). Therefore, I think the comment "(SELinux has been integrated into version 2.6 series of the Linux kernel, and separate patches are now unnecessary; the above is a historical quotation.)" should be changed in order to reflect this. Also, I was unable to find that citation from the NSA Security-enhanced Linux Team (which describes SELinux as being a set of patches) in the given source... is this the correct link? GGShinobi (talk) 02:40, 7 October 2013 (UTC)
thread_title:  Integrated into the kernel? 

message: "and managed by Dr. Charles Testa"
No source given, Chuck Testa is a taxidermist who became a meme when people started passing around his tv commercial on the internet. This might be a prank, or it might be an unrelated person named Charles Testa.
https://www.youtube.com/watch?v=LJP1DphOWPs
http://knowyourmeme.com/memes/nope-chuck-testa
Leaving this to more capable Wikipedians.
70.184.243.177 (talk) 19:11, 18 November 2014 (UTC)
replies: text: Hello!  Yeah, it looks like a possible vandalism, thanks for pointing it out.  I've  that was unsourced and already marked with  since October 2011. — Dsimic (talk | contribs) 06:14, 19 November 2014 (UTC)
thread_title:  Possible vandalism? 

message: footnote 36 ( SELinux Related Work". NSA.gov.) now gets a 404, I guess it's moved, don't have the new location
Graemev2 (talk) 16:26, 31 October 2021 (UTC)
thread_title:  Dead Link  

message: I suggest this page should be at SELinux. As per WP:OFFICIALNAMES, common usage is more important than the official name.
Regards, Ben Aveling 22:59, 9 November 2021 (UTC)
thread_title:  Proposed Move [[Security-Enhanced Linux]] -> [[SELinux]] 

message: I noticed the archived list of contributors is no longer available at the NSA site and they seem to have stopped caring about it. It would make sense to list not just the corporations but also the known original contributors to SELinux listed here:
https://web.archive.org/web/20081018034429/http://www.nsa.gov/selinux/info/contrib.cfm
I would not mind doing so myself, but what would be the best format? A table? A summarized list with the contributions as listed in the site? The names only? I would argue those people deserve to still have their names somewhere readily recognizable.  — Preceding unsigned comment added by Heapintrouble (talk • contribs) 21:25, 24 November 2021 (UTC)
thread_title:  Merge a list of the original contributors in History