[apparmor] default profile

[Jamie Strandboge]

On 05/10/2013 03:48 PM, John Johansen wrote:
> On 05/10/2013 01:04 PM, Jamie Strandboge wrote:
>> On 05/10/2013 01:24 PM, John Johansen wrote:

...

>>> currently the override to select the default profile is
>>>   apparmor.unconfined=0  or N
>>>
>>> and to select unconfined
>>>   apparmor.unconfined=Y
>>>
>>> this option is fine but I'm not fond of apparmor.unconfined=0 We could
>>> change this so that the apparmor= boot option could select the values, so
>>> something like
>>>
>>>   apparmor=unconfined
>>>
>>>   apparmor=default
>>>
>>
>> +1 :)
>>
> I'm fine with apparmor=unconfined, but not so happy with apparmor=default
> 
> other suggestion might be
> apparmor=enforce
> apparmor=confined
> 

I recognize why 'default' looks weird because the current default
everywhere that doesn't have the 'default' profile yet is unconfined.
That said, I don't like apparmor=enforce and apparmor=confined because
those aren't the names of profiles, and assume something about the
default profile (ie, that it is confined when it might actually be quite
lenient).

...

>> To me, the default profile is one which wholly replaces what apparmor
>> would normally do if booting with apparmor=unconfined. I also think
>> that, if possible, the default profile should be able to be defined such
>> that it the system will behave exactly like when booting with
>> apparmor=confined. This would be useful for testing and also helps
>> ensure a 'blank slate' is truly possible.
>>
> hrmm I'm not sure I follow you here. So here is a broad shot at some more
> detail.
> 

Sorry, I was trying to be clear but a couple of typos and my own
grammar-breakage didn't help. I'm reaffirming that the default profile
should be a wholesale replacement of the unconfined profile when loaded
and that a policy writer ideally should be able to write a default
profile (without '(unconfined)') that makes the system behave
identically to when booted with apparmor=unconfined.

> The policy author is free to define default however they want, including
> complain mode or any other rule combinations, transitions etc that are
> available to other profiles.
> 
> The author does need to define what goes in default if default is not in
> the unconfined mode. We have the issue of not being able to define what
> goes in default until it is replaced.
> 
> The default profile does make it possible to load the default profile in
> the initrd without having to re-exec init, and have confinement apply.
> But we can not define policy as part of the kernel boot parameters
> because we are not putting the compiler in the kernel.
> 
Sure.

> In general there should be some guidance to authors on how to use the
> default profile, and what should/shouldn't go in it.
> 
> Eg. It would be a very bad idea to stick
>   /** px,
> 
> in the profile and load it without other profiles in the same atomic set.
> 
Agreed.

...

>>> Now to ux, should that even work when the default profile is selected
>>> or should we just fail it, as ux remains away to escape confinement
>>> and the default profile?
>>>
>>
>> I think that the transition to unconfined that ux represents should not
>> be supported when the default profile is selected. 'u' stands for
>> 'unconfined' and when the default profile is selected, there is nothing
>> that is 'unconfined' (sure, things may be effectually unconfined, but
>> that is different).
>>
>> I recognize this is a problem with usability though. Ie, if I already
>> have a profile with [Uu]x in it and want to start using the default
>> profile, what do we do? The profile is still correct syntactically and
>> the parser shouldn't have to know if the default profile is in place. It
>> seems like [Uu]x in a profile on a system with the default profile
>> enabled should transparently allow transitions back to the default
>> profile so things don't break, but even that gets weird because the
>> default profile may have '/** pix,', so what does this actually mean?
>>
> yeah its a hard problem.
> 
> I am inclined to just leave the transition to ux as is at the moment,
> though maybe we make it mean transition to default
>
Transitioning to actual unconfined I guess is ok, especially if we tell
policy writers to use non-ux rules, but then I think it is difficult for
people (distributions or otherwise) to move over to the default profile
because they have to fix a bunch of stuff. Sure, things would still
work, but perhaps not as the policy writer expected.

> I think just failing it could be problematic as it could result in odd
> breakage.
> 
Agreed.

> We certainly should actively discourage its use
> 
Yes.

>> profile default {
>>   /** pix,
>> }
>>
>> /bin/foo {
>>   /bin/bar ux,
>> }
>>
>> /bin/bar {}
>>
> right now it mean bin/bar when started from /bin/foo will be put in the
> unconfined profile, and the unconfined profile behaves as it always does
> 

/me nods

>> The profiler intended that /bin/bar go unconfined when executed by foo.
>> Having the transition go to 'default' cause of the ux makes sense, but
>> then default defines the attachment such that bar gets '/bin/bar {}' policy.
>>
> nope. The exec rule for the profile on the subject is applied so ux (if it
> transitioned to default) would mean the exec went into the default profile
> and subsequent execs would depend on the rules defined in the default profile
> 

Ah, yes I see what you mean, we won't chain the rules.

>> As weird as it is, this seems correct to me. If 'profile default {}'
>> didn't have the '/** pix,' rule there would be no problem. Maybe we can
> as mentioned above it is not a problem because it does not apply to the
> exec from /bin/foo
> 

Right, and this makes sense.

>> document 'u' as another word when the default profile is in use.
>> 'u'nspecified maybe?
>>
> this is possible, or just the default profile which is usually unconfined
> 

Well, I think I don't like the term 'unconfined' when referencing the
default profile because the term is a bit overloaded and we don't know
that the default profile is any more confined than unconfined.
...

>>>
>>> 5. Tooling
>>>
>>> Currently the userspace tooling does not work well with the default
>>> profile or the unconfined mode. This needs to get updated. But the question
>>> remains how aa-status et al should represent profiles in the unconfined
>>> mode.
>>>
>>> should it report them as confined, unconfined, ...
>>>
>>
>> Confined because there is a profile defined for them. Case in point,
>> even now I can define this:
>> /bin/foo {
>>   file,
>>   capability,
>>   network,
>>   mount,
>>   dbus,
>> }
>>
> yes but then nothing is unconfined.
> 
> IF we wanted we could have multiple profiles in the unconfined state and
> they could all be reported as a single unconfined. I'm not sure that is
> best, just an option
> 
Well, I didn't explain this well, due to the overloaded terms. See below.

>> and aa-status will happily say it is confined. If the default profile is
>> truly a blank slate, we can't guess what the policy is. aa-status knows
> well its mode reports whether its unconfined or enforcing etc.
> 
>> the default policy is in place, so it can use this when apparmor=unconfined:
>> ...
>> 248 processes are unconfined but have a profile defined.
>>
>> and this when apparmor=default:
>> ...
>> 248 processes are using the default profile but have a profile defined.
>>
> Heh that looks funny, I'd rather just
> 
> 248 processes are using the default profile
> 
Well, it does look better, but I was trying to have the same
differentiation as we do now with unconfined. Ie, there is some system
profile in place (unconfined or default) and then there are profiles for
specific parts of the system (cups, libvirt VMs, etc) and then there are
processes that are either using a specific profile or some system
profile. Your change does look better but it doesn't communicate that
there is a more specific profile that it probably should be using (eg,
when using the default profile and dhclient started before its
/etc/apparmor.d/sbin.dhclient loaded).

-- 
Jamie Strandboge                 http://www.ubuntu.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130510/9d9daa01/attachment.pgp>