[Oneiric][Patch 0/13] AppArmor update for Oneiric

[Tim Gardner]

On 08/11/2011 11:09 AM, John Johansen wrote:
> On 08/11/2011 09:49 AM, Tim Gardner wrote:
>> On 08/11/2011 10:20 AM, John Johansen wrote:
>>> On 08/11/2011 08:16 AM, Tim Gardner wrote:
>>>> On 08/10/2011 11:02 PM, John Johansen wrote:
>>>>> The following patch series reverts and updates the compatibility
>>>>> patches
>>>>> along with adding new functionality for oneiric.
>>>>>
>>>>> The following changes since commit
>>>>> 7731cf0ecf5412872d5a4a25ab3ace22690f4408:
>>>>>
>>>>> UBUNTU: Ubuntu-3.0.0-8.10 (2011-08-05 11:33:35 -0700)
>>>>>
>>>>> are available in the git repository at:
>>>>> git://kernel.ubuntu.com/jj/ubuntu-oneiric.git apparmor
>>>>>
>>>>> John Johansen (13):
>>>>> Revert "UBUNTU: SAUCE: AppArmor: Fix unpack of network tables."
>>>>> Revert "AppArmor: compatibility patch for v5 interface"
>>>>> Revert "AppArmor: compatibility patch for v5 network controll"
>>>>> Revert "UBUNTU: SAUCE: AppArmor: Allow dfa backward compatibility
>>>>> with broken userspace"
>>>>> AppArmor: compatibility patch for v5 network controll
>>>>> AppArmor: compatibility patch for v5 interface
>>>>> AppArmor: Allow dfa backward compatibility with broken userspace
>>>>> AppArmor: add utility function to get an arbitrary tasks profile.
>>>>> AppArmor: Relax the restrictions on setting rlimits
>>>>> AppArmor: Add kvzalloc to handle zeroing for kvmalloc
>>>>> AppArmor: Allow loading of policy containing generic policy dfa
>>>>> AppArmor: Remove "permipc" command
>>>>> AppArmor: add support for generic perm query again current profile
>>>>>
>>>>> security/apparmor/Makefile | 22 ++++++++++++----
>>>>> security/apparmor/apparmorfs-24.c | 2 +-
>>>>> security/apparmor/apparmorfs.c | 2 +-
>>>>> security/apparmor/context.c | 17 +++++++++++++
>>>>> security/apparmor/domain.c | 10 ++-----
>>>>> security/apparmor/file.c | 2 +-
>>>>> security/apparmor/include/apparmor.h | 12 ++++++++-
>>>>> security/apparmor/include/context.h | 44
>>>>> +++++++++++++++++++++------------
>>>>> security/apparmor/include/file.h | 2 +
>>>>> security/apparmor/include/policy.h | 4 +++
>>>>> security/apparmor/include/procattr.h | 2 +-
>>>>> security/apparmor/ipc.c | 13 +++-------
>>>>> security/apparmor/lib.c | 7 +++--
>>>>> security/apparmor/lsm.c | 14 ++++++----
>>>>> security/apparmor/match.c | 2 +-
>>>>> security/apparmor/policy.c | 1 +
>>>>> security/apparmor/policy_unpack.c | 11 ++++++++
>>>>> security/apparmor/procattr.c | 34 ++++++++++++++++++++++++--
>>>>> security/apparmor/resource.c | 11 ++++++--
>>>>> 19 files changed, 153 insertions(+), 59 deletions(-)
>>>>>
>>>>>
>>>>
>>>> What is the state of these patches with respect to upstream review?
>>>> Have they landed in Morris' tree at least? linux-next ?
>>>>
>>> no,
>>> the compatibility patches, won't be going up, the reverts on those
>>> aren't even necessary it was more just to synchronize them with the
>>> slightly update versions carried in the upstream apparmor trees.
>>> Revert "UBUNTU: SAUCE: AppArmor: Fix unpack of network tables."
>>> Revert "AppArmor: compatibility patch for v5 interface"
>>> Revert "AppArmor: compatibility patch for v5 network controll"
>>> Revert "UBUNTU: SAUCE: AppArmor: Allow dfa backward compatibility with
>>> broken userspace"
>>> AppArmor: compatibility patch for v5 network controll
>>> AppArmor: compatibility patch for v5 interface
>>> AppArmor: Allow dfa backward compatibility with broken userspace
>>>
>>>
>>> the other patches are a subset of a much larger set, that I am preparing
>>> for submission. Out of those we can break the patches into two sets
>>> - the loosening of rlimits restrictions and the patch it pulled in
>>> (utility fn to get ...),
>>> AppArmor: add utility function to get an arbitrary tasks profile.
>>> AppArmor: Relax the restrictions on setting rlimits
>>>
>>> I could have backported "Relax the restrictions on setting rlimits"
>>> instead and dropped the second patch, but decided to try to keep to what
>>> is being submitted upstream. The relaxing of the rlimit to the profile
>>> level instead of the only the current task, is just nice to have and
>>> matched up with some of the changes that went into the userspace. So not
>>> strictly necessary.
>>>
>>> - The patch that got pulled in because of a use of kvzalloc, but I split
>>> the patch calling it and ended up removing its use. I didn't notice that
>>> the dependency was no longer there so we can actually drop this one.
>>> AppArmor: Add kvzalloc to handle zeroing for kvmalloc
>>>
>>> - the policy dfa
>>> AppArmor: Allow loading of policy containing generic policy dfa
>>> AppArmor: Remove "permipc" command
>>> AppArmor: add support for generic perm query again current profile
>>>
>>> These allow loading the generic policy dfa, and querying it from
>>> userspace. This doesn't actually change any kernel mediation yet, and is
>>> only being used by userspace to query about dbus messaging policy, which
>>> will be an opt in (default off) extension for oneiric. This is almost
>>> the minimal patchset to support the dbus mediation feature, I could have
>>> dropped "AppArmor: Remove "permipc" command".
>>>
>>> I purposefully excluded the majority of the policy dfa patch queue, as
>>> parts of it isn't ready yet and it does affect in kernel mediation and I
>>> wanted at a minimum upstream review on it first before pulling it in,
>>> and ideally we will just pick it up from upstream (ie. its not for
>>> oneiric).
>>>
>>>
>>>> I think 'AppArmor: Add kvzalloc to handle zeroing for kvmalloc' is
>>>> completely mis-described.
>>>>
>>> Hrmmm, not well described perhaps. It should be more along the lines of
>>>
>>> Allow passing of flags to kvalloc and add kvzalloc wrapper function in
>>> vein of kzalloc
>>>
>>
>> I guess I don't understand why the compatibility patches aren't going
>> upstream?
> They are parts that got a NAK for one reason or another and what is or
> will be upstream is incompatible with an older userspace. We will be
> able to drop them in P+1, and if we don't support booting a P kernel on
> Lucid we can drop them in P.
>
>> I can't imagine Ubuntu is the only distro that might want a more
>> recent kernel in an older, stable user space.
> Nope suse, pld and a few others carry them as well
>
>> I'm also reluctant to diverge so much from upstream.
>>
> I can certainly understand, as that is why I axed multiple features that
> where planned for oneiric but aren't in -next yet.
>
> The largest part of the deviation are the compatibility patches, I tried
> to prune the deviation down to a minimum.

OK, can you resend the pull request with the clean-ups you mentioned above?
-- 
Tim Gardner tim.gardner at canonical.com