[apparmor] Profile creation and few types of questions.

[John Johansen]

On 04/16/2013 01:56 AM, Daniel Curtis wrote:
> Hi
> 
> I have a one short question about creating a
> profile for application. Let say, that I want create
> a profile for e.g. audacious. During creation ('aa-genprof'),
> system will ask some type of questions.
> 
> Questions, that I must answer to add the resource or
> program to the profile and AppArmor suggesting directory
> path entries etc,. Should I answer 'yes' to all?
>
not necessarily, some of them are required some are optional

unfortunately there is no way to know exactly is required
without either looking at the code or denying a request and
seeing how the application handles it.

> These questions are needed to run application properly,
> right? So, what should I do? It's so difficult.
> 
Right, knowing what to allow and not to allow is just hard
and all I can do is give you some guidelines.

Profile development usually happens in two phases. A learning
phase and a deployed phase. In the learning phase you don't
expose the application to a hostile environment and just
exercise the program to learn what permissions it needs.
In general its not unusually wrong to allow requests made
during a learning run, unless you see the application trying
to access something that you really don't want it to have.

Look at the severity number that genprof/logprof provides
(the higher the more sever, and worth thinking about), generally
writes and capability requests are the most dangerous and
deserve the most attention.

Execs are especially hard, as this gets into how different
applications interact. There are some applications that should
not generally have their own system wide profiles like bash
(or any shell). These generic applications are better under
their a more generic profile like a user profile or an
application helper.  Knowing what to do here is just hard.

Generally pick your application and is it used mostly as
a stand alone application or is it a utility designed to
be combined (like shell commands ls, ...). If its a stand
alone app it gets its own profile.

However stand alone apps often call out to utilities. In
general the execution of the utility for the application
can be combined into the stand alone applications profile
using ix as the exec type. Think of it as the utility is
acting on behalf of the application so it belongs in the
same security domain.

There are cases where the utility requires more privileges
than you want to give the application so you can put it,
in its own profile, either a child of the application profile
or a system profile. Unless you know what you are doing
and have good reason I would avoid this.

Starting out I suggest using just two transition types
Px - to transition to a program with a profile (this is the
     safer version with scrubbed environment variables).
ix - to inherit the current profile (used by utilities run
     by your application).

there are several other transition types but unless you
are having difficulties and need something special just
stick with the basics.

You can also reduce the number of questions etc by choosing
patterns that may cover multiple entries.

In the deployment phase the application is in a potentially
hostile environment (other people are exercising the program),
if you get a rejection in this phase, you need to examine it
carefully, it could be just something that was missed during
profile development or because the program was updated without
updating the profile, but you need to be careful to not just
taken anything from the live environment.