lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 23 Oct 2007 10:17:34 +0200
From:	"Giacomo A. Catenazzi" <cate@...ian.org>
To:	Crispin Cowan <crispin@...spincowan.com>
CC:	Thomas Fricaccia <thomas_fricacci@...oo.com>,
	linux-kernel@...r.kernel.org, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg KH <greg@...ah.com>,
	LSM ML <linux-security-module@...r.kernel.org>
Subject: Re: LSM conversion to static interface

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ