Contents |
One of the goals of the project is to welcome and encourage external development.
To aid in this the following document describes some development that is already in progress (to avoid unnecessary duplication) and also future ideas we have that are as yet unimplemented.
Some of the future ideas are listed as "planned internal development".
This is not meant to discourage external development, but only an indication that they are more advanced features requiring a deeper understanding of the technology. There are also ideas listed that are perhaps more suitable for new developers.
Either way, your ideas are very much welcomed although we obviously cannot guarantee to incorporate every one. Please subscribe to the development list and feel free to ask questions. Other lists worth reading are the LSM list at:
http://vger.kernel.org/vger-lists.html#linux-security-module
Status: Kernel code complete, user tool changes complete. Performance issues remain with extensive use of audit subsystem.
Integrate blacklist based access control. Both global blacklist and per-profile blacklist
Status: Single global blacklist support implemented (ability to prevent non-confined processes from accessing specified files). Pending further analysis related to sufficient blacklist to prevent feature compromise.
Add 1st class support for list based variables and conditional processing to profile systax.
Status: Parser support complete; profile generation tools need help to make the most of variables and conditionals.
Ability to distribute policy changes to systems allowing local changes to be merged with upstream/vendor changes. Initially 2 way merge, subsequently plan is to offer 3 way merge.
Status: In development
Status: kernel work completed; parser work nearly finished; profile generation tools not yet started.
Alleviate need for namespace_sem patch.
Status: Work beginning
Develop new submodule with globbing support using kernel textsearch framework. Likely require that new submodule also implements a new textsearch algorithm.
Analyze rw lock contention on 8/16 way systems. Potentially re-implement using RCU.
Extend support to include network confinement. A draft implementation was completed (older code base) but there were issues with performing incoming mediation from softirq context due to LSM hook placement, shared descriptors and changehat. Solution is likely syntactic changes/limitations to limit what is allowable. Ask on list for more information.
Replace current "complain" mode method of profile 'learning' with in kernel mechanism that can better track things such as domain transistions and create less of a logging overhead. Profile being built in kernel would be exposed into AppArmor virtual filesystem. Memory usage is an issue that needs to be considered/evaluated.
Add parser and kernel support for internal capabilities. Currently internal AppArmor code often adds capable(CAP_XXX) often SYS_ADMIN which is already overloaded enough. Adding new internal capabilities (for want of a better word) which can be asserted in the profile and tested in the module is required.
Currently chrooted pathnames are reported relative to the chroot. This makes generation of profiles userside difficult and also open to possible exploit, is /bin/foo an absolute or relative to some chrootd_path changes are required to be able to report them relative to the absroot (patch available but not upstream). Alternatively, retaining relative pathnames but knowing when a task is in a chroot and reporting this (may require new LSM hook). Or perhaps more ideal, adding a new changehat type feature where chroot switches task into new subprofile. Issues here with tasks sharing a root (CLONEFS) and ensuring all are switched.
Add support for named transitions:
/sbin/exec {
/sbin/subexec px -> specific_profile,
}
Currently an exec of '/sbin/subexec px' by a confined process will result in the new task using the standard system profile for subexec, the above syntax allows an exec within this particular confinement to switch to a specific profile.
Current unresolved issue is how to handle files open in an unconfined process and duped onto a new confined task.
Improve linear algorithms (profile list and per profile rule list).
Provide mechanisms to view contents of loaded profiles/subprofiles. For example, the profile usr.sbin.postfix (/usr/sbin/postfix) when loaded would generate a filesystem node such as /sys/kernel/security/apparmor/profiles/usr/sbin/postfix which could be read outputting what policy is loaded. More likely it would be a directory with subfiles for profile, sub profiles and other statistics.
This would virtualize information about what features the module provides. For example, the parser could use this information to determine if certain policy can not be supported before attempting to load it. Initially, the output of the submodules sdmatch_features should be virtualized into the features subdirectory so that the parser will not attempt to load rules containing globs if the sdmatch module does not support them (see "Develop non-PCRE literal sdmatch module" above).
Provide additional hints from the userspace parser about glob and tailglob entries. These could be used by the kernel module to optimise processing. For example, tailglob could be extended to be tailglob_extension for rules of the form **.ext and the module could perform initial tail matching on .ext$. More advanced tree based schemes for full interior globs are possible.
Add module support for a limited set of variables expanded at runtime. For example, $PID and $TTY so that profile rules such as /var/log/foo.$PID can be used for logfiles rather than /var/log/foo.[0-9]* as currently.
AppArmor should expose controls for setting resource limits that would be enforced for confined applications. When transitioning between profiles, we should set rlimits according to values in the profile.
We have a prototype PAM module that will call change_hat() with the username of an authenticated user. Some configuration options to use groupname or another table lookup mechanism would likely make the module more useful.
We have a prototype Tomcat valve to add change_hat support; please ask on the mail list for details.
Nothing is yet known if Jakarta's architecture would lend itself to a change_hat plugin.
Nothing is yet known if JBoss's architecture would lend itself to a change_hat plugin.
We could more easily provide GUI interfaces to notify users of insufficient policy if the AppArmor system reported events via DBUS.
HAL can be instructed by any DBUS-enabled application to take a wide variety of privileged actions on behalf of potentially unprivileged or AppArmor-confined processes. HAL or DBUS or both need to be extended to provide plug-in modules the opportunity to perform mediation; this plug-in architecture should be flexible enough to provide both an AppArmor-style "direct listing" of owned/controlled resources as well as an SELinux-style type enforcement abstraction. Integration with or replacement of resmgr and pam_console are probably desirable.
© 2009 Novell, Inc. All Rights Reserved.
