SE Linux Questions

[Jim Cornette]

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