[Apparmor-dev] Network definitions in profile

[John Johansen]

On Tue, Dec 04, 2007 at 12:04:21PM +0200, Markku Savela wrote:
> Hi,
> 
> I'm not disagreeing strongly on anything. The following is only to 
> clarify my thoughs about this...
> 
hehe, no problem, I wouldn't mind if you were disagreeing strongly

> 
> ext John Johansen wrote:
> 
> > ... and I also think quibbling about the syntax isn't actually all
> > that important at this stage.  Since the "bind" syntax version and
> > the limited accept version are functionally equivalent, I would far
> > rather focus on getting a working prototype and then playing with
> > the syntax.
> 
> Whether "bind" or "accept" is used, I think the "quibbling about
> syntax" is actually very important thing. Once past the prototype and
> after first release, the syntax cannot be changed. The existing
> profiles using the limited syntax must work as is even after future
> extensions.
> 
yes after an initial protype it becomes very important, and must
become resolved before it can become part of apparmor.

The reasons I said it wasn't important for the initial protyping were:
- the proposals are pretty much functionally equivalent.  You could
  extend the accept based on to label the bound socket as to whether
  it was accepting, connecting or both.
- I find that prototyping often leads to a revised thinking on syntax
  so it may result in some proposed changes anyway
- it allows parallelizing the discussion of syntax and initial
  implementation.

> My vision for the profiles is that they should be generated by the
> application writers, and included in packages in signed
> repositories. An installer install the profile, and either refuse to
> install or install with some predefined default profile, if profile is
> missing.
> 
> The idea is that application comes with clear statement what resources
> it intends to use (AppArmor profile). The repository maintainer or
> anyone looking at the package could view the profile and evaluate
> whether it is reasonable for the application in question.
> 
yes that is a very nice goal (Crispin in particular will appreciate
it) and something apparmor strives for.

The packaging and dependency end of profiles is something that needs
to be worked on and I am going to kick off an email dedicated to
that topic with some proposals this week.

> For this to work, the profiles really must be simple and clear for
> application writers to generate and easy to visually verify. This is
> why I don't think "bind" keyword is such bad idea (but, "accept" works
> too).  If application writer is writing a server or otherwise needs
> socket bound to specific port/address, the "bind" is the function to
> use.
> 
right, "bind" isn't so bad, but I like the extensibility of "accept"
and it more closely matches what is done in firewall rules, which
is what most admins are familure with.

Of course I am aware that what we are doing is already different than
most standard firewalls in that the rules are declarative instead
of ordered (I believe bsd's pf is declarative as well).  So there
is precedence for changing things if it will improve the syntax or
is a simplification that is worth the trade off.

My fear is that "bind" can't be extended in the way that "accept" can
and that in the future the extension will be both of them so that
there is two ways of expressing something that are subtly different.

> Application writer, of course, can use the predefined abstractions for
> the generic stuff, and add only requirements which are directly
> relevant to the application code.
> 
yep, which also brings up that we need to improve our abstractions too :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://forge.novell.com/pipermail/apparmor-dev/attachments/20071204/d975f969/attachment.pgp