AVC Decision Tree.

AVC Decision Tree.

[Daniel J Walsh]

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.

Additional suggestions are welcome. 


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.

Re: AVC Decision Tree.

[Daniel J Walsh]

Thorsten Scherf 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.
>>     
>
> Usually if a AVC denied is fixed with a corresponding rule, the next AVC
> comes up in the log (allow getattr, after that ACV:denied read, and so
> on). Probably we don't want to annoy the administrator with several
> pop-ups coming up on his screen.
>
> What do you think about that?
>
>   
Yes the idea would be to continue gathering all of the AVC's while the 
app is running.  I do not believe they will be able
close the window faster than the AVC MEssages.  The app should have a 
disable button built in so that if their is a real labeling problem, it 
will not keep popping up.  So we will have to watch our usability. :^)  
But hopefully there will not be a lot of AVC messages :^)

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.

Re: AVC Decision Tree.

[Christopher J. PeBenito]

(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.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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.

Re: AVC Decision Tree.

[Daniel J Walsh]

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.