[apparmor] [SROS] Reuse of ApprArmor’s utils python library?

[Christian Boltz]

Hello,

Am Montag, 6. März 2017, 19:40:09 CET schrieb ruffsl:
> We are a few developers for SROS, a project geared towards securing
> the Robotic Operating System [1]. We’d like to inquire about some of
> the inner workings of ApprArmor’s utils python library [2] for
> several aspects: security event logging, policy profile syntax
> parsing, and logprof/genprof CLI tools.
...
> We are currently developing features to enable ROS users to specify
> these policies into the underlying protocol. In addition we’d like to
> make it simple to generate policies via learning by demonstration or
> auditing logged events, as well as provide a simple set of CLI tools
> much like apparmor has now for amending policies.
> 
> To do this, we’d like to see what amount of apparmor utility code
> could be reused, what sections of the code base may be most
> applicable, and perhaps if any common core functions could be shared.
> We'd like the idea of code reuse here, as there is much security
> policy oriented features, syntax, and unittests we would like to
> mirror for our own middleware for robotic systems. So if you’d be
> willing, we’d like to start a dialogue and find what we can learn
> from your community.

You are more than welcome to use the AppArmor utils - ideally by using
    from apparmor.whatever import what, you, need
to avoid copying code around (and having to maintain your copy).

Let me add some words about the stability of our interface/API.

Right now, the aa-* tools are the only consumers of the apparmor.** 
python modules, which means we regularly do quite some changes(including 
interface changes) without risking to break someone externally.

I'm quite sure the apparmor.rule.* classes are stable - I don't have any 
plans to change their interface (it took too long to invent something 
that works for all rule types ;-) - but some additions might happen. 
Also, the apparmor.rule.* classes usually have 100% test coverage.

OTOH, modules in the aparmor.* namespace (aa.py, aamode.py, logparser.py 
etc.) contain older code, and parts of them need to be rewritten sooner 
or later. This will likely also cause interface changes. If you use code 
from these modules, I'd recommend that you submit some unittests (name 
them "test-interface-used-by-sros.py") that call the functions you are 
using [1]. This will ensure that we don't accidently break something you 
need, and can discuss how to handle unavoidable changes.

> [2] http://bazaar.launchpad.net/~apparmor-dev/apparmor/2.10/file
> s/head:/utils/

I'd recommend to use the master branch ;-)

> P.S. I suppose it's been a while, but a couple months ago we sent out
> audit request for our AppArmor profile for ROS. I believe the audit
> is still open for for suggestions and recommendations, your feedback
> and expertise is really appreciated.

Sorry, ENOTIME ;-) - but maybe someone else has some time to look at 
them.


Regards,

Christian Boltz

[1] ideally those tests should also check if those functions do the 
    right thing - but that might be something that should go into "our"
    unittests, not the "test-interface-used-by-sros.py"
-- 
[SuSE 8.2] Auch die Paketverwaltung via YaST2 ist endlich einigermaßen
brauchbar: Du kannst ein Paket auf ein permanentes "Tabu" setzen und -
jetzt kommt die Überraschung - er überschreibt es _wirklich_ nicht! ;-)
[René Matthäi in suse-linux]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20170307/5a96c9df/attachment.pgp>