On Tue, Jul 22, 2008 at 11:06 AM, max <maximilianbianco@xxxxxxxxx> wrote: > Arthur Pemberton wrote: >> >> On Tue, Jul 22, 2008 at 9:15 AM, Gilboa Davara <gilboad@xxxxxxxxx> wrote: >>> >>> On Thu, 2008-07-17 at 17:03 -0400, Casey Dahlin wrote: >>>> >>>> Ahmed Kamal wrote: >>>>> >>>>> another idea, is when a denial occurs, and we get this nice balloon, >>>>> it would contain 2 buttons >>>>> - AutoFix: automatically attempts changing the offending file's >>>>> context, as per the recommended action >>>>> >>>> This is a sharp edge for users to cut themselves on. It would be nice if >>>> we would detect when the error was a result of inconsistencies though >>>> (such as the file label not matching policy). >>>> >>>> IMHO, we should be able to do the following: >>>> >>>> - We should have exempt, which ignores the denial for now. It also flags >>>> the issue upstream. Denial messages for the exempt process are then >>>> rerouted to a safe place. >>>> - Whenever policy-kit is updated, the exemptions are reevaluated and >>>> removed if they should be addressed. >>>> - We should come up with some secure way of quickly propagating >>>> information about known selinux issues, so that denial warnings can be >>>> suppressed until a fix is available >>>> - There should be more graphical tools for manipulating policy itself. >>>> The user should be able to see a list of local policy exceptions they >>>> have made. >>>> >>>> --CJD >>>> >>> Couldn't exempt be (ab)used to an attacker if/when it becomes common >>> knowledge? >> >> Through social engineering, yes. That's why it's a terrible solution, >> but I'm not sure there is any good way around it. >> > Don't implement it or if you do make that nonsense optional and not the > 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. > > -Max Most of the discussion was around a "Fix" button though. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
