[apparmor] First draft of a userspace ipc introspection interface

[John Johansen]

On 11/18/2010 04:20 PM, Kees Cook wrote:
> Hi John,
> 
> This all looks good. One question below...
> 
> On Wed, Nov 17, 2010 at 06:35:01PM -0800, John Johansen wrote:
>> /**
>>  * aa_query_task_ipc - query @origin task as to whether it can ipc with @target
>>  * @origin: origin task for the ipc request
>>  * @target: target task 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
>>  *
>>  * Returns: 0 on success with permissions in @perms
>>  *         -1 on failure, with errno set to the error condition
>>  */
>> int aa_query_task_ipc(pid_t origin, pid_t target, int symmetric,
>> 		      aa_perms_t *perms);
> 
> What would the backend access control look like on this? It doesn't feel
> right to allow me to ask if two arbitrary pids can talk to eachother.
> Perhaps they must match the owner or something? This smacks of PTRACE
> insanity.
>

well it is going to be controlled both by dac and the profile.  The backend for
the ipc question is a little fuzzy yet,

I had been meaning to map the exec pid question onto /proc/<origin pid>/attr/exec
as that is actually already used for this purpose if change_profile onexec is
overriding regular exec rules.  However the pure profile to profile question
will have to be handled differently, and I was planning for a general profile
introspection interface mapped into apparmorfs.

So for pid to pid at the profile level this would require access to the
/proc/<pid>/attr/exec file and for the first pass being either unconfined, having
MAC_ADMIN, or having the same profile as origin that is being examined.  The
restrictions can and will need to be tinked with some but I am still thinking
about what they should be.

The ipc question doesn't have a good mapping in /proc/<pid>/attr/ so I haven't
figured where to put that yet.  We could propose a new /proc/<pid>/attr/ file
but that will likely not go over to well.  We could just use one of the existing
unused files
   fscreate  keycreate  sockcreate

but I am not thrilled with that idea, and we might want to use them in a hybrid
model.

We can't multiplex the ipc onto current, exec, or prev because of how they are
currently used.  Current reports the current profile, and takes the change_hat/
change_profile commands.  Prev reports the parent profile when in a hat and
could be used to report the previous profile in general.  Exec is currently used
to take the change_profile on exec command, and report the exec override,
and I plan to map the exec question onto as it fits in nicely.

Basically I had decided to go with a transaction based file interface, I am not
fond of doing netlink as a command reply interface but that is a possibility.

But no matter what the interface, the asking task will need sufficient perms.
In fact I think it is desirable to not allow a task to introspect it self without
the correct entries in its profile.  Also requests to introspect that fail should
be longed just like a regular access request that fails.