[apparmor] Default deny access to the directory

[John Johansen]

On 01/16/2015 02:58 AM, Dmitry Kasatkin wrote:
> 
> 
> On 16 January 2015 at 11:25, John Johansen <john.johansen at canonical.com <mailto:john.johansen at canonical.com>> wrote:
> 
>     On 01/15/2015 07:39 PM, Seth Arnold wrote:
>     > On Thu, Jan 15, 2015 at 08:23:22PM +0200, Dmitry Kasatkin wrote:
>     >> I am running stock Ubuntu 14.10 and there I would like to create a policy
>     >> which allows program '/sbin/appd' to access directory '/etc/appd/', but
>     >> forbid for any other program having profile or not.
>     >>
>     >> Is there anyway to specify "default" policy which denies access to
>     >> /etc/food?
>     >
>     > You can achieve something like this using AppArmor with some work:
>     > http://wiki.apparmor.net/index.php/FullSystemPolicy
>     >
>     > The gist is that you'd create a profile suitable for your 'init' process,
>     > create profiles suitable for "everything else", the other profiles on your
>     > system, and a profile for /sbin/appd.
>     >
> 
> 
> ​This approach comes when look to how Apparmor currently works..
> ​That what I want to avoid creating profiles for everything.
> 
> ​
>  
> 
>     > None of the profiles would have /etc/appd/ permissions except the
>     > /sbin/appd profile.
>     > 
> 
>     > Every process on your system would then run confined in a profile; at
>     > least one profile would probably need to be quite permissive -- nearly
>     > everything would run under that profile.
>     >
>     > I haven't yet tried this for myself; I expect it's a fair amount of work
>     > to get it just right.
>     >
>     yes and no, its currently a pita to load a profile early enough to confine
>     init because it needs to be loaded in the initrd. Basically you need to
>     compile the policy and stuff it in the initrd with something to load it.
>     Its not hard, I've done it but it is not something we have automated tools
>     to do atm.
> 
>     There is the experimental default profile work that allows specifying a
>     default profile that starts in an unconfined state, and then can be replaced
>     into an enforing state. This means you need to trust your init up to the
>     profile load but that is generally the case because apparmor isn't checking
>     for inconsistent labeling from on offline attack.
> 
>     I think the real problem is currently policy is exclusively specified at
>     the profile level. This makes it hard to specify a rule that should be
>     applied globally.
> 
> 
> ​This is something I was looking - "fallback"​
>  
> ​/ global profile for anything has no profiles... That way I could be possible to limit access to resources system wide.
> 

perhaps there is a bit of a misunderstanding of apparmor profiles. They can be
generic and not bound to a specific executable. So a system wide fallback profile
is possible.

Generally people think of the profile name and attachment interchangeably

Eg.
  /usr/bin/ping {
     # enforce confinement on /usr/bin/ping executable
  }

However the attachment specification (rule) and name can be separate

  # profile with a name of default
  # attachment rule of /**
  profile default /** {

     # This will attach to any new exec that does not have a more specific profile
     # specified

     /** Pix,	# transition to the most specific profile match
  }

This allows a general default profile,
  /** is the most generic attachment and hence will only be applied
      if there is no other profile that matches

The rule /** Pix, rule in the profile is also involved in determining what profile
is transitioned to when an application is confined by the default profile.

  Basically the internal rule is applied first.  If the pattern is matched then
  the permission and transition mode is consulted.

    P - says to consult the loaded profiles
    i - says to fallback to inherit the current profile if no profile match was
        (wouldn't happen with the way the current default profile is defined)
    x - is granting the exec perm.

Having the local rule take priority makes it possible for a profile to override
the generic profile attachment.

Eg.
  profile firefox /usr/lib/firefox {
    /bin/evince Cx -> child_profile,
    /** Pix,

    profile child_profile {

    }
  }

In this case evince is sent into a special firefox local profile, even if there
is a global evince profile defined.

So it is possible to have global rules via a generic profile, but I think the
current setup is harder for people to understand than it needs to be. Right
now the default profile has to be explicitly defined and, any global denials
need to be setup in an include or explicitly within the profiles.

Having some "global" rules that are correctly applied as part of the compile
would be easier.

Now to the other part of the problem, Loading the default profile during
regular boot instead of using the initrd still leaves the early init and
processes unconfined, with currently no way to confine those applications
after the fact.

Loading the profile from the initrd or using the experimental default profile
fixes this problem. If you are fine with the init process and what ever
it launched before profile load running unconfined, the default profile
can provide a global rules without having to define profiles for every
application.