[apparmor] default profile

Jamie Strandboge jamie at canonical.com
Fri May 10 20:04:16 UTC 2013


On 05/10/2013 01:24 PM, John Johansen wrote:
> So with apparmor 3.0 we pickup a default profile that can be used to confine
> init, without having to load policy in the initrd and then re-exec init
> 
Cool! :)

> how this works is the default profile starts in the unconfined mode and init
> in early boot is unconfined. Once the default profile is replaced
> everything in the default profile picks up the new confinement.
> 
> to replace the default profile you define a new
> 
> profile default {
>   ..
> }
> 
> and load it, or if you want it to have default attachment
> 
> profile default /** {
>   ...
> }
> 

I don't understand the difference between these, can you explain? (The
source of my not understanding is that unconfined seems to already have
attachment to everything, and so if we setup the default profile, to me,
that implies everything attaches to it).

...

> 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 :)

> 
> 
> 2. default attachment
> 
> currently specifying the attachment may not be what you want it means that
> px will always find a profile. This is different behavior from what you
> would get with unconfined.
> 
> Instead a rule in the default profile can be used
> 
>   profile default {
>     /** pix,
>   }
> 
> This will retain the current unconfined behavior of other profiles px and
> pix failing/inheriting if a profile is not defined.
> 
> Is this adequate? It certainly needs to be documented.
> 

I think we want to define what we intend for the default profile to do.
First off, I think if you setup a default profile you should be expected
to know what you are doing. Second, I think the default profile should
provide a blank slate for people to use if they choose to. Third, we do
need to make sure that we document things, like you said, so people
understand what is happening.

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.

As such, if you define the default profile, everything will attach to it
(just like everything attaches to unconfined when there are no other
profiles defined on the system). It is then up to the policy writer to
determine how transitions work. Since there are some subtleties here and
we believe that there may be best practices surrounding the default
profile, we might then say that it is best practice to have the default
profile include this at minimum:

profile default {
   ...
   /** pix,
   ...
}

since this will allow transitions to existing profiles on the system in
the manner people are accustomed to.

> 
> 3. Profile/Namespace removal
> Currently when a profile or namespace is removed it inherits the task
> that where confined by the profile inherit the unconfined profile.
> 
> If the default profile is selected should this be inherited instead of
> the unconfined profile.
> 
I did not understand the first sentence, but I think I understand the
question. IMO, because the default profile wholly replaces
apparmor=unconfined, it should be inherited.

> 
> 4. ux
> 
> there is no equivalent ux, pux for the default profile, and I would rather
> avoid dx, and pdx
> 
> Instead ux can be replaced with
>   /foo px -> default,
> 
> but we have nothing to enable a fall back like pux
> a glob rule like
>   /** px -> default,
> 
> would come close as long as no other x rules used globbing and you
> wanted the fallback to apply to all x rules (you usually don't)
> 
> We need to fix the overlapping x rule problem (this is just compiler work),
> ie.
>   /** px -> default,
>   /usr/* px,
> 
> will currently fail to compile, but this still does not give use per rule
> control of the fallback.
> 
> Finally we could introduce the explicit fallback that steve suggested years
> ago
> 
>   /usr/bin/* px -> @{\1}, default, inherit,
> 
> (Note: syntax is just of the cuff and would need to be worked on)
> 
> 
> 
> 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?

profile default {
  /** pix,
}

/bin/foo {
  /bin/bar ux,
}

/bin/bar {}

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.

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
document 'u' as another word when the default profile is in use.
'u'nspecified maybe?

That said, I think this requires more exploration.

> 
> 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,
}

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
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.


-- 
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/1d67a6ee/attachment.pgp>


More information about the AppArmor mailing list