linux-security-module November 2007 archive
Main Archive Page > Month Archives  > linux-security-module archives
linux-security-module: Re: [Apparmor-dev] Object Capabilities fo

Re: [Apparmor-dev] Object Capabilities for AppArmor

From: Rob Meijer <capibara_at_nospam>
Date: Sun Nov 18 2007 - 21:31:46 GMT
To: "apparmor-dev" <apparmor-dev@forge.novell.com>


I've tried to process your, Peter and and Mark's feedback and just placed a revised version of my first draft on http://polacanthus.net/fdoc.html

I've attempted to clearify some points that I understood to be unclear from feedback I got, and tried to make modifications from your usefull input.

I hope the updated doc will help in the discussion.

I currently have aproximately 300 hours planned for work on this over the next 10 to 13 months, either as a seperate LSM module or as a part of AppArmor (including the time I'll need to get up to speed with kernel development and AppArmor specifics).

I'll be abel to be on the irc channel sunday anywhere from 12:00 till 17:00 or anywhere from 19:00 till 23:00 localtime (I'm on GMT+1).

Rob

On Sat, November 17, 2007 20:18, Crispin Cowan wrote:
> From various discussions in these mailing lists, I have recently moved
> from on-the-fence to inclined in favor of adding some Object
> Capabilities to the AppArmor system. However, because of the UNIX
> legacy, and the way that AppArmor is intended to work, it cannot be a
> pure OC system, it will have to be some kind of a hybrid. I particularly
> like the file descriptor OC hybrid that Rob Meijer has proposed, but
> will need some refinement.
>
> For example, in UNIX file descriptors are left open on exec(), unless
> you do something to close them. Sometimes software deliberately leaves
> file descriptors open as a parameter passing technique, but there is
> also a chronic sequence of security vulnerabilities where FDs are
> unintentionally left open. Thus AppArmor needs some kind of policy
> mechanism to specify whether FDs should be left open on exec() in
> particular circumstances.
>
> To figure out just how to do this, I propose a discussion on the
> apparmor-dev mailing list (where the reply-to: is pointed) and a virtual
> conference in the #apparmor IRC room. American Thanks Giving holiday is
> coming, so I propose approximately a week's discussion, and a virtual
> conference in #apparmor on Sunday November 25th. The exact date & time
> of the virtual conference can be determined in follow-ups to this post
> on apparmor-dev.
>
> Please join this discussion if you are interested. apparmor-dev holds
> non-member posts for moderation by a human. The human policy is to
> filter spam only, but if you want your posts to go straight through
> unmoderated, please subscribe to apparmor-dev, it is not a high volume
> list. Well, it wasn't until just now :)
>
> Thanks,
> Crispin
>
> --
> Crispin Cowan, Ph.D. http://crispincowan.com/~crispin
> CEO, Mercenary Linux http://mercenarylinux.com/
> Itanium. Vista. GPLv3. Complexity at work
>
> _______________________________________________
> Apparmor-dev mailing list
> Apparmor-dev@forge.novell.com
> http://forge.novell.com/mailman/listinfo/apparmor-dev
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html