[Apparmor-dev] Network definitions in profile

[Cliffe]

Hi John and Markku,

What you are describing is closely related to my PhD research. I have 
been working on this problem for some time, and part of my work involves 
creating these kind of policies.

I used AppArmor profiles as a starting point for policy, and all the 
policies and software I am creating will be GPL open sourced. My initial 
theory/model design should be published soon and the proof of concept 
software and policies will follow. Hopefully my work will contribute to 
your AppArmor efforts, although it may be more efficient use of time if 
you wait for my results before tackling the same problem.

Regards,

Z. Cliffe Schreuders
BSc Comp Sci (Hons) & Int Comp
PhD Candidate, Casual Tutor
School of IT
Murdoch University
c.schreuders at murdoch.edu.au
cliffe at ii.net


John Johansen wrote:
> On Wed, Dec 05, 2007 at 10:19:26PM +0800, Lincoln Yeoh wrote:
>   
>> At 06:04 PM 12/4/2007, Markku Savela wrote:
>>     
>>> 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.
>>>       
>> I agree that this sort of thing is a better approach, a bit like "security 
>> by contract" :).
>>
>> Would it be possible to have templates for such profiles? Either a template 
>> is a more high level description of a profile, or profiles are generalized 
>> to fit more apps that are similar.
>>
>>     
> yes, it is possible.  The trade off is more lack security.
>
>   
>> The idea is to reduce the number of possible profiles for popular 
>> applications to a more manageable number of templates which normal users 
>> might be more able to cope with.
>>
>>     
> There are a few possible ways to go about this, but the basis of any
> approach is setting up good abstractions for the classes that are
> desired.  Of course identifying meaningful classes and making generic
> abstractions isn't easy, but it is possible.
>
> One thing that would make it easier is defining a good set of variables
> for those classes and let installation of new apps modify the variables
> so the abstraction get expanded as new applications are installed.
>
> Profile wise you can then setup application profiles that include those
> abstractions or you can setup a generic profile, for each abstraction
> and a master profile that can control entering that abstraction.
>
> This latter approach in its full form isn't possible with current
> releases of AppArmor, it needs the generalized transition model which I
> haven't pushed out yet.
>
>
>   
>> It may require a lot more standardization of apps - installation 
>> directories, temporary files, where to share read-only files with other 
>> apps, logging etc.
>>
>>     
> standardizing apps would make security better but it just isn't going
> to happen.  There are too many apps, and too much legacy
>
>   
>> If such standardization is not possible (maybe only Apple could pull such a 
>> thing off), we might have to have trusted parties audit profiles (with 
>> corresponding app), labelling/classifying them (from maybe a dozen or so 
>> standard types) and then sign them. e.g. "Basic screensaver", "Guest 
>> applet", "web browser", "Administrator privileges", "Full user privileges". 
>> This is less desirable of course.
>>
>>     
> It is possible, and perhaps even desirable but there are many apps that
> fall into multiple catagories depending on their use, or even because
> of different confinement strategies.
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Apparmor-dev mailing list
> Apparmor-dev at forge.novell.com
> http://forge.novell.com/mailman/listinfo/apparmor-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://forge.novell.com/pipermail/apparmor-dev/attachments/20071210/017d35cd/attachment.html