[apparmor] [PATCH v2] apparmor: implement profile-based query interface in apparmorfs

[John Johansen]

On 03/06/2013 04:10 PM, Seth Arnold wrote:
> On Tue, Mar 05, 2013 at 06:38:35PM -0800, Tyler Hicks wrote:
> 
> This looks really good. A few nitpicks inline..
> 
>> Allow userspace applications to query for allowed, denied, audit, and
>> quiet permissions using a profile name and a DFA match string. Userspace
>> applications that wish to enforce access controls defined in the
>> system's AppArmor policy can use this interface to perform access
>> control lookups.
>>
>> This patch adds a new file, called .access, to the apparmorfs root
>> directory. The semantics of the .access file should be hidden behind a
>> libapparmor interface, but the process for doing a query looks like
>> this:
>>
>> open("/sys/kernel/security/apparmor/.access", O_RDWR) = 3
>> write(3, "profile\0/usr/bin/app\0 system\0org"..., 98) = 98
>> read(3, "allow 0x000002\ndeny 0x000000\naud"..., 1024) = 59
>> close(3) = 0
>>
>> The write() buffer contains the prefix specific to the current type of
>> current ("profile\0" in this case), the profile name followed by a '\0',
> 
>   ^^^^^^^ should be 'query'
> 
>> and the binary DFA match string. The read() buffer contains the query
>> results. Here's an example of the query results:
>>
>> allow 0x000002
>> deny 0x000000
>> audit 0x000000
>> quiet 0x000000
> 
> I may have tuned out a discussion on IRC about the 'deny' flags -- at
> least it feels like a conversation I've ignored :) -- but the profiles
> currently communicate 'deny' through the 'quiet' flags. What use is there
> for 'deny' in this interface? Is a 'loud explicit deny' something we're
> intending to add?
>
Actually no. Currently deny is carried by a lack of allow, quiet is only
applied once its decided to potentially audit something and allow/deny
has already been determined.

With the permission rework, we will have a field for explicit deny
as it is needed if we ever do composition of precompiled policy chunks.
Whether it will ever be needed at the interface I am less sure but it
would allow us to toggle to a black list mode for say debugging etc.

I talked to tyler about the separate masks and felt it was better to
leave them unprocessed so that the trusted helper would have full information
instead of only seeing something prefiltered by the kernel.

We could leave deny out atm and just add it if we see a need but I also
don't see its presence as harmful