linux-kernel - Re: LSM conversion to static interface

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-next>] [day] [month] [year] [list]

Date:	Sun, 21 Oct 2007 19:24:42 -0700
From:	"Thomas Fricaccia" <thomas_fricacci@...oo.com>
To:	"Crispin Cowan" <crispin@...spincowan.com>
Cc:	linux-kernel@...r.kernel.org,
	"LSM ML" <linux-security-module@...r.kernel.org>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>
Subject: Re: LSM conversion to static interface

Yes, I think Crispin has succinctly summed it up:  irrevocably closing
the LSM prevents commercial customers from using security modules other
than that provided by their Linux distributor.  As Sarbanes-Oxley and
other regulatory laws require these customers to use "standard
kernels", the result is a rather dreary form of vendor lock-in, where the
security framework is coupled to the distribution.

Though it would require a somewhat undesirable complexity of CONFIG_
flags, it should be possible to construct flexibility enough for everyone
to get what he wants.  For example, it should be possible to configure
kernels with a single security framework hard-linked, AND it should
also be possible to configure kernels such that the default security
framework could be completely replaced at boot time by another, be it
out-of-tree module, or other.

I agree entirely that preserving this form of freedom for the end user
makes Linux a much stronger technology than not.  For one thing, the
consequences of closing LSM are fairly certain to irritate enterprise
commercial customers, which is probably a sign that the technology has
taken a wrong turn.

Tommy F.

Crispin Cowan <crispin@...spincowan.com> wrote:

> So the net impact of this patch is:
> 
>    * It takes a deployment practice (static compiled-in security) that
>      is arguably good in many circumstances and makes it mandatory at
>      all times.
>    * It takes a development practice that is very convenient and
>      slightly risky, and forces you into the pessimal inconvenient
>      development practice at all times.
>    * 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.
>
> This strikes me as a rather anti-choice position to take. It says that
> because candy is bad for you, you only ever get to eat vegetables. I
> don't understand why Linux would want to do this to its users.
>
> It doesn't hurt me or AppArmor. Since AppArmor is now shipping with
> SUSE, Ubuntu, and Mandriva, what this does is make it harder for newer
> modules like TOMOYO, Multi-Admin, etc, to get exposure to enterprise
> users. So I don't think I am being self-serving in arguing against this
> patch. I just think it is bad for Linux.
>
> Crispin
>
> -- 
> Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
>         Itanium. Vista. GPLv3. Complexity at work

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