<div bgcolor="#FFFFFF" text="#000000">
    <div>On 12/19/2012 11:24 PM, John Johansen
      wrote:<br>
    </div>
    <blockquote type="cite">
      <pre>On 12/19/2012 05:55 AM, alexofen wrote:
</pre>
      <blockquote type="cite">
        <pre>Dear people working with AppArmor,

[...]
</pre>
      </blockquote>
      <pre>[...]
Generally we take the approach of if the policy is strict enough that the user is turning it off then it is of no benefit, so we default to a more relaxed targeted policy that raises the bar but is not perfect. For those who want tighter security, and want to learn/deal with the added complexity we try to make it easy for them to update the policy.</pre>

    </blockquote>
    Why should we care about people that do not appreciate security and
    are willingiy discarding all for the little effort involved?<br>
    I see the point totally, I only do not share the conclusion<br>
    <br>
    <blockquote type="cite">
      <pre>For arbitrary execution of unknown code we are working on improving our dynamic sandboxing so that these applications can be run in very tight little containers.</pre>
    </blockquote>
    Is AA connected to the LXC project? is LXC what you referred to?
    <blockquote type="cite">
      <blockquote type="cite">
        <pre>Is there a way to have something like a fallback/default deny thing for applications that are not profiled?
</pre>
      </blockquote>
      <pre>you can define a default profile by doing

profile default /** {
  #insert default profile rules here
}

to have this applied to all processes it must be precompiled and loaded from the init ramfs

However a default policy does not really end up being much different than unconfined.</pre>
    </blockquote>
    why would there be no difference?<br>
    Assume in a attack scenario I can manage to dispose a executable
    somewhere.<br>
    a) without the default rule this executable would be (that is how I
    understand it) without a AA profile and hence<br>
    NO AAprofile equals unconficed. Only DAX left. <br>
    <br>
    b) with a default or fallback rule the executable likewise to above
    does not have a dedicated AA-profile, but (again  this is my
    undestanding or idea)<br>
    there can be still some restrictions (those of the default).<br>
    <br>
    <blockquote type="cite">
      <pre></pre>
      <blockquote type="cite">
        <pre>The ease of deployment should not be the primary concern and the safety sacrifized. The product sold (AppArmor)
</pre>
      </blockquote>
      <pre>Our experience is actually contrary to this. Users will turn off security if it gets in their way too much. Generally speaking users don't understand and don't want to understand security, they just want to do what they want and it gets in their way. Our single biggest problem is that users complain that our loose targeted policy is too tight and they just turn it off instead of tweaking it for what they want. Security that isn't used has no benefit, a loose targeted policy while imperfect still raises the bar and is better than nothing.</pre>

    </blockquote>
    Thank you for sharing the experience. Maybe I am thinking "no pain,
    no gain", having stricter rules, even at the short-term necessitated
    effort would result in a long-term security gain. It's a absurd
    thinking but in a way AA this idea is like this "better a poorly
    working diet" than one that the person skips. Well anyhow either way
    we will have overweight person. (I excuse this crude example). I
    just so much think any progress is done once the necessity exits, as
    long as you exemp users from doing some work (its mostly the
    distributions maintainers, right) they happily free-ride and do very
    little, since possible<br>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre>without profiles is rather useless (as it is in most desktop Ubuntus) and I assume only by setting it active fall all programs via
</pre>
      </blockquote>
      <pre>AppArmor is not sold, its a community project that distros are free to integrate into their systems. It is impossible for us to define a strinct policy that would work for a distro as each distro is different and would have to modify it to suite their system.</pre>

    </blockquote>
    I wanna apologize here. I used a very bad term. Let me take the
    chance to applaud and thank the people giving effort and work an
    life for this good thing AA. <br>
    <blockquote type="cite">
      <pre>A default profile can provide extra security, but it takes additional effort. Without a broader profile set with profiles on all applications that require special privilege, a default profile that works is effectively the equivalent of unconfined.</pre>

    </blockquote>
    I am sceptical that it should or must be equivalent with unconfined.
    Can you elaborate why / how you mean this?<br>
    <blockquote type="cite"><br>
      <blockquote type="cite">
        <pre>I do not wanna provoke or insult etc. And if for heaven's sake it must be that we have cases in which AppArmor
is deployed with this kind of "everything unprofiled is white", that is ok. But what is the trick to setup a default profile

</pre>
      </blockquote>
      <pre>np. no insult taken, its a valid question. As I said above targeted policy has been the projects focus because of experience with users and distros, that doesn't mean we don't want to be able to provide strict policy and we have slowly improved our ability here.</pre>

    </blockquote>
    That is good to here. As you see I was worried it could have been
    taken the wrong way, just because I have quite some strong wishes
    and opnion in terms of what should be strict security etc. etc. But
    indeed I really like the AA project of course<br>
    <blockquote type="cite">
      <pre>The default profile solution is to provide a profile that matches everything

default /** {

}

</pre>
    </blockquote>
    regards,<br>
    Alexander<br>
  </div>