Talk:Security-Enhanced Linux

SELinux vs. AppArmor

The article states AppArmor does not provide multi level security. Then, why at AppArmor's wiki there's an article on how to implement MLS? Other points of the comparison should be verified.

This article seems to be fairly biased toward "SELinux is better than AppArmor". Only cons are provided hereby.

Usage

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)

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

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)

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)

Flask is the name of the architecture and implementation of the Fluke operating system where SELinux was born. Take a look at [1]. --W4otn (talk) 18:58, 23 November 2009 (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?

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)

I used NSAlinux before it became SELinux in 2008. there simply is no "root" account, and I recall not being able to create one (though there I might be mistaken). SUDO was possible if your account had the privilege enabled. The idea was that if there was no Root account, no one could ever gain Root access. From what I gather about SELinux, that same concept about Root is there, and they have added more control over what permissions any user can be given. In other words, you can create a non-root account that has root-like permissions, but since it isn't called "root", it isn't readily obvious to someone trying to gain remote access what accounts have what abilities. in other systems, with "root" accounts, there is no guessing - someone trying to break in knows they want the "root" account.

I use Debian now, and the system is very similar, but there is still a root account, and it requires a password to login. if you set the rootaccount up with no password, no one can ever get in (rather than everybody being able to, like a "guest" account). It is effectively the same, but I do know a way around it (unlike SELinux. I should install it sometime... later) Maxnort (talk) 16:54, 19 January 2020 (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)

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)

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)

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)

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

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.

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)

Features

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)

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. 85.221.142.5 (talk) 23:31, 9 November 2009 (UTC)

SELinux eliminates "root" access, and allows a high degree of control over what users have the ability to do what on the system - much like Windows promises, but then disregards whenever it is convenient for them.

a MAC address is the physical name of a network interface card. a NIC (as they are called) actually has at least 2 names on a network. one, called it's IP, or Internet Protocol address, can change, and still be tracked by the system. This is because the NIC also has an unchanging address, called it's MAC address. A router associates an IP as belonging to a particular MAC address, and that physical hardware exists on a particular physical port on the router itself. so, the router can control all data going to that node. and, more importantly, the router (and also a switch) keeps track of what MACs are active on a system, and can be told to not allow other MACs (any and all) access. this allows one to create an all / none set of access controls. no other MACs, but all other IPs on any allowed MACs.

look, my real point is that all the "jargon" I've just used isn't just a bunch of nonsense and buzzwords. this is legitimately how MACs work in a system. The fact that it sounds like buzzwords and unsubstantiated claims to you is simply a reflection of what you know about such things.Maxnort (talk) 17:11, 19 January 2020 (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'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)

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)

Controversy

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)

The quote by Larry Loeb has no cited source.Maxximillian (talk) 01:41, 17 November 2011 (UTC)

In agreement with the removal of the controversy section. There is No Such Agency anyway. — Preceding unsigned comment added by 77.248.0.214 (talk) 11:37, 28 August 2013 (UTC)

I removed the section again. I've added a see also link. Widefox; talk 17:00, 29 May 2014 (UTC)

Totally agreed, much better when left to a "See also" link. — Dsimic (talk | contribs) 18:02, 1 June 2014 (UTC)

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)

Dubious sentence on hard links

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)

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)

Possible vandalism?

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

Hello! Yeah, it looks like a possible vandalism, thanks for pointing it out. I've deleted a chunk that was unsourced and already marked with {{citation needed}} since October 2011. — Dsimic (talk | contribs) 06:14, 19 November 2014 (UTC)

Dead Link

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)

→ The NSA webmasters ditched the original SELinux site, the reasons probably have to do with internal policies and maintenance issues. The web archive has copies from 2008, I suggest rebasing the links against that. I fixed the History section with some more information from the original site that is worth keeping and relevant to the project and its contributors. Heapintrouble (talk) 02:02, 25 November 2021 (UTC)

Proposed Move Security-Enhanced Linux -> SELinux

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)

Merge a list of the original contributors in History

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)

Done, including the archived reference. Used a reduced list not including the context or scope of contributions, just the names. Because it contains quite a few names, but not too many to be superfluous, I tried using a columnlist and it worked out quite well. The list could use some edits to include internal links to past and present companies and individuals, if they have corresponding pages. Heapintrouble (talk) 01:34, 25 November 2021 (UTC)

Does the "Linux kernel statement" section belong on this page?

The "Linux kernel statement" section seems entirely unrelated to SELinux, other than the tangential association to the NSA. The section doesn't even mention SELinux at all.

I think it should probably be removed, as it's off-topic. 174.83.228.229 (talk) 02:00, 25 July 2024 (UTC)

How doesn't it mention it when it's where they purportedly wanted to install it? If they asked then it's not tangential, and I thought it was more relevant than to just be on Linus' father's page, but... someone else with more knowledge about all this can chime in, if desired... ~Lofty abyss 14:25, 6 September 2024 (UTC)