lkml.org 
[lkml]   [2007]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote:
> On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:
> > On 2007-06-21T15:42:28, James Morris <jmorris@namei.org> wrote:
> >
>
> > And now, yes, I know AA doesn't mediate IPC or networking (yet), but
> > that's a missing feature, not broken by design.
>
> The incomplete mediation flows from the design, since the pathname-based
> mediation doesn't generalize to cover all objects unlike label- or
> attribute-based mediation. And the "use the natural abstraction for
> each object type" approach likewise doesn't yield any general model or
> anything that you can analyze systematically for data flow.
>
No the "incomplete" mediation does not flow from the design. We have
deliberately focused on doing the necessary modifications for pathname
based mediation. The IPC and network mediation are a wip.

We have never claimed to be using pathname-based mediation IPC or networking.
The "natural abstraction" approach does generize well enough and will
be analyzable.

> The emphasis on never modifying applications for security in AA likewise
> has an adverse impact here, as you will ultimately have to deal with
> application mediation of access to their own objects and operations not
> directly visible to the kernel (as we have already done in SELinux for
> D-BUS and others and are doing for X). Otherwise, your "protection" of
> desktop applications is easily subverted.
>
yes of course, we realize that dbus and X must be trusted applications,
this to will happen. But it will happen piece meal, something about
releasing early and often comes to mind.

> > > You might define this as a non-technical issue, but the fact that AppArmor
> > > simply does not and can not work is a fairly significant consideration, I
> > > would imagine.
> >
> > If I restrict my Mozilla to not access my on-disk mail folder, it can't
> > get there. (Barring bugs in programs which Mozilla is allowed to run
> > unconfined, sure.)
>
> Um, no. It might not be able to directly open files via that path, but
> showing that it can never read or write your mail is a rather different
> matter.
>
Actually it can be analyzed and shown. It is ugly to do and we
currently don't have a tool capable of doing it, but it is possible.
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2007-06-22 10:11    [W:0.413 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site