[apparmor] First draft of a userspace ipc introspection interface

[John Johansen]

On 11/17/2010 06:35 PM, John Johansen wrote:
> So this is a first cut at an interface to be exposed to userspace via libapparmor.
> 
> It takes the general question approach, ie. what are my permissions for doing
> ipc between X and Y.  It doesn't deal with all the various exceptions and possible
> combinations that may be possible.
>   ie.  It will be possible to do ipc but not send sig kill, or ipc may be limited
>        to a specific form, eg pipes.
> 
> It also doesn't currently deal with whether ipc can be done through a file that
> each end opens (ie not a shared fd that was passed).  That would require a total
> policy analysis that we don't currently do/require at profile load time.
> 
> I am not terribly happy with the int return parameter (I actually favor the kernel
> negative error codes or using errno) but I choose to follow the clib and current
> libapparmor convention.
> 
> Basically there are two fns, one form ipc, and one for exec questions.  And then
> there are several convenience function that make life easier for application
> developers.
> 
> _query_ is used on fn names that do generic queries that could be against any
>         profile/task
> 
> _introspect_ is used for fn names for querying the state of the task calling it
> 
> 
> I have omitted the details of the kernel interfaces, and patches at this time
> as I just want to focus on getting peoples feed back about the interfaces before
> we get into implementation details
> 
> ---
> 
> 
> /**
>  * aa_query_ipc - query @origin as to whether it can ipc with @target
>  * @origin: origin profile for the ipc request
>  * @target: target profile for the ipc request
>  * @symmetric: whether the communication needs to be symmetric or asymmetric
>  * @perms: Return - if successful permission granted for ipc between @origin
>  *         and @target
Hrmmm, so the symmetric parameter really isn't needed, as this isn't a yes
no type question.  A symmetric communication would be implied by getting both
read and write back in the perms.