Talk:Security-Enhanced Linux

From Wikipedia, the free encyclopedia

	This article is part of the Linux WikiProject, a group of Wikipedians interested in improving the encyclopaedic coverage of articles relating to Linux, and who are involved in developing and proposing standards for their content, presentation and other aspects. If you would like to participate, please visit the project page, where you can join the project and see a list of open tasks.
???	This article has not yet received a rating on the quality scale.

	This article is within the scope of the Military history WikiProject. If you would like to participate, please visit the project page, where you can join the project and see lists of open tasks and regional and topical task forces. To use this banner, please see the full instructions.
Start	This article has been rated as Start-Class on the quality scale.
Additional information and associated task forces: This article has been checked against the following criteria for B-Class status: Referencing and citation: not checked Coverage and accuracy: not checked Structure: not checked Grammar: not checked Supporting materials: not checked To fill out this checklist, please add the following to the template call: <!-- B-Class-1. It is suitably referenced, and all major points have appropriate inline citations. --> |B-Class-1=yes/no <!-- B-Class-2. It reasonably covers the topic, and does not contain obvious omissions or inaccuracies. --> |B-Class-2=yes/no <!-- B-Class-3. It has a defined structure, including a lead section and one or more sections of content. --> |B-Class-3=yes/no <!-- B-Class-4. It is free from major grammatical errors. --> |B-Class-4=yes/no <!-- B-Class-5. It contains appropriate supporting materials, such as an infobox, images, or diagrams. --> |B-Class-5=yes/no This article is not currently associated with a task force. To tag it for one or more task forces, please add the task force codes from the template instructions to the template call.

[edit] Text's License

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)

[edit] FLASK is jargon

Anyone who has a clue what FLASK is probable 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)

[edit] 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)

[edit] "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)

[edit] no root in linux any more?

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?

[edit] 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)

[edit] NPOV disputed?

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. 12.134.194.7 00:50, 24 April 2007 (UTC)

[edit] NPOV disputed

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)

[edit] NPOV Disputed

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

[edit] 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)

[edit] 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.