Re: AVC Decision Tree.

[Daniel J Walsh <dwalsh@redhat.com>]

Christopher J. PeBenito wrote:
> (accidentally went off list with this)
>
> On Wed, 2006-05-10 at 14:29 -0400, Christopher J. PeBenito wrote:
>   
>> On Wed, 2006-05-10 at 14:21 -0400, Daniel J Walsh wrote:
>>     
>>> Christopher J. PeBenito wrote:
>>>       
>>>> On Thu, 2006-03-30 at 14:51 -0500, Daniel J Walsh wrote:
>>>>   
>>>>         
>>>>> http://fedoraproject.org/wiki/SELinux/Troubleshooting/AVCDecisions#preview
>>>>>
>>>>> Trying to build a analysys tool to be able to translate avc messages 
>>>>> into possible boolean/file_context solutions.
>>>>>
>>>>> The idea is that we can look at the AVC messages that are generated and 
>>>>> figure out what the servers were trying to do.  Then we can give some 
>>>>> advise to the administrator on the corrective measures.  So what we are 
>>>>> looking for are expected code paths where there is a file context of 
>>>>> boolean available.
>>>>>     
>>>>>           
>>>> We had a meeting since the conversion of example policy is wrapping up,
>>>> and we're looking at adding this type of information to reference policy
>>>> XML.  Then the tree doesn't have to be hard coded, so a tool could load
>>>> up the XML and gather denials, and then if you got an etc_t:file read
>>>> denial, the decision tree should come up with files_read_etc_files().
>>>>
>>>>   
>>>>         
>>> But that is not what we are after.  I have attached an example plugin, 
>>> which translates an AVC message about ftp into one of two possible 
>>> messages. 
>>>       
>> Thats included in what we were thinking.
>>     
>
> To expand, the idea would be to eventually have something like an
> audit2interface tool.  It would be much better than the current
> audit2allow, not only because it resolves to interfaces or boolean
> toggles, but it allows an opportunity to give the user information about
> what the rules do.  With audit2allow, users just see a pile of rules and
> have no clue what it means or if its safe, whereas leveraging the
> information in the interface xml, the tool can present them with much
> more information about risks with allowing the access and give the
> opportunity to dontaudit instead.
>
>   

This sounds good,  I actually use the audit2allow -R all the time, and 
for a hack it works pretty well.
But an improvement in this would be great.  I think if we can get better 
descriptions and problem
resolutions that users could understand it would be a huge improvement.  
My concern is translations.
We are currently working on an interface to be able to translate AVC and 
present them to the user.  
These need to be translated.  Now we could probably extract the 
descriptions out of the policy and
allow them to be translated for our tool.

Dan


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.