From: "Giacomo A. Catenazzi" <cate@debian.org>
To: Crispin Cowan <crispin@crispincowan.com>
Cc: Thomas Fricaccia <thomas_fricacci@yahoo.com>,
linux-kernel@vger.kernel.org, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg KH <greg@kroah.com>,
LSM ML <linux-security-module@vger.kernel.org>
Subject: Re: LSM conversion to static interface
Date: Tue, 23 Oct 2007 10:17:34 +0200 [thread overview]
Message-ID: <471DAE1E.1050600@debian.org> (raw)
In-Reply-To: <471D9ECB.6060400@crispincowan.com>
Crispin Cowan wrote:
> Giacomo Catenazzi wrote:
>> What do technical and regulatory differences have "driver/LSM module" that
>> is build-in and one that is modular?
>> It seems to me silly to find difference. A kernel with a new kernel module
>> is a new kernel.
>>
> *I* understand that, from a security and logic integrity point of view,
> there is not much difference between a rebuilt-from-source kernel, and a
> standard kernel from the distro with a new module loaded.
>
> However, there is a big difference for other people, depending on their
> circumstances.
>
> * Some people live in organizations where the stock kernel is
> required, even if you are allowed to load modules. That may not
> make sense to you, but that doesn't change the rule.
[read also the very last commentary: don't take to seriously my
arguments]
ok, but why simplifying life of company with such silly rule?
Are not the same people that required commercial UNIX kernel?
So don't worry about internal company rules. In one year a lot
of things changes.
Anyway it is a good motivation to delay the conversion, if there
are really so many external LSM modules used in production environment.
(but see next point)
> * Some people are not comfortable building kernels from source. It
> doesn't matter how easy *you* think it is, it is a significant
> barrier to entry for a lot of people. Especially if their day job
> is systems or security administration, and not kernel hacking.
Configuring a new kernel is not "kernel hacking" and IIRC is considered
in the very first level of LPI.
Anyway where you will find the new module? It should be very specific
on the actual kernel installed. I find few differences to distribute
a module or a kernel. Distributions have/had a lot of kernels
(versions, SMP, processor specific, vserver, xen, readhat, clusteres,
...), so why not distribute a new kernel?
> Think of it like device drivers: Linux would be an enterprise
> failure if you had to re-compile the kernel from source every
> time you added a new kind of device and device driver.
This is a frequent argument, but I don't believe it ;-)
I see more time this argument that new devices on an enterprise.
The real argument is:
: Think of it like device drivers: Linux would be an enterprise
: failure if you had to *compile* the kernel from source for
: *every machine*.
Which is a good point to have modules. Is it still a good point
to have LSM modules? And to obey the "Sarbanes-Oxley"
Don't take me wrong, the above commentaries are not so serious,
and my point was not about modules, but why "Sarbanes-Oxley"
tell us that new modules are simpler then new kernel.
I like kernel without modules, so I want to understand all motivations
why people need modules (and this thread showed me other (non-classical)
reasons). I know that the modules are necessary in most situation, but
I like to see if some reasons can be solved in other ways, so to
simplify also the life of "build-in" peoples.
ciao
cate
next prev parent reply other threads:[~2007-10-23 8:17 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-22 17:00 LSM conversion to static interface Thomas Fricaccia
2007-10-22 17:12 ` Alan Cox
2007-10-22 17:13 ` Greg KH
2007-10-23 5:14 ` Crispin Cowan
2007-10-23 5:32 ` david
2007-10-23 11:38 ` Simon Arlott
2007-10-23 5:53 ` Giacomo Catenazzi
2007-10-23 7:12 ` Crispin Cowan
2007-10-23 8:17 ` Giacomo A. Catenazzi [this message]
2007-10-24 3:41 ` Greg KH
-- strict thread matches above, loose matches on Subject: below --
2007-10-25 11:33 Jan Engelhardt
2007-10-26 10:40 ` Samir Bellabes
2007-10-22 2:24 Thomas Fricaccia
2007-10-22 3:59 ` Greg KH
2007-10-22 17:47 ` Avi Kivity
2007-10-23 16:05 ` Adrian Bunk
2007-10-23 16:52 ` Geert Uytterhoeven
2007-10-22 10:07 ` Alan Cox
2007-10-22 16:10 ` Crispin Cowan
2007-10-22 16:50 ` Alan Cox
2007-10-22 16:56 ` Greg KH
[not found] <167451.96128.qm@web38607.mail.mud.yahoo.com>
2007-10-18 2:18 ` Linus Torvalds
2007-10-19 20:26 ` Andreas Gruenbacher
2007-10-19 20:40 ` Linus Torvalds
2007-10-20 11:05 ` Jan Engelhardt
2007-10-20 22:57 ` James Morris
2007-10-21 22:59 ` Adrian Bunk
2007-10-23 9:13 ` Jan Engelhardt
2007-10-23 5:44 ` Giacomo Catenazzi
2007-10-23 8:55 ` Jan Engelhardt
2007-10-23 9:14 ` Giacomo A. Catenazzi
2007-10-23 9:18 ` Jan Engelhardt
2007-10-23 15:20 ` Serge E. Hallyn
2007-10-23 15:28 ` Jan Engelhardt
2007-10-23 15:34 ` Serge E. Hallyn
2007-10-25 10:23 ` Valdis.Kletnieks
2007-10-19 21:07 ` James Morris
2007-10-18 1:34 Thomas Fricaccia
2007-10-18 2:03 ` Casey Schaufler
2007-10-18 2:21 ` Linus Torvalds
2007-10-18 3:06 ` Arjan van de Ven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=471DAE1E.1050600@debian.org \
--to=cate@debian.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=crispin@crispincowan.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=thomas_fricacci@yahoo.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox