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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox