On Wed, 2008-01-16 at 21:35 +0100, Valent Turkovic wrote: > On Jan 16, 2008 9:25 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: > > On Wed, Jan 16, 2008 at 09:19:38PM +0100, Valent Turkovic wrote: > > > On Jan 16, 2008 9:03 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: > > > > On Wed, Jan 16, 2008 at 08:57:56PM +0100, Valent Turkovic wrote: > > > > > Hi, > > > > > I believe that SELinux is a great linux server security hardening tool > > > > > but that has little use in desktop linux usage and it confuses > > > > > ordinary desktop users. > > > > > > > > It is of great use in a desktop spin. On my 'desktop' install for my > > > > laptop I have many many system daemons running under a confined domain > > > > > > You, of course, will always have the ability to choose to install it > > > and use it. > > > > > > > > If it hasn't been discussed before I would like to propose that on > > > > > desktop cd spin SELinux is not installed by default, of course after > > > > > discussion and approval from you (fedora devels). > > > > > > > > No. SELinux provides very real & important protection for desktop users. > > > > > > Can you give me examples of this protection over fedora 9 without > > > SELInux or with SELinux in permissive mode? > > > > Yes. SELinux mitigated against the recent HPLIP security flaw which > > would have allowed arbitrary code execution as root. > > > > http://james-morris.livejournal.com/25140.html > > https://rhn.redhat.com/errata/RHSA-2007-0960.html > > > > There have been other similar scenarios where security flaws have been > > prevented, or their damage mitigated by presence of SELinux > > > > > > Dan. > > Dan you are taking this the wrong way. Of course SElinux is great, of > course it prevents from 0day exploits, no body is challenging that. > But what was the real threat to average desktop users? Has anybody > made use of this 0day exploit threat? is there a linux virus in the > wild that spread like wildfire that took down all desktops that didn't > use SELinux? > > It is a question of cost and benefit. I argue that SELinux makes much > more trouble that it saves people from real danger in desktop > enviroment. Ofcourse that you need it in corporate enviroment and if > you use Fedora as corporate desktop you should enable it - but don't > make it default for them - especially if most of the people using it > won't understand cryptic messages that it gives :( > > If fedora is used as testing ground for redhat corporate desktop then > I understand the decision to make it on by default but if you really > want average home desktop users to have a pleasant linux experience I > really see no point in SELinux. I actually agree with you that SELinux for the desktop user currently leaves a bad taste in users' mouths ... specially new users trying it out. You've mentioned problems with codecs (though I've not had the same problem myself even with SELinux enabled). I did run across problems with it initially with some printer drivers, NFS shares and a couple of first-person shooter games. That said, I do believe that it's something that has to be done now because it IS an important feature that has to be fixed for the common desktop user ASAP. Of course, I would only agree with it being adopted now even if it causes problems for users WITH THE UNDERSTANDING that the devs actually taking people's pain and fixing their problems. I've followed your travails with getting audio codecs to work from the beginning and I feel your pain. If I'm not mistaken, the problem lies now with Fluendo to come up with a fix for it. Again, I would go back to the premise that SELinux is alright so long as the time is being used to fix things for users. If things aren't getting fixed, then perhaps the situation should be re-evaluated. For the most part, however, Dan Walsh (?) and others have done an excellent job of shooting down SELinux bugs as they appear ... and most are problems for desktop users. -- Richi Plana -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
