[apparmor] Default deny access to the directory

[Dmitry Kasatkin]

On 16 January 2015 at 11:25, John Johansen <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.

​
​

> You can achieve it by sticking some deny rules in the base include and
> making
> sure all profiles include that except your special profile which will need
> to include a version of the base without the deny rules. Easy to do by
> moving
> abstractions/base to abstraction/base-core, and making abstraction/base
> include base-core and also specify the deny rules.
>
>
​But it works only for apps having profiles?

What about apps without profiles?

​


> However this takes more work than say having the ability to specify some
> global rules that will automatically get set on all profiles.
>
>
> There is another alternative to doing this that isn't quite ready yet.
> You can use stacking to have a master profile that enforces the denies
> and stacks regular policy under it. The exception profile would have
> rules to have it not stack.
>
>
​You mean work you mention bellow?
​


>
> TLDR: doing default policy is currently harder than it should be.
> There is work currently being done to address a couple of the pain points.
>
>
​Can you please point to source code/commit where it is being addressed?
​

​Thanks to all for answers..

- Dmitry​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20150116/1639e0ed/attachment.html>