With all due respect, you've completely missed the point. In many cases,
casual users are their own system admin (home machine). Yes, the man
pages exist but the whole point of improving SELinux <--> user
interaction is to avoid exactly that. Things need to be more user
friendly and human-readable so the casual user can understand SELinux
instead of getting frustrated and disabling it.

Stewart


On Mon, 2008-07-21 at 17:34 -0400, max bianco wrote:
> On Thu, Jul 17, 2008 at 7:26 PM, Ahmed Kamal
> <email.ahmedkamal@googlemail.com> wrote:
> > I'd say I am a pretty knowledgeable Linux user. However, when I see an
> > AVC denial, and the recommended chcon doesn't fix it, I'm pretty much
> > lost! I need to launch that server or that application NOW, and
> > selinux is stopping that ... and the policy won't be fixed for days,
> > it won't even be fixed at all if that's a 3rd party app! I need
> > something to help me launch my apps if I so choose! a 95% selinux
> > protected system, is so much better than one with it disabled, which
> > what I always seem to end up doing to get my work done!
> >
> The tools to fix this already exist.
>
> man audit2allow
> man ausearch
>
> The man pages explain things pretty well. If I can read them and fix
> my own problems so can any competent sysadmin.
> ausearch can be used with audit2allow to generate the needed rules.
> The rules shouldn't be blindly accepted but they can get you buy for
> the moment.
> Its all documented in the man pages, every step. SysAdmins need to get
> used to SELinux and use the available troubleshooting tools. The Z
> option is available on a few commands.
>
>
> Max
> --
> If opinions were really like assholes we'd each have just one
>

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Arthur Pemberton wrote:

On Tue, Jul 22, 2008 at 9:15 AM, Gilboa Davara <gilboad@gmail.com> 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

--
Fortune favors the BOLD

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list