[apparmor] [PATCH RFC] Add profile-based libapparmor query interface

[John Johansen]

On 03/07/2013 04:07 PM, Tyler Hicks wrote:
> On 2013-03-07 00:07:29, John Johansen wrote:

<< snip >>

>>>
>>> Description: Add profile-based libapparmor query interface
>>>  Wrap the apparmorfs profile query interface with a very simple libapparmor
>>>  interface. This function takes a permission mask and query string consisting
>>>  of a profile name and a DFA match string separated by a NUL char. It sets two
>>>  output parameters indicating whether the action should be allowed and if the
>>>  action should be audited.
>>>  .
>>>  The allowed and audited output parameters take into account deny and quiet
>>>  permission masks returned in the kernel query. Additionally, the audited
>>>  ouput parameter takes into account whether the action is to be allowed or
>>>  not. If not, audited is set to true as long as there was no specific quiet
>>>  rules for the queried permission.
>>>  .
>>>  The function requires a static char array to be allocated and initialized to
>>>  the path of the apparmorfs .access file the first time it is called.
>>>  Otherwise, aa_find_mountpoint() would need to be called for every query which
>>>  would be inefficient. pthread_once() is used to ensure that aa_query_profile()
>>>  is thread-safe while the char array is being allocated and initialized.
>> We could just require a call to setup query once. And that would open a file handle
>> and we could leave the handle open, and reset queries by seeking to the beginning
>> instead of opening the .access file each time.
>>
>> I realize this would require some kernel modifications and I am not sure whether
>> it is worth doing, but its an alternative.
> 
> Yeah, it is a bummer that simple_transaction_get() enforces one write
> per open.
> 
> Another option would be to do this in a library constructor function but
> support for that is compiler specific.
> 
> I do like that we don't currently require callers to keep any kind of
> state around (such as a file descriptor), so I'm currently ok with
> pthread_once() if everyone else is.
> 
well I was thinking we could do the same kind of trick with a descriptor. However
since its all hidden that type of change, if we decide to do it, can come later