2008/7/22 max <maximilianbianco@xxxxxxxxx>:
Any suggested solution that starts with "open a terminal" scares users, additionally if they are required to be root in said terminal I would hestitate to guess that we lose everyone except a bare minimum of users when looking at the big picture - my mother surely should not be asked to do this, the mere thought of her with the root password in hand terrifies me add to that firing off random commands she has no idea what does - it's a wonder Hollywood has yet to make a blockbuster horror movie following this plot. In terms of what SELinux does currently, it's an improvement over the older releases but it's still far from being something I would let my mother ticker with - and the policy currently has plenty of holes in terms of what an average user might do, just the other day I discovered SELinux utter fail when plugging in my iPod (this was fixed within days of being filed and as I recall an update was pushed soon there after, so the response is generally good but that is still some 2 weeks where aunt tilly can't use her iPod). Should asking the user to drop to a terminal as root and issue commands really be our first line of defence.. I certainly hope not. We really need to be more proactive in gathering failures instead of relying on the user to patch up the policy with mysterious cli magic.
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.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:Couldn't exempt be (ab)used to an attacker if/when it becomes common
another idea, is when a denial occurs, and we get this nice balloon,This is a sharp edge for users to cut themselves on. It would be nice if
it would contain 2 buttons
- AutoFix: automatically attempts changing the offending file's
context, as per the recommended action
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
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.
Any suggested solution that starts with "open a terminal" scares users, additionally if they are required to be root in said terminal I would hestitate to guess that we lose everyone except a bare minimum of users when looking at the big picture - my mother surely should not be asked to do this, the mere thought of her with the root password in hand terrifies me add to that firing off random commands she has no idea what does - it's a wonder Hollywood has yet to make a blockbuster horror movie following this plot. In terms of what SELinux does currently, it's an improvement over the older releases but it's still far from being something I would let my mother ticker with - and the policy currently has plenty of holes in terms of what an average user might do, just the other day I discovered SELinux utter fail when plugging in my iPod (this was fixed within days of being filed and as I recall an update was pushed soon there after, so the response is generally good but that is still some 2 weeks where aunt tilly can't use her iPod). Should asking the user to drop to a terminal as root and issue commands really be our first line of defence.. I certainly hope not. We really need to be more proactive in gathering failures instead of relying on the user to patch up the policy with mysterious cli magic.
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
