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

[John Johansen]

On 07/03/2013 01:10 AM, Rob Meijer wrote:
> 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?

I think its fair to say its planned for. Its something we would really
like this fall but are just running out of time

> 
> 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
I'm not opposed to that, I know we have discussed it in the past. I'll let
others speak for themselves.

> 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
We have tried to use the Linux kernel code style templates, but I wouldn't
say you have to adhere to that. Minorfs would be its own corner and we could
live with a differ style, its not like the python or perl based tools
don't have their own styles.

My personal take is that you try to stick to the style of the code your
in.

> for submitting the MinorFs2 codebase for inclusion in AppArmor 3.2 ?
> 
My guess is feature freeze would be somewhere around the start of February.