From: John Johansen <john.johansen@canonical.com>
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org
Subject: Re: [PATCH 11/13] AppArmor: LSM interface, and security module initialization
Date: Thu, 15 Jul 2010 11:04:44 -0700 [thread overview]
Message-ID: <4C3F4DBC.7010200@canonical.com> (raw)
In-Reply-To: <20100715172757.GA26839@hallyn.com>
On 07/15/2010 10:27 AM, Serge E. Hallyn wrote:
> Quoting John Johansen (john.johansen@canonical.com):
>> AppArmor hooks to interface with the LSM, module parameters and module
>> initialization.
>>
>> Signed-off-by: John Johansen <john.johansen@canonical.com>
>
> Thanks, John - looks good overall. Comments:
>
> ...
>
>> +static int apparmor_ptrace_access_check(struct task_struct *child,
>> + unsigned int mode)
>> +{
>> + int rc;
>> +
>> + rc = cap_ptrace_access_check(child, mode);
>> + if (rc)
>> + return rc;
>> +
>> + return aa_ptrace(current, child, mode);
>> +}
>> +
>> +static int apparmor_ptrace_traceme(struct task_struct *parent)
>> +{
>
> Just curious - why aren't you calling cap_ptrace_traceme() first here?
>
err, we should be. I'm not sure where that got dropped. I'll go through
and re audit all of these.
thanks
>> + return aa_ptrace(parent, current, PTRACE_MODE_ATTACH);
>> +}
>> +
>> +/* Derived from security/commoncap.c:cap_capget */
>> +static int apparmor_capget(struct task_struct *target, kernel_cap_t *effective,
>> + kernel_cap_t *inheritable, kernel_cap_t *permitted)
>> +{
>> + struct aa_profile *profile;
>> + const struct cred *cred;
>> +
>> + rcu_read_lock();
>> + cred = __task_cred(target);
>> + profile = aa_cred_profile(cred);
>> +
>> + *effective = cred->cap_effective;
>> + *inheritable = cred->cap_inheritable;
>> + *permitted = cred->cap_permitted;
>> +
>> + if (!unconfined(profile))
>> + *effective = cap_intersect(*effective, profile->caps.allow);
>
> Should you mask permitted too? Otherwise you might confuse a userspace
> lib which assumes it's caller previously culled pE, and that it can
> nwo refill it from pP.
>
yes indeed thanks
>> + rcu_read_unlock();
>> +
>> + return 0;
>> +}
>> +
>> +static int apparmor_capable(struct task_struct *task, const struct cred *cred,
>> + int cap, int audit)
>> +{
>> + struct aa_profile *profile;
>> + /* cap_capable returns 0 on success, else -EPERM */
>> + int error = cap_capable(task, cred, cap, audit);
>
> jinkeys, it might be just me, but i'd have spend 2 mins less looking
> at this if you'd done
>
> if (error)
> return error;
>
> here, simplifying the condition below.
>
>> +
>> + profile = aa_cred_profile(cred);
>> + if (!error && !unconfined(profile))
>> + error = aa_capable(task, profile, cap, audit);
>> +
>> + return error;
>> +}
>
yeah, that is better
thanks Serge
next prev parent reply other threads:[~2010-07-15 18:04 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-15 0:43 [AppArmor #5 0/13] AppArmor security module John Johansen
2010-07-15 0:43 ` [PATCH 01/13] AppArmor: misc. base functions and defines John Johansen
2010-07-15 0:43 ` [PATCH 02/13] AppArmor: basic auditing infrastructure John Johansen
2010-07-15 15:18 ` Eric Paris
2010-07-15 16:36 ` John Johansen
2010-07-15 17:36 ` Eric Paris
2010-07-15 18:07 ` John Johansen
2010-07-15 0:43 ` [PATCH 03/13] AppArmor: contexts used in attaching policy to system objects John Johansen
2010-07-15 0:43 ` [PATCH 04/13] AppArmor: core policy routines John Johansen
2010-07-15 15:33 ` Eric Paris
2010-07-15 16:40 ` John Johansen
2010-07-15 0:43 ` [PATCH 05/13] AppArmor: dfa match engine John Johansen
2010-07-15 0:43 ` [PATCH 06/13] AppArmor: policy routines for loading and unpacking policy John Johansen
2010-07-15 0:43 ` [PATCH 07/13] AppArmor: userspace interfaces John Johansen
2010-07-15 0:43 ` [PATCH 08/13] AppArmor: file enforcement routines John Johansen
2010-07-15 0:43 ` [PATCH 09/13] AppArmor: mediation of non file objects John Johansen
2010-07-15 0:43 ` [PATCH 10/13] AppArmor: domain functions for domain transition John Johansen
2010-07-15 0:43 ` [PATCH 11/13] AppArmor: LSM interface, and security module initialization John Johansen
2010-07-15 17:27 ` Serge E. Hallyn
2010-07-15 18:04 ` John Johansen [this message]
2010-07-15 0:43 ` [PATCH 12/13] AppArmor: Enable configuring and building of the AppArmor security module John Johansen
2010-07-15 0:43 ` [PATCH 13/13] AppArmor: update Maintainer and Documentation/kernel-parameters.txt John Johansen
2010-07-15 13:06 ` [AppArmor #5 0/13] AppArmor security module Miklos Szeredi
2010-07-16 5:21 ` Tetsuo Handa
2010-07-16 16:37 ` John Johansen
2010-07-17 7:41 ` Tetsuo Handa
-- strict thread matches above, loose matches on Subject: below --
2010-07-27 2:57 [AppArmor #6 " John Johansen
2010-07-27 2:57 ` [PATCH 11/13] AppArmor: LSM interface, and security module initialization John Johansen
2010-07-29 21:47 [AppArmor #7 0/13] AppArmor security module John Johansen
2010-07-29 21:48 ` [PATCH 11/13] AppArmor: LSM interface, and security module initialization John Johansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C3F4DBC.7010200@canonical.com \
--to=john.johansen@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=serge@hallyn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.