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

John Johansen john.johansen at canonical.com
Thu Aug 11 17:44:19 UTC 2011


On 08/11/2011 10:22 AM, Tim Gardner wrote:
> 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?
Do you want the synced compat patches included or would you like to stay
with the ones we currently carry?






More information about the kernel-team mailing list