[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