On Sun, Oct 26, 2008 at 3:17 PM, Ben Gamari (FOSS) <bgamari@xxxxxxxxx> wrote: > Jerry Amundson wrote: >> On Sun, Oct 26, 2008 at 10:13 AM, Bruno Wolff III <bruno@xxxxxxxx> wrote: >> >>> On Sat, Oct 25, 2008 at 18:59:12 -0500, >>> Jerry Amundson <jamundso@xxxxxxxxx> 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@xxxxxxxxxx > 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. -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
