[apparmor] AppArmor profile: requested_mask and denied_mask = "c", "x".

[John Johansen]

On 12/19/2015 10:27 AM, daniel curtis wrote:
> 
> ​Hi Christian,
> 
> So, if "c" means create file/directory then if AppArmor audit
> entries (for example from log files etc.) contains something like
> this:
> 
> operation="mkdir", requested_mask="c", denied_mask="c"
> 
> Then, rule in an AppArmor application profile should look like:
> 
> /home/user/.app/ w,
> 
yes w implies create permission

> Am I right? That should be enough? You wrote: for file 'a' (append)
> permission might be enough, right? So, instead of 'w' (see above)
> I should use 'a'? Of course if 'operation' will be responsible for
> file creation.
> 
'a' might be enough, it will depend on the flags/command used to
create the file. Eg. if the file is created using creat() then
append is enough, but if it is created using open O_RW | O_CREATE
then 'w' will be required.

You can always start with 'a' and see if the application works,
or what gets auditied

>>> That means executing another binary.
>>> Depending on what gets executed, you can choose (...)
> 
> You've asked about what gets executed. Let say, that it is, for
> example:
> 
> operation="exec", requested_mask="x", denied_mask="x"
> 
> It concerns /usr/bin/pulseaudio and /usr/lib/firefox/plugin-container.
> So, which permission should be okay in this example: 'ix', 'Cx'?
> Or maybe another one? Sorry for such naive question, but... I
> want to create a secure profile.
> 
It depends on what you are trying to achieve with your policy.

lets say we have an application A confined by a profile P that wants to
exec B,

You want to consider the relationship between the applications
px - is used for the case where the application is stand alone and you
     want to use a common confinement
cx - is used when an application/binary is used as a helper tool
     and you want a custom confinement for its use
ix - is used when an application is being used within a role, or as
     helper but it doesn't justify having its own separate confinement

if ix is used then P will need to contain all the permissions for both
A and B.  This means the profile P may be wider than is strictly needed
by A or B.
  Eg. If A is firefox and B is evince (say firefox is calling out to
      it to read a pdf) then the P will have all the permissions needed
      by firefox and evince. When evince is run it will have network
      access, this might be something you want to avoid.

However may be its a case where the utility being called shouldn't be
treated as separate in which case ix is appropriate.

The other place ix is appropriate is if your confinement is role based
ie. Log Admin role for a user, and you want everything that user runs
to be limited by the same profile. This type of policy isn't used
very much with apparmor atm but it is possible to do.


> Thank You very much for an informations about 'aa-logprof' and
> man for 'apparmor.d'. (I checked it already, but I will do it one
> more time). Definitely, I will check "AppArmor Crash Course"
> and slides at blog.cboltz.de <http://blog.cboltz.de> etc.
> 
> Best regards.​
> 
> 
> 
>