On Thu, 2008-07-03 at 11:29 +1000, James Morris wrote: > On Wed, 2 Jul 2008, Alan Cox wrote: > > > Knowing what it is isn't sufficient - they must know enough to make a meaningful > > risk analysis fo the decision. Very few users I suspect are in that position. > > This is quite a significant problem, as people tend to underestimate > negative risk and overestimate positive risk (according to "Prospect > Theory"). > > And as the odds increase in each direction, people increasingly mis-judge > them. e.g. people believe they'll win the lottery but figure they don't > need a motorcycle helmet. > > Bruce Schneier recently discussed the topic: > http://www.schneier.com/blog/archives/2008/05/how_to_sell_sec.html > > The only way to really make progress in improving security is to make it a > standard part of the computing landscape; for it to be ubiquitous and > generalized, which is the aim of the SELinux project. > > Having a separate "secure" version or option will not work, as proven many > times over with the trusted Unix variants which are essentially forks of > their respective mainline products. > > Avoiding the whole issue will also not work, as DAC security simply cannot > provide adequate protection in a globally networked environment. The > rationale for MAC has been made very clear in an NSA paper, the reading of > which I think is essential for any informed discussion on the issue: > > http://www.nsa.gov/selinux/papers/inevitability/ > > Punting the decision to the end user during installation is possibly the > worst option. It's our responsibility as the developers of the OS to both > get security right and make it usable. It's difficult, indeed, but not > impossible. That's all nice and all, but really SELinux on by default has never worked on a Fedora gold release, there is always some path through some program that didn't get tested, how about you guys try and come up with a way to solve those problems in advance or at least give developers some tools so regressions in SELinux policy can be tracked. Like we have rpmdiff and that other internal rpm thingy for RHEL, perhaps SELinux team could construct a similiar tool that says your new package is going to violate policy where your old package didn't. Relying on users to mail us the contents of some pop-up dialog box is ass. Ask Dr. Watson. Dave. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
