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

John Johansen john.johansen at canonical.com
Thu Aug 11 17:09:43 UTC 2011


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.




More information about the kernel-team mailing list