On Tue, 2010-11-09 at 10:56 +0000, Ian Campbell wrote:
> On Mon, 2010-11-08 at 22:13 +0000, Ben Hutchings wrote:
> > On Mon, Nov 08, 2010 at 12:31:15PM -0800, Kees Cook wrote:
> > > Hi,
> > >
> > > On Sat, 2010-11-06 at 22:23 +0000, Ben Hutchings wrote:
> > > > On Sun, 2010-11-07 at 03:43 +0530, Ritesh Raj Sarraf wrote:
> > > > > The wiki lists most items marked as done. I am just curious to know what
> > > > > the decision has been made for AppArmor. Will it be enabled ?
> > > >
> > > > Only if we can find a way to make it modular or discardable.
> > >
> > > Hm? LSMs cannot be made modular.
> > Currently, no. Is there a logical reason why this is unfeasible?
> Speculating somewhat (since I don't know the internals of any LSM) but I
> guess there is an argument that the LSM needs to be present and
> measuring (or whatever) from start of day to be affective, or at least
> to avoid some potentially large or intractable amount of work at
> initrd/modprobe time to validate or reconstruct the state at the time
> the LSM is loaded. I'd have thought that validating the initrd along
> with the vmlinux would be sufficient, but what would I know ;-)
I did suspect that might be the case, so I was looking first at the
possibility of discarding code/data.
> > > AppArmor is upstream already, so the
> > > question on the agenda was to add back the old-style interface methods
> > > and network mediation (so the userspace tools will work sanely). The
> > > desired LSM is selected at boot-time, so that's highly "discardable".
> > > The agenda item wasn't asking for it to be the default LSM, just to be
> > > available at all.
> > By 'discardable' I mean that it would be possible to free the memory used
> > for its code and static data if it was not used (similar to the way init
> > code is discarded after boot).
> There was talk on LKML recently of allowing statically compiled code to
> be registered with the system as if it were a preloaded module, such
> that it can subsequently be rmmod'd.
> This was in the context of IOMMUs which have similar properties to LSM
> in that a whole bunch need to be compiled into the kernel at start of
> day but only some small number actually end up being used.
> See http://article.gmane.org/gmane.linux.kernel/1051547 and in
> particular hpa's responses.
Thanks very much for the pointer.
Once a job is fouled up, anything done to improve it makes it worse.