[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <471D8C54.4050907@debian.org>
Date: Tue, 23 Oct 2007 07:53:24 +0200
From: Giacomo Catenazzi <cate@...ian.org>
To: Thomas Fricaccia <thomas_fricacci@...oo.com>
CC: 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>,
Crispin Cowan <crispin@...spincowan.com>
Subject: Re: LSM conversion to static interface
Thomas Fricaccia wrote:
> Some well-respected contributors have taken exception my amplification
> of Crispin Cowan's point about the patch that closes LSM.
>
> Crispin Cowan <crispin@...spincowan.com> wrote:
>> * It prevents enterprise users, and in fact anyone who isn't
>> comfortable compiling their own kernel, from ever trying out any
>> security module that their distro vendor of choice did not ship.
>
> I extended this point by observing that regulatory laws make it difficult
> for enterprise customers to compile their own kernels, mentioning one
> of the more invasive statutes, Sarbanes-Oxley.
>
> In reply, "Alan Cox" <alan@...rguk.ukuu.org.uk> writes:
>> Crispin at least is providing genuine discussion points. Sarbox has
>> nothing to say on "using vendor linux kernels".
>
> And just previously, "Greg KH" <greg@...ah.com> had written:
>> Since when does Sarbanes-Oxley decree that a company must use a
>> "standard kernel"? And just exactly what defines such "standard
>> kernel"? Can you point out where in that bill it requires such a
>> thing?
>
> I was actually talking about the *effects* of regulatory law, rather
> than the wording in the text of the statutes. The misunderstanding
> could be partially my fault, as my exact words were
>
> As Sarbanes-Oxley and other regulatory laws require these
> customers to use "standard kernels" ....
>
> which may not have been as unambiguously clear as I intended.
>
> But as long as we're here, let me elaborate on the point I tried to make.
>
> SOX and other laws require enterprise customers to keep specified
> controls on their internal processing procedures, and keep documentation
> that can be audited to prove compliance. The auditing requirements
> are extensive and detailed, and certainly include the kernel of an
> operating system used to process business and/or financial transactions.
>
> It is within this framework that enterprise customers conclude something
> like (and this is vernacular, not the language within the statutes) "if
> we use any kernel other than that supplied by our distributor, the
> SOX auditing paperwork will be a nightmare." (I've actually heard
> statements similar to this, and so believe that it is an accurate
> portrayal of the perception of the effects of regulatory law. I'm not
> a lawyer.)
>
> As I said at the beginning, I meant to amplify Crispin's observation
> that enterprise customers are reluctant to compile their own kernels
> with the additional observation that the complexities of regulatory
> law create obstacles that are significant contributors to that reluctance.
>
> I'll not belabor the unfortunate non sequitur further. You can find
> plenty of documentation of auditing requirements with by Googling
> combinations of "Sarbanes-Oxley," "operating system integrity", etc.
> This is a big-business topic of wide concern.
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.
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