linux-kernel - Re: [PATCH v14 1/6] LSM: Security blob abstraction

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 29 Jul 2013 18:49:41 -0700
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Kees Cook <keescook@...omium.org>
CC:	LKLM <linux-kernel@...r.kernel.org>,
	LSM <linux-security-module@...r.kernel.org>,
	SE Linux <selinux@...ho.nsa.gov>,
	James Morris <jmorris@...ei.org>,
	John Johansen <john.johansen@...onical.com>,
	Eric Paris <eparis@...hat.com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH v14 1/6] LSM: Security blob abstraction

On 7/29/2013 2:15 PM, Kees Cook wrote:
> On Thu, Jul 25, 2013 at 11:32 AM, Casey Schaufler
> <casey@...aufler-ca.com> wrote:
>> Subject: [PATCH v14 1/6] LSM: Security blob abstraction
>>
>> Create an abstracted interface for security blobs.
>> Instead of directly accessing security blob pointers
>> Use lsm_get and lsm_set functions that hide the actual
>> mechanism used to maintain the security blobs. This
>> affects most uses of inode->i_security, file->f_security,
>> cred->security and similar fields in keys, sockets,
>> superblocks, ipc and keys.
>>
>> The use of a single 32 bit integer to refer to a security blob
>> does not scale to the case where there may be more than one
>> relevant security blob. Where it is possible to do so the use
>> of secids (u32) has been replaced with a struct secids, which
>> provides for multiple u32 values. There are components where
>> u32 secids remain at the request of the maintainer of that
>> component.
> If I boot with "security=apparmor", lsm_set_blob ends up with a NULL
> "bp" and Oopses the kernel. Still happens with
> "security=yama,apparmor". As soon as I add smack anywhere in the list,
> everything is fine. It seems like the AppArmor init needs to be
> changed to:
>
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 78b271a..512f430 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -875,9 +875,9 @@ static int __init set_init_cxt(void)
>                 return -ENOMEM;
>
>         cxt->profile = aa_get_profile(root_ns->unconfined);
> -       lsm_set_cred(cred, cxt, &apparmor_ops);
> -
> -       return 0;
> +       printk(KERN_INFO "AA: cred:%p cxt:%p &apparmor_ops:%p\n",
> +               cred, cxt, &apparmor_ops);
> +       return lsm_set_init_cred(cred, cxt, &apparmor_ops);

I've incorporated this fix (without the printk) and she looks good.

>  }
>
>  static int __init apparmor_init(void)
>
> Or maybe it still needs lsm_set_cred, but an earlier
> lsm_set_init_cred? It's not clear to me yet.
>
> -Kees
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/