[Oneiric][Patch 0/3] AppArmor update for Oneiric v2

[Tim Gardner]

On 08/12/2011 09:35 AM, John Johansen wrote:
> On 08/12/2011 06:23 AM, Tim Gardner wrote:
>> On 08/11/2011 01:59 PM, John Johansen wrote:
>>> - Drop sync of compatibility patches
>>> - reworked rlimits patch to not require AppArmor: add utility
>>> function to get an arbitrary tasks profile.
>>> - dropped AppArmor: Add kvzalloc to handle zeroing for kvmalloc
>>> - dropped AppArmor: Remove "permipc" command
>>> - updated to apply AppArmor: add support for generic perm query again
>>> current profile
>>>
>>> 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 (3):
>>> AppArmor: Relax the restrictions on setting rlimits
>>> AppArmor: Allow loading of policy containing generic policy dfa
>>> AppArmor: add support for generic perm query
>>>
>>> security/apparmor/apparmorfs-24.c | 2 +-
>>> security/apparmor/file.c | 2 +-
>>> security/apparmor/include/file.h | 2 ++
>>> security/apparmor/include/policy.h | 4 ++++
>>> security/apparmor/include/procattr.h | 1 +
>>> security/apparmor/lsm.c | 12 ++++++++----
>>> security/apparmor/policy.c | 1 +
>>> security/apparmor/policy_unpack.c | 11 +++++++++++
>>> security/apparmor/procattr.c | 34 ++++++++++++++++++++++++++++++++++
>>> security/apparmor/resource.c | 15 ++++++++++++---
>>> 10 files changed, 75 insertions(+), 9 deletions(-)
>>>
>>>
>>>
>>
>> John - the patches look OK. However, while I can tell _what_ they are
>> doing, I don't know _why_. _Why_ are you relaxing restrictions on
>> setting rlimits? _Why_ do patches 2 and 3 appear to be adding new
>> features that haven't been vetted by upstream ?
>>
> https://blueprints.launchpad.net/ubuntu/+spec/security-o-apparmor-dbus
>
> the feature development happened this cycle, with DBus happening after
> the Ralley, its 95% userspace but still needs access to policy. The
> policy dfa, which the dbus patches are split off from, is a much larger
> patchset that I had certain planned to have pushed already but is
> undergoing another round of revision. For dbus I managed to split what
> it needs out into patches that don't affect current enforcement, or
> features so it will only take affect if you opt in to the dbus mediation.

Well, that makes a bit more sense. How about updating the the commit 
logs such that they describe their relevancy to the specification, e.g., 
we're relaxing rlimits restrictions because feature X in spec Y requires 
certain behaviors, blah, blah...

-- 
Tim Gardner tim.gardner at canonical.com