Thanks Crispin and Stephen for your earlier advice.
Crispin Cowan wrote:
AppArmor logs stuff using either the classic syslog method or the new LAF method.
Stephen Smalley wrote:
You can use the audit subsystem
The version of AppArmor source I have (with suse 10.1) seams to use the
audit subsystem. I am currently also using the audit subsystem.
Stephen Smalley wrote:
An alternative approach to implementing your own LSM would be to look at
modifying the SELinux security server (code under security/selinux/ss,
interface defined by security/selinux/include/security.h), as that is
the policy engine for SELinux and has a general interface for security
decisions that isn't tied to a specific policy model. Then you would be
able to reuse the rest of SELinux, including both the rest of the kernel
code, the userland support, etc.
Or possibly you could even represent your "policies" as configurations
of SELinux, and avoid having to modify kernel code at all. The
configuration language for SELinux is quite flexible.
My model/design is too unconventional for either of these options. (not
to mention that pathname based confinement will be used - although that
may change - and no I am not trying to start that debate again)
Crispin Cowan wrote:
Why use multiple modules? The stacking mechanism is painful at
best,and security policy composition in the general case is intractable.
It was just an early implementation idea, which as you point out would
be pointless and hard to manage.
Just a thought:
Do security modules such as selinux and apparmor currently stack correctly?
If not, do you think that this may be partially responsible for the
friction between the two camps? Users have to choose one or the other -
yet they actually provide different types of security.
-
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
