[Apparmor-general] Features vs Roadmap

[John Johansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mitnyan.Manuel at hydro.qc.ca wrote:
> Hi,
>  
> I can't find any roadmap for the project, only mailing list thread talking about new/future functionnality. Is there is one ?
>  
>  
There is one, but it is badly out of date and pretty much worthless
http://developer.novell.com/wiki/index.php/Apparmor_dev

I started to update it here
http://developer.novell.com/wiki/index.php/Apparmor_dev_stage

and I have copious amounts of text written, that need cleaned up and
added, but its one of those things that keeps falling to the bottom
of the priority queue.

> We need two feature that do not exist yet on apparmor. My concern is if they are already schedule do be done one day and if not where can I suggest them.
>  
yeah, the wiki and development road maps need to get updated.  And I
also need to get the experimental branch up so people can see some of
the stuff being worked on.  Unfortunately there has been a lack of time
as of late.

> Just in case the mailing list is the good place, here is the two feature we looking for:
>  
Any and all suggestions are always welcome on the mailing list.

> 1-Ability to discriminate/exclude permission 
>  
> Examples of what it can look like to exclude permissions on directories and files
>  
> #With nothing to mean no permissions
> /**    r,
> /noaccesstothatdirectrory    ,
> /noaccesstothatdirectrory/**    ,
>  
> so the behavior can be: 'ls /bla' = OK, 'ls /noaccesstothatdirectrory/*' = ERROR.
>  
> or 
>  
> #With a bang to say exclude permissions
> /**    rw,
> /noaccesstothatdirectrory        !w, 
> /noaccesstothatdirectrory/**    !w,
>  
> so the behavior can be:  'echo > /bla.txt' = OK, 'echo /noaccesstothatdirectrory/bla.txt' = ERROR.
>  
Well the audit control patch (scheduled for AppArmor 2.3) does add this
though in slightly different syntax.

  deny /noaccesstothatdirectory w,
  deny /noaccesstothatdirectory/** w,

the syntax has not really been openly debated and the bang ! was
considered, in fact the very syntax you proposed was considered.
The reason the leading deny syntax was chosen is that it is explicit,
its accessable to someone who may not understand !, and it can be
prepended to more than just file access rules.

The ability to carve out permissions is important but there are also
other reasons to add deny rules.
- - the tools need a way to remember what has been denied in a profile
  so that they don't prompt for the same thing over and over again.
- - there needs to be a way to quiet profiles that have known rejects
  so they don't fill up the logs, and cause excessive reporting.

The audit control patch hits all 3 concerns, and is the main reason
I have wanted to push AppArmor 2.3 as early as possible.

Under the audit control patch as it currently stands
- - deny rules exclude permissions, taking precedence over allow rules so
  that rules can have permission accumulated correctly (order doesn't
  matter)
- - deny rules provide a way for the tools to remember what has been
  denied in previous profiling runs.
- - deny rules by default quiet rejects that match them.
  If it is desirable to have a deny rule reject logged, then the audit
  key word can be prepended

  audit deny /dontallowaccess w,

The audit keyword is the other part of the audit control patch that
allows individual allow rules to specify an audit log.

eg.
audit /etc/shadow w,
audit capability dac_override,

AppArmor 2.3 should enter beta at the end of the month, so the syntax
details are still open for discussion.  We want to get it right as
once it is officially adopted the syntax has to stay for a long time.

>  
>  
>  
> 2-Validation about the parameters
> It can be good to have the granularity of the parameters permit on executable files. Regex can be a nice addon on same time ...
>  
I can understand the desire for this, but it is also problematic.  There
are some security concerns and potential race attacks on the parameters,
and there is also the problem that each program has its own rules for
parameters.  I believe the security concerns can be addressed, but I
have my doubts about the parameter parsing.  Allowing regex matching of
the parameters would handle some of those problems, but a more general
solution is desirable and getting that accepted upstream (lkml) will be
problematic.

I am not rejecting this idea, as it is something I have wanted and it
can be used to get around some of the problems we currently have with
scripts.

eg.
> /myscript foo

will get the /myscript profile associated with it, while doing

> bash /myscript foo

gets a /bin/bash profile associated with it.

The idea will definitely get added to the feature wish list, but there
are some technical issues to work out first.

Thanks for your suggestions, and time.  I will work on getting up the
new road map even if it is in a rough and partial form.

cheers
john
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHxhdDi/GH5xuqKCcRAlHZAJ9O0wbUio1a9uG7RfbM55UE68c9gQCffQtr
GnL2YzJRWajRiM4sRILo2W4=
=MgWt
-----END PGP SIGNATURE-----