After installing the Nvidia driver I tried to enable special effects but was thwarted by an AVC denial. I couldn't get the acceleration enabled until I turned off SElinux.
It seems with Fedora and SElinux is it simply a matter of time before SElinux throws a spanner in the works at which time I have to get rid of it.
A security tool that is incompatible with normal use to the extent it must be disabled offers no real security. Perhaps it should be an add-on for security geeks instead of a default annoyance.
Chuck Forsberg caf@omen.com www.omen.com 503-614-0430 Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc "The High Reliability Software" 10255 NW Old Cornelius Pass Portland OR 97231 FAX 629-0665
There should be no need to entirely disable SELinux. In my several months of using Rawhide, I have never had an issue with SELinux and the security that it provides is more than worth the one-in-a-thousand chance of a minor annoyance. You need to keep in mind that using the NVidia binary driver is definitely not an ideal case when it comes to problem-free operation of your installation. I had a bad enough time keeping the NVidia blob from crashing my machine when I was still on an NVidia graphics platform; I can certainly believe you are having some annoyances with something like SELinux.
Speaking from personal experience, if you want trouble-free operation of your Linux box, dump the NVidia card. I've had nothing but good experiences with Intel integrated hardware (although it might not meet your requirements) and AMD hardware is quickly gaining open-source support. Even recent releases of AMD's binary driver have been surprisingly unproblematic in my experience.
Regardless, the AVC denial that you reported should be fairly simple to resolve without fully disabling SELinux. You should look at setroubleshooter and determine exactly what the nature of the denial is. Then open a bug with the output of setroubleshooter so that the issue can be fixed.
- Ben
Chuck Forsberg WA7KGX N2469R wrote:
After installing the Nvidia driver I tried to enable special effects but was thwarted by an AVC denial. I couldn't get the acceleration enabled until I turned off SElinux.
It seems with Fedora and SElinux is it simply a matter of time before SElinux throws a spanner in the works at which time I have to get rid of it.
A security tool that is incompatible with normal use to the extent it must be disabled offers no real security. Perhaps it should be an add-on for security geeks instead of a default annoyance. Chuck Forsberg caf@omen.com www.omen.com 503-614-0430 Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc "The High Reliability Software" 10255 NW Old Cornelius Pass Portland OR 97231 FAX 629-0665
On Sat, Oct 25, 2008 at 4:55 PM, Chuck Forsberg WA7KGX N2469R caf@omen.com wrote:
A security tool that is incompatible with normal use to the extent it must be disabled offers no real security. Perhaps it should be an add-on for security geeks instead of a default annoyance.
+1 Yep, I say leave the question out of the installer, and default it to *disabled*. Annoyances "one-in-a-thousand"? Ha. I see 779 out of 10913 bugs (1 in 14, if you will). Considering some are legit software issues, I'd estimate one-in-a-hundred "annoyances". Where is the ROI? Have there been documented cases where SElinux stopped malicious things dead in their tracks? (outside of selinux development situations, of course...)
jerry
Jerry Amundson wrote:
Have there been documented cases where SElinux
stopped malicious things dead in their tracks? (outside of selinux development situations, of course...)
Sure. Mitigation is useful as well. Listing all of them would take more time but here is a sample:
http://www.linuxjournal.com/article/9176
https://rhn.redhat.com/errata/RHSA-2008-0002.html http://danwalsh.livejournal.com/10131.html http://danwalsh.livejournal.com/17727.html
https://rhn.redhat.com/errata/RHSA-2007-0960.html http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3304
Rahul
On Sat, Oct 25, 2008 at 7:04 PM, Rahul Sundaram sundaram@fedoraproject.org wrote:
Jerry Amundson wrote:
Have there been documented cases where SElinux
stopped malicious things dead in their tracks? (outside of selinux development situations, of course...)
Sure. Mitigation is useful as well. Listing all of them would take more time but here is a sample:
Probably useful one time in a thousand. Basic software and network security practices easily cover your examples.
Yet another case of the user having their experience poisoned by the medicine, but the "doctors" insist we take it, "it's good for us"!
Chuck, kudos to you and everybody else who puts up with selinux. I can't take the productivity hit it eventually causes with things like this.
jerry
Jerry Amundson wrote:
Probably useful one time in a thousand.
Excellent record then.
Basic software and network security practices easily cover your examples.
Reading the references would help and shows you otherwise. You asked for real life cases where SELinux has blocked attacks and you have been provided with some of those.
Chuck, kudos to you and everybody else who puts up with selinux. I can't take the productivity hit it eventually causes with things like this.
Sure. You have your freedom.
Rahul
On Sat, Oct 25, 2008 at 7:31 PM, Rahul Sundaram sundaram@fedoraproject.org wrote:
Jerry Amundson wrote:
Probably useful one time in a thousand.
Excellent record then.
Whatever.
Basic software and network security practices easily cover your examples.
Reading the references would help and shows you otherwise. You asked for real life cases where SELinux has blocked attacks and you have been provided with some of those.
I did. We're talking about a rotten apple, and you give us a tour of the orange grove. It's unclear as to the origin of the nVidia driver in question, but it matters not. The point is to have a usable desktop all of the time. The state of an Apache web server doesn't matter, nor does some server doing an insecure dance I'm all too familiar with, the "mambo", all of which could be headless servers for all we know.
Chuck, kudos to you and everybody else who puts up with selinux. I can't take the productivity hit it eventually causes with things like this.
Sure. You have your freedom.
Yes, and I'm not afraid to use it.
jerry
Jerry Amundson wrote:
I did. We're talking about a rotten apple, and you give us a tour of the orange grove. It's unclear as to the origin of the nVidia driver in question, but it matters not. The point is to have a usable desktop all of the time. The state of an Apache web server doesn't matter, nor does some server doing an insecure dance I'm all too familiar with, the "mambo", all of which could be headless servers for all we know.
... aka "I didn't read the references provided".
Rahul
On Sat, Oct 25, 2008 at 10:31 PM, Rahul Sundaram sundaram@fedoraproject.org wrote:
Jerry Amundson wrote:
I did. We're talking about a rotten apple, and you give us a tour of the orange grove. It's unclear as to the origin of the nVidia driver in question, but it matters not. The point is to have a usable desktop all of the time. The state of an Apache web server doesn't matter, nor does some server doing an insecure dance I'm all too familiar with, the "mambo", all of which could be headless servers for all we know.
... aka "I didn't read the references provided".
Are you that obtuse? Really? Which part of "I did." was confusing to you?
jerry
Jerry Amundson wrote:
On Sat, Oct 25, 2008 at 10:31 PM, Rahul Sundaram sundaram@fedoraproject.org wrote:
Jerry Amundson wrote:
I did. We're talking about a rotten apple, and you give us a tour of the orange grove. It's unclear as to the origin of the nVidia driver in question, but it matters not. The point is to have a usable desktop all of the time. The state of an Apache web server doesn't matter, nor does some server doing an insecure dance I'm all too familiar with, the "mambo", all of which could be headless servers for all we know.
... aka "I didn't read the references provided".
Are you that obtuse? Really? Which part of "I did." was confusing to you?
Now that the discussion has moved to whether or not I am obtuse, instead of SELinux, we shall end it here.
Rahul
On Sat, Oct 25, 2008 at 18:59:12 -0500, Jerry Amundson jamundso@gmail.com wrote:
Yep, I say leave the question out of the installer, and default it to *disabled*.
Disabled is the worst of the three options because you will need to do a relabel if you ever turn it back on. And you don't get useful logs of any problems.
On Sun, Oct 26, 2008 at 10:13 AM, Bruno Wolff III bruno@wolff.to wrote:
On Sat, Oct 25, 2008 at 18:59:12 -0500, Jerry Amundson jamundso@gmail.com wrote:
Yep, I say leave the question out of the installer, and default it to *disabled*.
Disabled is the worst of the three options because you will need to do a relabel if you ever turn it back on. And you don't get useful logs of any problems.
I repeat. I think disabled is the best option for the largest audience. Overall, the majority of time spent re-labeling occurs when we disable selinux in firstboot. No selinux. No problems. Everything else that needs to be logged gets logged.
Very simple. Disable SElinux by default. Enable it (at firstboot, etc.) if you want it. The world becomes a better computing place. :)
jerry
Jerry Amundson wrote:
On Sun, Oct 26, 2008 at 10:13 AM, Bruno Wolff III bruno@wolff.to wrote:
On Sat, Oct 25, 2008 at 18:59:12 -0500, Jerry Amundson jamundso@gmail.com wrote:
Yep, I say leave the question out of the installer, and default it to *disabled*.
Disabled is the worst of the three options because you will need to do a relabel if you ever turn it back on. And you don't get useful logs of any problems.
I repeat. I think disabled is the best option for the largest audience. Overall, the majority of time spent re-labeling occurs when we disable selinux in firstboot. No selinux. No problems. Everything else that needs to be logged gets logged.
Very simple. Disable SElinux by default. Enable it (at firstboot, etc.) if you want it. The world becomes a better computing place. :)
jerry
Or we can simply decide that sticking our collective head in the sand is not an option when it comes to security, leave it enabled, and fix the remaining issues. There is no reason why SELinux needs to cause any issues in the vast majority of cases. Sure, if you are running a poorly tested/proprietary configuration (e.g. NVidia blob) then you will probably not have a completely glitch-free experience. However, degrading the security of the entire platform to cater to a small subset of users is simply not acceptable.
Security-wise, we in the Linux community have been extremely lucky thusfar. We represent a small percentage of Internet users and thus desktop exploits aren't particularly prevalent. However, if and when Linux becomes a sizeable player on the desktop/end-user space, we are going to have far greater security issues. Look at Windows. Even without considering the brain-dead security defaults, Windows XP is a security nightmare. Many of the issues that Windows has with malware could be mitigated with proper containment through MAC. Giving any application or service open access to anything on the system is a recipe for disaster. The fact is, the least-privilege principle simply can't realistically be implemented using only a primitive user/group privilege system. A perception that Linux is weak in security will only further hamper future adoption.
We have already seen early indications of the remarkable power that containment holds. To disable SELinux by default would be to remove a vital part of our security subsystem. Nobody can deny that there are still issues, but these can be fixed and once they are, the result will be a more secure computing environment for all.
- Ben
On Sun, Oct 26, 2008 at 3:17 PM, Ben Gamari (FOSS) bgamari@gmail.com wrote:
Jerry Amundson wrote:
On Sun, Oct 26, 2008 at 10:13 AM, Bruno Wolff III bruno@wolff.to wrote:
On Sat, Oct 25, 2008 at 18:59:12 -0500, Jerry Amundson jamundso@gmail.com wrote:
Yep, I say leave the question out of the installer, and default it to *disabled*.
Disabled is the worst of the three options because you will need to do a relabel if you ever turn it back on. And you don't get useful logs of any problems.
I repeat. I think disabled is the best option for the largest audience. Overall, the majority of time spent re-labeling occurs when we disable selinux in firstboot. No selinux. No problems. Everything else that needs to be logged gets logged.
Very simple. Disable SElinux by default. Enable it (at firstboot, etc.) if you want it. The world becomes a better computing place. :)
jerry
Or we can simply decide that sticking our collective head in the sand is not an option when it comes to security, leave it enabled, and fix the remaining issues. There is no reason why SELinux needs to cause any issues in the vast majority of cases. Sure, if you are running a poorly tested/proprietary configuration (e.g. NVidia blob) then you will probably not have a completely glitch-free experience. However, degrading the security of the entire platform to cater to a small subset of users is simply not acceptable.
Security-wise, we in the Linux community have been extremely lucky thusfar. We represent a small percentage of Internet users and thus desktop exploits aren't particularly prevalent. However, if and when Linux becomes a sizeable player on the desktop/end-user space, we are going to have far greater security issues. Look at Windows. Even without considering the brain-dead security defaults, Windows XP is a security nightmare. Many of the issues that Windows has with malware could be mitigated with proper containment through MAC. Giving any application or service open access to anything on the system is a recipe for disaster. The fact is, the least-privilege principle simply can't realistically be implemented using only a primitive user/group privilege system. A perception that Linux is weak in security will only further hamper future adoption.
We have already seen early indications of the remarkable power that containment holds. To disable SELinux by default would be to remove a vital part of our security subsystem. Nobody can deny that there are still issues, but these can be fixed and once they are, the result will be a more secure computing environment for all.
- Ben
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
While I agree with Ben's statements - I'll also add one other comment. If you've ever had to report a problem with SELinux and gone to the quite minimal effort to file a bug listing the AVC denial errors in place, you'd see that Dan Walsh and company work very fast to resolve it. I'll admit that I have only reported problems twice (once in channel and once in Bugzilla) but never did I go more than 24 hours before a fix was available (even if it was a koji build) (That said it's also relatively easy to fix on your own as well - but it's worth it to get the changes upstream in the targeted policy.) Moreover permissive domains REALLY changes the landscape. I wish I could remember who to attribute this to, but someone on -devel suggested that the same arguments occurred when firewalls were really starting to become commonplace - a lack of knowledge of how to manipulate and handle them caused repeated calls for their removal. Mandatory Access Control isn't going away, and is really one of the shining examples of Fedora leading the way with something and making it far easier to use than it was.
On Sun, Oct 26, 2008 at 4:29 PM, David Nalley david@gnsa.us wrote:
On Sun, Oct 26, 2008 at 3:17 PM, Ben Gamari (FOSS) bgamari@gmail.com wrote:
Or we can simply decide that sticking our collective head in the sand is not an option when it comes to security, leave it enabled, and fix the remaining issues. There is no reason why SELinux needs to cause any issues in the vast majority of cases. Sure, if you are running a poorly tested/proprietary configuration (e.g. NVidia blob) then you will probably not have a completely glitch-free experience. However, degrading the security of the entire platform to cater to a small subset of users is simply not acceptable.
Security-wise, we in the Linux community have been extremely lucky thusfar. We represent a small percentage of Internet users and thus desktop exploits aren't particularly prevalent. However, if and when Linux becomes a sizeable player on the desktop/end-user space, we are going to have far greater security issues. Look at Windows. Even without considering the brain-dead security defaults, Windows XP is a security nightmare. Many of the issues that Windows has with malware could be mitigated with proper containment through MAC. Giving any application or service open access to anything on the system is a recipe for disaster. The fact is, the least-privilege principle simply can't realistically be implemented using only a primitive user/group privilege system. A perception that Linux is weak in security will only further hamper future adoption.
We have already seen early indications of the remarkable power that containment holds. To disable SELinux by default would be to remove a vital part of our security subsystem. Nobody can deny that there are still issues, but these can be fixed and once they are, the result will be a more secure computing environment for all.
- Ben
...
While I agree with Ben's statements - I'll also add one other comment. If you've ever had to report a problem with SELinux and gone to the quite minimal effort to file a bug listing the AVC denial errors in place, you'd see that Dan Walsh and company work very fast to resolve it. I'll admit that I have only reported problems twice (once in channel and once in Bugzilla) but never did I go more than 24 hours before a fix was available (even if it was a koji build) (That said it's also relatively easy to fix on your own as well - but it's worth it to get the changes upstream in the targeted policy.) Moreover permissive domains REALLY changes the landscape. I wish I could remember who to attribute this to, but someone on -devel suggested that the same arguments occurred when firewalls were really starting to become commonplace - a lack of knowledge of how to manipulate and handle them caused repeated calls for their removal. Mandatory Access Control isn't going away, and is really one of the shining examples of Fedora leading the way with something and making it far easier to use than it was.
Ben, you had me at "Windows". ;-) Thank you also, David, for reassurance on the resolution side of things. My misconception up to now had been that bz'd selinux issues were lumped in with everything else. Good to hear that's not the case. And of course, my apologies to Rahul and Bruno for erring on the side of the dramatic. I have been know, on occasion, to howl at the moon. I'm reaching over to one of my other laptops, menu item for s-c-selinux, good, enforcing mode, relabel yes, done. I see this not as an end, but as a beginning! :-)
jerry
ps. Relabel is complete. logged in, wireless connected, just like any regular day, but *safer*. Brings a bit of a tear to me eyes! :)
On Sun, 2008-10-26 at 16:29, David Nalley wrote:
I wish I could remember who to attribute this to, but someone on -devel suggested that the same arguments occurred when firewalls were really starting to become commonplace - a lack of knowledge of how to manipulate and handle them caused repeated calls for their removal. Mandatory Access Control isn't going away, and is really one of the shining examples of Fedora leading the way with something and making it far easier to use than it was.
Wish I could be as optimistic but I'm not. SELinux has been trying to get to a truly useful state since FC2 and still causes more problems than it solves for too many end users. Are we expected to believe that it is about to finally 'just work?'
Yes it is great for a locked down server, and it's something any sane admin should try to use where a server is exposed to the wild Internet. On a very basic desktop that doesn't change much or run many different applications it doesn't do much harm... but also doesn't do much good either. On a more power user desktop it will almost always blow enough stuff up to end up getting disabled in frustration.
Compare and contrast to your example of enabling the firewall by default. That caused problems because it was done before good graphical tools to control the thing were ready so end users had problems. But any admin worthy of the name could deal with iptables wuth a manpage, vi (or emacs) and perhaps some Googling. The number of people who can write SELinux policy is still in the hundreds (at most) after five plus years of Red Hat pushing the technology as hard as it can.
And this new idea of using log scraping tools to automatically generate policy is simply an admission of that lack of skilled humans. Anybody who thinks automatically generated policy is going to produce a secure system is delusional. If enough humans who deeply understand SELinux existed to be able to double check these auto generated policies they could probably have written the darned things themselves.
Finally, the biggest objection is that it acts like alien technology bolted onto UNIX's security model as a totally different and parallel system. And like alien tech humans can't understand it, they are expected to treat it as a big black box and to just trust that it works and doesn't hose them at unexpected times. I can teach somebody the UNIX permission model in less than an hour. Learning the admin arcana of sticky bits, SUID, noexec mounts and such takes a few more hours. I read the O'Reilly book on SELinux and still don't think I understand it enough to write a sound policy. It is hard to trust things that one can't understand, especially a security system that I'm supposed to somehow administer.
On Mon, Oct 27, 2008 at 6:55 PM, John Morris jmorris@beau.org wrote:
On Sun, 2008-10-26 at 16:29, David Nalley wrote:
I wish I could remember who to attribute this to, but someone on -devel suggested that the same arguments occurred when firewalls were really starting to become commonplace - a lack of knowledge of how to manipulate and handle them caused repeated calls for their removal. Mandatory Access Control isn't going away, and is really one of the shining examples of Fedora leading the way with something and making it far easier to use than it was.
Wish I could be as optimistic but I'm not. SELinux has been trying to get to a truly useful state since FC2 and still causes more problems than it solves for too many end users. Are we expected to believe that it is about to finally 'just work?'
After years of will power to hold myself back from it, I caved in and gave an enforcing SElinux system a chance ... and everyone knows where that got me. [if you don't: https://bugzilla.redhat.com/show_bug.cgi?id=468645]
Yes it is great for a locked down server, and it's something any sane admin should try to use where a server is exposed to the wild Internet. On a very basic desktop that doesn't change much or run many different applications it doesn't do much harm... but also doesn't do much good either. On a more power user desktop it will almost always blow enough stuff up to end up getting disabled in frustration.
It did harm on my "basic" desktop. And the response so far has been "your user database is screwed up." Not "hmm, that's odd, how can we fix it?", not even a "strange, how did that happen?". Yep, like I purposefully sabotaged my SElinux environment... Let me emphasize here that I see it's potential as a sysadmin. However, the current mindset is to force it upon the user, and that, simply, is narrow-minded.
Compare and contrast to your example of enabling the firewall by default. That caused problems because it was done before good graphical tools to control the thing were ready so end users had problems. But any admin worthy of the name could deal with iptables wuth a manpage, vi (or emacs) and perhaps some Googling. The number of people who can write SELinux policy is still in the hundreds (at most) after five plus years of Red Hat pushing the technology as hard as it can.
This is one of the points I was intending to make in my posts of the past few days. Inside, I *felt* the state of selinux is dysfunctional and wrong, but the *technical* part of me wanted to believe what I was told. As usual, my technical experience confirmed what my instincts told me - SElinux is not production quality. [And for those of you considering it, don't bother playing the "rawhide" card.]
And this new idea of using log scraping tools to automatically generate policy is simply an admission of that lack of skilled humans. Anybody who thinks automatically generated policy is going to produce a secure system is delusional. If enough humans who deeply understand SELinux existed to be able to double check these auto generated policies they could probably have written the darned things themselves.
You've really hit the nail on the head there. I've said it before, and I'll say it again as long as necessary, software quality currently sucks. Where did todays developers learn that it's OK to pass burdens off to the end user? Oh, that's right, it's the open source way - "someone else will test, fix, document, etc." "patches greatly accepted" is another way of saying, "I don't care, you do the work."
Finally, the biggest objection is that it acts like alien technology bolted onto UNIX's security model as a totally different and parallel system. And like alien tech humans can't understand it, they are expected to treat it as a big black box and to just trust that it works and doesn't hose them at unexpected times. I can teach somebody the UNIX permission model in less than an hour. Learning the admin arcana of sticky bits, SUID, noexec mounts and such takes a few more hours. I read the O'Reilly book on SELinux and still don't think I understand it enough to write a sound policy. It is hard to trust things that one can't understand, especially a security system that I'm supposed to somehow administer.
Amen. Thanks for this. It drew me back from the darkness. That means SELINUX=disabled and a relabel/reboot from now on, as I see from installing Snap 3 today that "enforcing" is shoved down our throats. But, I'm OK with that. I'm still inclined to "test it out" on *some* systems - that's why I'm here. But I won't be fooled again. Thank you also for "Whitebox" - It's still on a couple of my key production systems (for now). It was my first exposure to what "open source" and "community" really meant when combined together.
jerry
<snip> ....... </snip>
From my experience things have gone a lot and I mean a lot better but is still far away from perfection.
For the first time, I think it was the F10-beta I did not have a single selinux report after *default* installation, now that in itself is an achievement ( Let's hope it makes it so to final ).
I had to check if I had selinux in enforce mode here on my workstation ( F9 + I'm one of those that disables it if gets to much in my way of doing things) and I do.
I'm not going to say I have not had to "tweak it a bit" but it is running "silently" in the background now.
I think it's because of all the reports from the testers and Dan's exceptional fast and good work on fixing things..
We of course have to continue feed him the reports we encounter both from the official fedora repo's and and ( now ) rpmfusion to have things fixed before it reaches the end-users.
When it comes to the reports that the novice end user receives they are to technical orientated even thou I personally like to get details, they are perceived as gibberish from the end user that does not understand selinux.
If we really want our end users to have good experience with selinux running we need to add several things to setroubleshoot...
A) Simplify the reports with an "Detail" button for us techies.
B) Add a "Report" button that would file a selinux report to bugzilla. ( Team Anconda has done this so the code is there just needs to be integrated I think. )
C)
Add "Allow access" button that would execute the fix that setroubleshoot recommends upon the end user provides the root password.
The users going to do it anyway so why not make it easer for him to do so if he has the root password instead of having him open a terminal have the report open and type in what's being recommended. users that dont have the root password could "Report" the issue.
D) Add a "Fix" button that automatically restores the default system file context.
If you have any other suggestions on how to improve selinux experience please add your thoughts to this thread or to the RFE I filed. #Bug 468842
Issues wont get improved/fixed if we dont report them..
JBG
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jerry Amundson wrote:
On Mon, Oct 27, 2008 at 6:55 PM, John Morris jmorris@beau.org wrote:
On Sun, 2008-10-26 at 16:29, David Nalley wrote:
I wish I could remember who to attribute this to, but someone on -devel suggested that the same arguments occurred when firewalls were really starting to become commonplace - a lack of knowledge of how to manipulate and handle them caused repeated calls for their removal. Mandatory Access Control isn't going away, and is really one of the shining examples of Fedora leading the way with something and making it far easier to use than it was.
Wish I could be as optimistic but I'm not. SELinux has been trying to get to a truly useful state since FC2 and still causes more problems than it solves for too many end users. Are we expected to believe that it is about to finally 'just work?'
After years of will power to hold myself back from it, I caved in and gave an enforcing SElinux system a chance ... and everyone knows where that got me. [if you don't: https://bugzilla.redhat.com/show_bug.cgi?id=468645]
Yes it is great for a locked down server, and it's something any sane admin should try to use where a server is exposed to the wild Internet. On a very basic desktop that doesn't change much or run many different applications it doesn't do much harm... but also doesn't do much good either. On a more power user desktop it will almost always blow enough stuff up to end up getting disabled in frustration.
It did harm on my "basic" desktop. And the response so far has been "your user database is screwed up." Not "hmm, that's odd, how can we fix it?", not even a "strange, how did that happen?". Yep, like I purposefully sabotaged my SElinux environment... Let me emphasize here that I see it's potential as a sysadmin. However, the current mindset is to force it upon the user, and that, simply, is narrow-minded.
Compare and contrast to your example of enabling the firewall by default. That caused problems because it was done before good graphical tools to control the thing were ready so end users had problems. But any admin worthy of the name could deal with iptables wuth a manpage, vi (or emacs) and perhaps some Googling. The number of people who can write SELinux policy is still in the hundreds (at most) after five plus years of Red Hat pushing the technology as hard as it can.
This is one of the points I was intending to make in my posts of the past few days. Inside, I *felt* the state of selinux is dysfunctional and wrong, but the *technical* part of me wanted to believe what I was told. As usual, my technical experience confirmed what my instincts told me - SElinux is not production quality. [And for those of you considering it, don't bother playing the "rawhide" card.]
And this new idea of using log scraping tools to automatically generate policy is simply an admission of that lack of skilled humans. Anybody who thinks automatically generated policy is going to produce a secure system is delusional. If enough humans who deeply understand SELinux existed to be able to double check these auto generated policies they could probably have written the darned things themselves.
You've really hit the nail on the head there. I've said it before, and I'll say it again as long as necessary, software quality currently sucks. Where did todays developers learn that it's OK to pass burdens off to the end user? Oh, that's right, it's the open source way - "someone else will test, fix, document, etc." "patches greatly accepted" is another way of saying, "I don't care, you do the work."
Finally, the biggest objection is that it acts like alien technology bolted onto UNIX's security model as a totally different and parallel system. And like alien tech humans can't understand it, they are expected to treat it as a big black box and to just trust that it works and doesn't hose them at unexpected times. I can teach somebody the UNIX permission model in less than an hour. Learning the admin arcana of sticky bits, SUID, noexec mounts and such takes a few more hours. I read the O'Reilly book on SELinux and still don't think I understand it enough to write a sound policy. It is hard to trust things that one can't understand, especially a security system that I'm supposed to somehow administer.
Amen. Thanks for this. It drew me back from the darkness. That means SELINUX=disabled and a relabel/reboot from now on, as I see from installing Snap 3 today that "enforcing" is shoved down our throats. But, I'm OK with that. I'm still inclined to "test it out" on *some* systems - that's why I'm here. But I won't be fooled again. Thank you also for "Whitebox" - It's still on a couple of my key production systems (for now). It was my first exposure to what "open source" and "community" really meant when combined together.
jerry
SELinux has a bug in the selinux-policy-targeted package that fails to setup the user database correct if the package is initially installed on a disabled system. If you later turn SELinux on, your database is screwed up so you were not able to login. The post install executes these commands semanage -S targeted -i - << __eof user -a -P user -R "unconfined_r system_r" -r s0-s0:c0.c1023 unconfined_u user -a -P user -R guest_r guest_u user -a -P user -R xguest_r xguest_u __eof semanage -S targeted -i - << __eof login -m -s unconfined_u -r s0-s0:c0.c1023 __default__ login -m -s unconfined_u -r s0-s0:c0.c1023 root __eof
Which basically setup the default user and root account to login as unconfined_t. Since SELinux was disabled these commands failed.
On Tue, Oct 28, 2008 at 7:56 AM, Daniel J Walsh dwalsh@redhat.com wrote:
SELinux has a bug in the selinux-policy-targeted package that fails to setup the user database correct if the package is initially installed on a disabled system. If you later turn SELinux on, your database is screwed up so you were not able to login. The post install executes these commands semanage -S targeted -i - << __eof user -a -P user -R "unconfined_r system_r" -r s0-s0:c0.c1023 unconfined_u user -a -P user -R guest_r guest_u user -a -P user -R xguest_r xguest_u __eof semanage -S targeted -i - << __eof login -m -s unconfined_u -r s0-s0:c0.c1023 __default__ login -m -s unconfined_u -r s0-s0:c0.c1023 root __eof
Which basically setup the default user and root account to login as unconfined_t. Since SELinux was disabled these commands failed.
OK, thanks. I'll try it when I have a chance to get back on that system.
jerry
On Mon, Oct 27, 2008 at 18:55:38 -0500, John Morris jmorris@beau.org wrote:
Yes it is great for a locked down server, and it's something any sane admin should try to use where a server is exposed to the wild Internet. On a very basic desktop that doesn't change much or run many different applications it doesn't do much harm... but also doesn't do much good either. On a more power user desktop it will almost always blow enough stuff up to end up getting disabled in frustration.
SELinux has great potential for the Desktop user and will be even more important for them than it is on the server. It provides a way for a user to run foreign code that they have limited trust of and have some protection from that code. (I.e. it can't do everything they can.) If we don't have some sort of mac system and average computer users start flocking to linux, they are going to need to run antivirus crap instead.
It also provides a way to provide guest access to your machine that is reasonably safe.
Fixing problems with policy have gotten easier. Permissive domains is a big step.
There is work going on labelling network traffic so that you can enforce policies in a networked environment rather than on just a single machine.
On Sun, Oct 26, 2008 at 13:39:40 -0500, Jerry Amundson jamundso@gmail.com wrote:
I repeat. I think disabled is the best option for the largest audience. Overall, the majority of time spent re-labeling occurs when we disable selinux in firstboot.
FYI, when you disable selinux a relabel doesn't occur. It's just that processes stop properly labelling new files, so that if you turn selinux back on (even in permissive mode), all files on the system need to be checked to make sure they are properly labelled.
No selinux. No problems. Everything else that needs to be logged gets logged.
The logs from selinux can be useful even in permissive mode and include information that is not included in other logs. Whether or not they are useful often enough to justify the overhead by default is something reasonably debated.
On Sun, Oct 26, 2008 at 01:39:40PM -0500, Jerry Amundson wrote:
On Sun, Oct 26, 2008 at 10:13 AM, Bruno Wolff III bruno@wolff.to wrote:
On Sat, Oct 25, 2008 at 18:59:12 -0500, Jerry Amundson jamundso@gmail.com wrote:
Yep, I say leave the question out of the installer, and default it to *disabled*.
Disabled is the worst of the three options because you will need to do a relabel if you ever turn it back on. And you don't get useful logs of any problems.
I repeat. I think disabled is the best option for the largest audience. Overall, the majority of time spent re-labeling occurs when we disable selinux in firstboot. No selinux. No problems. Everything else that needs to be logged gets logged.
Very simple. Disable SElinux by default. Enable it (at firstboot, etc.) if you want it. The world becomes a better computing place. :)
a The best solution is for nVidea to get with the program. Rather than snipe at each other each of us with nVidea hardware should send them a note.
The performance delta is very real so yes I want acceleration... and more importantly I do vote with my wallet.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Chuck Forsberg WA7KGX N2469R wrote:
After installing the Nvidia driver I tried to enable special effects but was thwarted by an AVC denial. I couldn't get the acceleration enabled until I turned off SElinux.
It seems with Fedora and SElinux is it simply a matter of time before SElinux throws a spanner in the works at which time I have to get rid of it.
A security tool that is incompatible with normal use to the extent it must be disabled offers no real security. Perhaps it should be an add-on for security geeks instead of a default annoyance. Chuck Forsberg caf@omen.com www.omen.com 503-614-0430 Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc "The High Reliability Software" 10255 NW Old Cornelius Pass Portland OR 97231 FAX 629-0665
I would bet your problem was with executable memory, which nvidia libraries cause. You can turn on allow_execstack boolean to allow executable memory, and then SELinux would stop complaining.
-
"Jóhann B. Guðmundsson" -
Alan Cox -
Ben Gamari -
Bruno Wolff III -
Chuck Forsberg WA7KGX -
Daniel J Walsh -
David Nalley -
Jerry Amundson -
John Morris -
Nifty Fedora Mitch -
Rahul Sundaram