[apparmor] Retrofitting & access-control impedance mismatch for MinorFs

[Rob Meijer]

On Wed, July 3, 2013 09:04, John Johansen wrote:
> On 06/25/2013 04:27 AM, Rob Meijer wrote:
>> Basically I think there would 3 distinct possibilities:
>>
>> 1) The default policy you describe helps to keep any non-special process
>>    from doing a readlink on  @{PROC}/@{OTHERPID}/fd/*. This would solve
>> the
>>    whole issue. No performance price. No sacrificing functionality.
>>    No confused deputies.
> right so this isn't possible atm but we are working on it. Specifically we
> do have a plan, and I have been gradually working on it. It requires
> improvements
> to the compiler and matching engine, and we don't have it scheduled to
> land
> in the up coming 3.0 release.
>
> It is a possibility for the following 3.1 release in the spring.
>
>> 2) CapFs is made to only allow /minor-mnt/cap/ access to higher lever
>>    MinorFs file-systems and these file-systems work as overlay
>> file-system.
>>    There is no authority leakage possible, but there is a performance
>> issue.
>>    Next to this, the ability to decompose,attenuate and delegate ones
>>    private storage sub-tree to other processes is sacrificed.
> right
>
>> 3) Either the default policy or the CapFs file-system could deny access
>> to
>>    /minor-mnt/cap/*. This leaves open the confused deputy issue, but
>> doesn't
>>    have the performance or functionality price of 2.
>>
> Could you live with this solution until 1 is complete?
>
>> The issue with 3 would be that Malet could readlink for example
>> /proc/1000/fd/5 and gain access to the pseudo path for Alice her private
>> directory. Malet couldn't access this path herself, but Bob could. If
>> Malet can convince Bob to access the file on her behalf, than we have a
>> confused deputy problem.
>>
>> I think its fair to conclude that '1' is the preferred option, and that
>> this preferred option depends on (at-least) AppArmor version 3 to be
>> sufficiently secure. Will AppArmor 3 allow expressing something like a
>> deny for @{PROC}/@{OTHERPID}/fd/* in a default policy? If so, what order
>> of magnitude timescale are we looking at for version 3?
>>
> So again 3.0 won't have this but I have been working on it.  3.0 is
> scheduled
> to land this fall, feature freeze around the start of September and ship
> in mid October.
>
> Will be the 6 month followup and is scheduled for the spring of next year.
> I wish I could say that we will have @{pid} and the other kernel vars
> support for 3.0 because it would solve several problems, not just for
> minorfs but with the current set of work we still have to get done.
> I don't see it happening, and the planning is currently for 3.1

Given the fact that MinorFs is my spare-time project and I only have a few
hours a week of spare-time, spring 2014 seems like a perfectly reasonable
timeline for me to aim my own target release-date for.

B.t.w, I'm giving a talk at the OHM2013 conference next month (
http://ohm2013.capibara.com/ ), could I state that 'AppArmor 3.1
(projected for spring 2014) will allow  the configuration of default
process-private file-handles' or would that be premature?

An other question, if I manage to get the first release of MinorFs2 also
ready next spring, it might be interesting to see if MinorFs2 could become
part of the AppArmor user-space tool-set. Would you be open to this? If so
are there any (C++) coding and/or style and/or documentation guidelines I
would need to make my code-base adhere to? And what would be the deadline
for submitting the MinorFs2 codebase for inclusion in AppArmor 3.2 ?

Tnx,

Rob