2008/7/22 Arthur Pemberton <pemboa gmail com
2008/7/22 David Nielsen <gnomeuser gmail com>:
[ snip ]
>> Don't implement it or if you do make that nonsense optional and not theWhat are you responding to?
>> default. Everyone wants things to be simpler, there is no easy way out.
>> System security is not something simple. Developer's continue to indulge in
>> running permissive or turning SELinux off entirely, all this accomplishes is
>> to make it take longer to establish good policy, SELinux isn't going
>> anywhere. People need to get used to it. There are a number of tools
>> available to troubleshoot any issue but nobody seems to want to use any of
>> them. The kerneloops for SELinux is a good idea but it isn't going to
>> instantly solve anyone's problems. All those reports still have to sorted
>> and reviewed to determine how to fix policy to suit the majority of users,
>> it still may take weeks to sort it all out. People often are not even trying
>> the fixes suggested by SETroubleshoot. SETroubleshoot does a good job of
>> suggesting fixes. Audit2allow is great for this until upstream can figure
>> out how to work it out. All this talk of allow/deny buttons is absolute
>> insanity and it will ruin one of the few useful security tools that exist.
The above seems to indicate to me an opinion that the current solutions are sufficient, though could be expanded with automated gathering of information akin. Every SELinux prompt I have seen so far suggests terminal usage instead of a direct "click to implement this" solution. I merely point out cases where this is not sufficient. If I read this wrong I apologize, I stand by my opinion that SELinux should be useful even in cases where there are holes in the policy, currently it is not. If we want to grab a higher market share we do need to design solutions to encompass Aunt Tilly type people, at least every solution we deploy by default such as SELinux.