SE Linux Questions
Jim Cornette
redhat-jc at insight.rr.com
Thu Apr 15 01:36:20 UTC 2004
Russell Coker wrote:
> On Wed, 14 Apr 2004 21:21, Jim Cornette <redhat-jc at insight.rr.com> wrote:
>
>>This is a job that the developers know what errors are valid for aiding
>>their forward refinements to the security Linux concept. Automated
>>reporting sounds like the most productive way to accomplish this error
>>tracking.
>>
>>Hopefully, this automatic logging and informing developers can be used
>>for the early stages of development, then slacked off after refinements
>>are successfully implemented and errors with SELinux are very few.
>
>
> Having AVC messages on their own often does not help in solving problems. We
> also need to know whether the program continues to work in spite of not being
> granted access (IE whether it's something the program really needs). We also
> need to know what the user is trying to do (consider the example of procmail
> and the Sendmail mqueue directory).
>
> I don't think that an automatic report is of any use unless the administrator
> of the system is prepared to get involved (in which case they can send a
> manual report).
>
Thanks for adding the the application functionality and blockades that
SELinux may expose are important. I guess the AVC messages were
mentioned more than the application functionality.
I guess automated failure reports would not be very practical. I just
realized how fouled up the state of my test installation is with SELinux
and latest kernel release, I was hoping that there was an easier way to
get these errors reported to the developers and off of the test machines.
I dreaded booting to runlevel 1, running "make" and then running "make
relabel", just to get my graphical interface to work. Then try to figure
out how to get all the information regarding the "needs improvement",
located, filtered and relayed t where changes can be made and users
could be a little less frustrated with downed processes.
Before X locked up on initiating and the system had to be hard reset. I
was only slightly agitated with the unknown user pop-up and not being
able to poweroff from other than a root account.
Little failures added to pretty important inoperable processes just got
a little bothersome, especially, since I thought that I disabled
SELinux interference by putting it into permissive mode.
Oh well, I guess the fun begins at runlevel 1. Good luck! I'll try to
see if I can get through the obstacles and help eliminate some of these
blocks to a calmer release for Fedora Core 2.
Jim
More information about the fedora-test-list
mailing list