-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 > - Exempt: changes the policy such that the offended application runs > in an unrestricted selinux domain. > > IMHO, the policies will never be perfect. Mortals can't really "fix" > the policy coz it's too complex. The Exempt is what the end users > need, or they turn off the whole thing > exempt is coming, (permissive domains) available in Rawhide now. The problem with this is when you get an AVC that really did not block anything. Teaching people to press a button to tell SELinux to disable protection will get them to disable it when a real attack comes a long. Most avc's are caused by mislabled files, leaked or redirected file descriptors, bugs in policy/code. And a hole lot of them can be ignored. As an example, if you run system-config-services from the launch panel. It has stdout redirected to ~/.xsession-errors If you restart a confined domain from this tool, you will generate an avc saying the confined domain tried to write to user_home_t. This is a fairly bogus avc and users should not disable protection since nothing was really blocked. Our job is to figure out how to get rid of the false noice and get to real security problems. We have just added a new access called open. Before we had only read/write. You could get read/write errors from open file descriptors being passed around as explained above. useradd dwalsh > ~/myhome will generate an Read/write avc. This is not some thing to worry about, however if named suddenly got an "open" avc on user_home_t you know you have a problem. Since named should never be opening files in the homedir. > On Thu, Jul 17, 2008 at 10:55 PM, Robin Norwood <rnorwood@xxxxxxxxxx> wrote: >> On Thu, 17 Jul 2008 14:19:07 -0500 >> "Arthur Pemberton" <pemboa@xxxxxxxxx> wrote: >> >>> On Thu, Jul 17, 2008 at 2:17 PM, Daniel J Walsh <dwalsh@xxxxxxxxxx> >>>> John Dennis designed setroubleshoot to be able to send its messages >>>> to an upstream collector, it seems to me that adding a button to >>>> report the message upstream would be easy. The problem is where is >>>> the upstream infrastructure to handle all the messages. >>>> >>>> dwalsh@xxxxxxxxxxx Is probably not a good place. >>> >>> I would think not. Does the infrastructure team have any web service >>> or sorts that can accept these log messages? >> Probably not, but it sounds like a fairly easy turbogears project. The >> data is in XML? Is the format defined anywhere? The app would need to >> process the XML to check for duplicates, and display the results. If >> the format is well-defined and we can say "If fields x, y, and z are >> the same, then this is a duplicate report", then it should be nearly >> trivial. >> >> -RN >> >> -- >> Robin Norwood >> Red Hat, Inc. >> >> "The Sage does nothing, yet nothing remains undone." >> -Lao Tzu, Te Tao Ching >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list@xxxxxxxxxx >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh/sR0ACgkQrlYvE4MpobMunQCdE461uwubJxxsrOPZK1w1pzGv MjYAoMSussoCH57VB6jB21yILPfScviA =cavG -----END PGP SIGNATURE----- -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
