On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote:
Woah, that describes the userspace side of AA just fine, it means
nothing when it comes to the in-kernel implementation. There is no
reason that you can't implement the same functionality using some
totally different in-kernel solution if possible.
> SELinux is applicable in areas where AppArmor is not (e.g., MLS), but
I am still not completely certian that we can not properly implement AA
functionality using a SELinux backend solution. Yes, the current tools
that try to implement this are still lacking, and maybe the kernel needs
to change, but that is possible.
I still want to see a definition of the AA "model" that we can then use
to try to implement using whatever solution works best. As that seems
to be missing the current argument of if AA can or can not be
implemented using SELinux or something totally different should be
stopped.
So, AA developers, do you have such a document anywhere? I know there
are some old research papers, do they properly describe the current
model you are trying to implement here?
thanks,
greg k-h
-
| Peter Zijlstra | [PATCH 00/23] per device dirty throttling -v8 |
| david | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| Frans Pop | svc: failed to register lockdv1 RPC service (errno 97). |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
