>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
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
