linux-security-module April 2007 archive
Main Archive Page > Month Archives  > linux-security-module archives
linux-security-module: Re: New to LSM list. A few questions.

Re: New to LSM list. A few questions.

From: Crispin Cowan <crispin_at_nospam>
Date: Thu Apr 26 2007 - 09:24:02 GMT
To: Cliffe <cliffe@iinet.net.au>


Cliffe wrote:
> 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)?

Sure.

> 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?
The papers are ok for the overall concepts and history, but they are grossly out of date. Read the current kernel source for current information.

> 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?

The best way to write kernel code is to steal it. AppArmor logs stuff using either the classic syslog method or the new LAF method. Steal the code (subject to the GPL) and modify it to do what you want. Look also at the SELinux code for a different perspective on how to do things, and steal from the code you find suits you the best.

> 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?

Why use multiple modules? The stacking mechanism is painful at best,and security policy composition in the general case is intractable. Better to implement all your stuff in a single module, unless you need to be able to deploy one module without the other.

Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com - 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