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

John Johansen john.johansen at canonical.com
Fri Aug 12 15:56:25 UTC 2011


On 08/12/2011 08:51 AM, Tim Gardner wrote:
> 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...
>
Sure, I'll resubmit next week after I get a chance to sync up with jdstrand, as there is potentially 1 more patch which I am hoping we can get away with not using, and hence avoided submitting so far.





More information about the kernel-team mailing list