On Thu, 2007-04-26 at 16:46 +0800, Cliffe wrote: > G’day, > > I am a PhD candidate. My research project will involve implementing an > experimental access control model as a LSM. I have some programming > background (I teach intro to C and Java); however, I am new to kernel > programming. > > So I thought I would introduce myself. Is this mailing list an > appropriate place to ask a few questions (and later discuss the > resulting LSM)? > > I have read two papers about LSM [1, 2] which give a good foundation of > LSM, and the Linux Journal root plug example article, and I have started > reading through some LSM sources. Are any of these sources outdated? Do > you recommend any other must-read sources? > > With my [very] limited exposure to kernel-level code I am still not sure > how to go about writing information to disk. I know that generally it is > forbidden (and there is usually no need to) and there seems to be a > number of ways to communicate with user-land processes. But I basically > just want to log the arguments to a LSM hook call into a file (to poke > around and see exactly what is happening and what LSM operations > specific applications invoke). Is this possible or do I need a user-land > application to read/accept the data? For example, how does AppArmor (or > other LSMs with learning-modes) log application behaviour?
You can use the audit subsystem; kernel interface is defined by include/linux/audit.h, and you'll see examples of usage in existing modules (like SELinux, e.g. security/selinux/avc.c:avc_audit()). You definitely don't want to log every LSM hook call though, as you'll quickly fill your disk. The audit data will go to syslog (and end up in /var/log/messages) if not running auditd or to /var/log/audit/audit.log if running auditd. > I want to recursively apply the same decision logic to enforce multiple > policies (concurrently on the same subjects). Would it be practical to > have a primary security module which loads and stacks copies of a > secondary module initialised using module parameters to enforce separate > policies? No, see prior discussions of module stacking. SELinux implements several policies internally, such as RBAC, TE, and MLS, and handles the composition directly. Limited forms of module "stacking" can be used in trivial cases, like stacking with the native Linux capabilities module; again, you'll see an example of that in SELinux. 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. -- Stephen Smalley National Security Agency - 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
