[apparmor] [PATCH 23/32] apparmor: provide the ability to boot with a default profile set on init
John Johansen
john.johansen at canonical.com
Fri Feb 1 12:58:19 UTC 2013
On 01/30/2013 10:27 PM, Seth Arnold wrote:
> On Wed, Jan 16, 2013 at 01:28:52PM -0800, John Johansen wrote:
>> add the ability to boot with a basic default profile instead of the
>> unconfined state. This provides a way to provide total system confinement
>> without having to load policy in the init ramfs.
>>
>> The basic default profile can be replaced during early boot to achieve
>> system confinement.
>>
>> Signed-off-by: John Johansen <john.johansen at canonical.com>
>> ---
>> security/apparmor/Kconfig | 11 +++++++++++
>> security/apparmor/apparmorfs.c | 4 ++++
>> security/apparmor/include/apparmor.h | 1 +
>> security/apparmor/include/policy.h | 1 +
>> security/apparmor/lsm.c | 17 ++++++++++++++---
>> security/apparmor/policy.c | 21 +++++++++++++++++++++
>> security/apparmor/procattr.c | 8 +++++---
>> 7 files changed, 57 insertions(+), 6 deletions(-)
>
> This was a lot simpler than I expected. Nice.
>
>> diff --git a/security/apparmor/Kconfig b/security/apparmor/Kconfig
>> index 9b9013b..1108be7 100644
>> --- a/security/apparmor/Kconfig
>> +++ b/security/apparmor/Kconfig
>> @@ -29,3 +29,14 @@ config SECURITY_APPARMOR_BOOTPARAM_VALUE
>> boot.
>>
>> If you are unsure how to answer this question, answer 1.
>> +
>> +config SECURITY_APPARMOR_UNCONFINED_INIT
>> + bool "Set init to unconfined on boot"
>> + depends on SECURITY_APPARMOR
>> + default y
>> + help
>> + This option determines policy behavior during early boot by
>> + placing the init process in the unconfined state, or the
>> + 'default' profile.
>> +
>> + If you are unsure how to answer this question, answer T.
>
> "answer Y" :)
>
>> /**
>> * set_init_cxt - set a task context and profile on the first task.
>> - *
>> - * TODO: allow setting an alternate profile than unconfined
>> */
>> static int __init set_init_cxt(void)
>> {
>> @@ -881,7 +884,15 @@ static int __init set_init_cxt(void)
>> if (!cxt)
>> return -ENOMEM;
>>
>> - cxt->profile = aa_get_profile(root_ns->unconfined);
>> + if (!aa_g_unconfined_init) {
>> + cxt->profile = aa_setup_default_profile();
>> + if (!cxt->profile) {
>> + aa_free_task_context(cxt);
>> + return -ENOMEM;
>> + }
>> + /* fs setup of default is done in aa_create_aafs() */
>> + } else
>> + cxt->profile = aa_get_profile(root_ns->unconfined);
>> cred_cxt(cred) = cxt;
>
> What's the consequences of returning -ENOMEM here? I traced it back up
> through security_initcall() and gave up when it looked like magic kernel
> magic invoked it through magic. :)
>
> Does it fail to boot? (Secure.) Does it boot anyhow?
>
Sadly the return value is just ignored atm
static void __init do_security_initcalls(void)
{
initcall_t *call;
call = __security_initcall_start;
while (call < __security_initcall_end) {
(*call) ();
call++;
}
}
this walks the set of initcalls that are stored in the security_initcall
section during kernel compile.
(*call) ();
does the actual call to each modules init fn that is set by using the macro
security_initcall()
But sadly you can see it does not look at the return value. Anyways if your
curious you can look in security/apparmor/lsm.c for the apparmor fn
More information about the AppArmor
mailing list