FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 11-06-2010, 09:20 PM
maximilian attems
 
Default Paris MiniDebConf Minutes

On Sun, Nov 07, 2010 at 03:43:40AM +0530, Ritesh Raj Sarraf wrote:
> Hello Kernel Team,
>
> http://wiki.debian.org/DebianKernel/Meetings
>
> 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 ?

the decisions will be made public soon.
please have a little patience.


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101106222053.GG19612@vostochny.stro.at">http://lists.debian.org/20101106222053.GG19612@vostochny.stro.at
 
Old 11-08-2010, 07:31 PM
Kees Cook
 
Default Paris MiniDebConf Minutes

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

Thanks,

-Kees

--
Kees Cook @debian.org


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101108203115.GP5876@outflux.net">http://lists.debian.org/20101108203115.GP5876@outflux.net
 
Old 11-08-2010, 09:13 PM
Ben Hutchings
 
Default Paris MiniDebConf Minutes

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?

> 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).

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101108221302.GB31963@decadent.org.uk">http://lists.debian.org/20101108221302.GB31963@decadent.org.uk
 
Old 11-08-2010, 09:43 PM
Kees Cook
 
Default Paris MiniDebConf Minutes

On Mon, Nov 08, 2010 at 10:13:02PM +0000, Ben Hutchings wrote:
> 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).

Right, this is an upstream limitation of the LSM when they made it
non-modular, unfortunately. If a distro wants to make multiple LSMs
available to their users, they have to compile them all in. Which is rather
annoying.

-Kees

--
Kees Cook @debian.org


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101108224321.GT5876@outflux.net">http://lists.debian.org/20101108224321.GT5876@outflux.net
 
Old 11-09-2010, 09:56 AM
Ian Campbell
 
Default Paris MiniDebConf Minutes

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 ;-)

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

Ian.
--
Ian Campbell
Current Noise: Cryptopsy - Born Headless

Our business is run on trust. We trust you will pay in advance.


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1289300191.13236.15740.camel@zakaz.uk.xensource.co m">http://lists.debian.org/1289300191.13236.15740.camel@zakaz.uk.xensource.co m
 
Old 11-10-2010, 01:31 AM
Ben Hutchings
 
Default Paris MiniDebConf Minutes

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.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 

Thread Tools




All times are GMT. The time now is 07:43 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org