[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apparmor-dev
Subject:    Re: [Apparmor-dev] Towards AppArmor 3.0
From:       "Rob Meijer" <capibara () xs4all ! nl>
Date:       2008-12-06 10:05:18
Message-ID: 20345.82.95.100.23.1228557918.squirrel () webmail ! xs4all ! nl
[Download RAW message or body]

On Sat, December 6, 2008 02:27, John Johansen wrote:
> Rob Meijer wrote:
>> On Fri, December 5, 2008 07:42, John Johansen wrote:
>>> If you have
>>> an idea or feature you would like to see, please don't hesitate to join
>>> into the discussion, or email me privately.
>>>
>>>
>>> john
>>
>> Hi John,
>>
>> I have a few features that would be very interesting with respect to
>> using AppArmor as the base for using MinorFs.
>>
>>
>> 1) Reading of symbolic links governed by explicit profile rules.
> yes, the exact details yet to be resolved but this will happen
>
>> 2) A way to express /proc/$SELFPID in a profile.
> yep again.  The plan is to have a few special variables that get
> expanded in the kernel.
>   @{PID} was what I was going to propose for this, as this follows
> AppArmors current syntax but that is open for debate.

Great.

>> 3) A facility for use by a user space process (such as minorviewfs) that
>>    can be used to map a process-id to a unforgeable call-chain-id.
> I am unsure of what you mean by unforgetable call-chain-id here.
> Do you mean
> - an interface to set/get a special call-chain-id on a process or
>   AppArmor setting a special call-chain-id and just an interface to
>   retrieve it.
>
> - If AppArmor is setting the call-chain-id is it based off of the parent
>   child relationship or processes, or should it be based on the parent
>   child relationship of profiles, or even a special id based off of both

Both,

Currently minorviewfs parses /proc/* data to first create an XML
representation like the one attached to this mail, and than calculates the
SHA1 digest of the XML data for use as call-chain-id. This works, but is
rather high overhead to do in userspace IMO. If AppArmor could provide a
simular facility, this could I feel be made much more efficient.
If the 'codefiles' and the 'parentmap' could together be represented as
some unique id, and the 'right' codefile could be made visible in this id,
 than minorviewfs would next to this call-chain-id further only need to
look at the commandline and enviroment of the process to do its work.

So an ideal id for this example could look like:

  26e911f3294dcae667fa6b9b23e96663520161a7@/bin/ls

Rob
Rob
["meta.xml" (application/octet-stream)]

_______________________________________________
Apparmor-dev mailing list
Apparmor-dev@forge.novell.com
http://forge.novell.com/mailman/listinfo/apparmor-dev

[prev in list] [next in list] [prev in thread] [next in thread]