[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Minutes of the Debian linux-2.6 Group Meeting



On Thu, Nov 18, 2010 at 11:23:39AM -0800, Kees Cook wrote:
> On Thu, Nov 11, 2010 at 13:52:12 +0000, maximilian attems wrote:
> > LSM: Enable AppArmor? as well as/instead of Tomoyo?
> > ---------------------------------------------------
> > As the LSM need to be built we can't enable them. This needs a technical
> > solution were code can be disregarded as init sections or similar.
> > AppArmor seems more popular as Opensuse and Ubuntu uses it. Technicaly
> > Tomoyo is said to be cleaner.
> 
> What do you mean by "can't" here? You can build _all_ of them,
> actually. The active LSM is just selected at boot-time through the
> kernel command line arguments. If it's a concern over kernel size,
> upstream specifically removed the ability to make the LSM modular,
> so this means that no additional LSMs will ever be available in Debian?

Julien already explained what this is about.

We don't like to bloat the kernel with features that most people won't use.
(It was controversial enough when we built IPv6 in.)  And each possible LSM
will only be used by a minority of users.

> > NX bit emulation and 32-bit mmap randomization
> > ----------------------------------------------
> > We don't want to carry intrusive patches.
> > The NX patch was rejected as such by upstream and thus we won't take
> > it either.
> 
> Why? These patches are well maintained, and touch areas of the kernel that
> do not change much (making them very easy to merge). Why leave non-PAE
> x86 users out in the code when so many other distros use some form of
> this patchset? I've worked to make sure they only touch CONFIG_X86_32,
> so they're extremely minimal.
[...]

Then you should convince upstream that these are good and unintrusive.
 
Ben.

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


Reply to: