|This is the talk page for discussing improvements to the Security-Enhanced Linux article.|
|This article is of interest to the following WikiProjects:|
- 1 Usage
- 2 SELinux for BSD
- 3 Text's License
- 4 FLASK is jargon
- 5 Labels vs. file paths
- 6 "It has been available"
- 7 no root in linux any more?
- 8 Russell Coker photo
- 9 NPOV disputed?
- 10 NPOV disputed
- 11 NPOV Disputed
- 12 Replaced "Criticism" section
- 13 Unix and Linux use a combination of path-based and inode-based control?
- 14 Features
- 15 full of buzzwords
- 16 Familiar Linux and SELinux
- 17 NSA wrote SELinux?!
- 18 Controversy
- 19 Dubious sentence on hard links
- 20 Integrated into the kernel?
- 21 Possible vandalism?
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 18.104.22.168 (talk) 21:11, 9 October 2011 (UTC)
SELinux for BSD
Ok I have searched around and honestly I can find no evidence at all that you could apply these patches to any member of the BSD family. It simply doesn't make sense that you could apply the same set of patches to a 2.4 or 2.6 Linux Kernel and NetBSD. FLASK has been ported to FreeBSD via the TrustedBSD project but porting a portion of the software isn't the same as having a set of patches available to BSD. Also see: http://www.nsa.gov/research/selinux/list-archive/0108/thread_body15.shtml
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)
FLASK is jargon
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)
Labels vs. file paths
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)
"It has been available"
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)
no root in linux any more?
(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)
Russell Coker photo
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)
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)
I'm not sure if it is NPOV or not, but the second sentence I'm quoting doesn't quite make sense following the first: "Critics say that due to its complexity, even experienced users are likely to configure SELinux in an unsafe manner or disable it altogether, leaving the system vulnerable to attacks. However, because SE Linux only provides restrictive controls and cannot permit an operation that Unix permissions deny, this is not possible." It certainly *is* possible that a user may consider SELinux too complex and disable it for that reason. 22.214.171.124 00:50, 24 April 2007 (UTC)
I've used Linux continuously since its earliest days (I'm number 119 in the Linux Counter) so I'm in a good position to distinguish "complex" from "incomprehensible." The problem with SELinux is not that it's complex but that its documentation is incomprehensible to anyone that hasn't taken a class in it. In particular it is hard to imagine how the man pages for chcon, restorecon, runcon, secon, fixfiles, and SELinux itself could be less useful. Someone needs to explain to Dan Walsh, the author of this miserable documentation, how to write documentation. First, it would have been helpful if at least one of these man pages contained at least one example. Second, it would have been even more helpful if Walsh had given some idea in the documentation of how one is supposed to configure an out-of-the-box installation of Fedora 8 (for example) so that it doesn't complain every few seconds about SELinux preventing access to this or that file. Nowhere does the documentation supplied by RedHat explain what labels to give files to make SELinux happy. I'd love to have a secure Linux box, but the closest I can get without bringing my system to its knees is to run SELinux in permissive mode and lose sleep over all those cryptic messages. Turning SELinux off altogether seems to be the only reasonable thing to do with this apology for a security system. Why RedHat bothers to keep distributing this junk with Fedora is a complete mystery to me. --Vaughan Pratt (talk) 05:44, 26 October 2008 (UTC)
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)
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 126.96.36.199 (talk) 01:08, 8 May 2007 (UTC).
Replaced "Criticism" section
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)
OK, tried to write a NPOV discussion of differences to alternative systems myself. I hope this will be a reasonable starting point for people to build on. Jcarnelian 11:43, 15 July 2007 (UTC)
Unix and Linux use a combination of path-based and inode-based control?
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.
full of buzzwords
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. 188.8.131.52 (talk) 23:31, 9 November 2009 (UTC)
Familiar Linux and SELinux
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)
NSA wrote SELinux?!
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 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". 184.108.40.206 (talk) 13:20, 31 December 2010 (UTC)
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? 220.127.116.11 (talk) 22:19, 1 November 2012 (UTC)
Integrated into the kernel?
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)
"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.
Leaving this to more capable Wikipedians.