[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080301211108.GF25835@cs181133002.pp.htv.fi>
Date: Sat, 1 Mar 2008 23:11:08 +0200
From: Adrian Bunk <bunk@...nel.org>
To: Casey Schaufler <casey@...aufler-ca.com>
Cc: "Ahmed S. Darwish" <darwish.07@...il.com>,
Chris Wright <chrisw@...s-sol.org>,
Stephen Smalley <sds@...ho.nsa.gov>,
James Morris <jmorris@...ei.org>,
Eric Paris <eparis@...isplace.org>,
Alexey Dobriyan <adobriyan@...ru>,
LKML <linux-kernel@...r.kernel.org>,
LSM-ML <linux-security-module@...r.kernel.org>
Subject: Re: [RFC PATCH -mm] LSM: Add lsm= boot parameter
On Sat, Mar 01, 2008 at 12:28:43PM -0800, Casey Schaufler wrote:
>
> --- "Ahmed S. Darwish" <darwish.07@...il.com> wrote:
>
> > Hi everybody,
> >
> > This is a first try of adding lsm= boot parameter.
> >
> > Current situation is:
> > 1- Ignore wrong input, with a small warning to users.
> > 2- If user didn't specify a specific module, none will be loaded
>
> I'm not fond of this behavior for the case where only one LSM
> has been built in. Fedora, for example, ought to boot SELinux
> without specifing lsm=SELinux, and all the rest should boot
> whatever they are built with. In the case where a kernel is
> built with conflicting LSMs (today SELinux and Smack) I see
> this as a useful way to decide which to use until you get
> your kernel rebuilt sanely, so it appears to be worth having.
>...
Remarks:
Your comment would be covered if the default for this boot parameter (if
not explicitely set through the boot loader would not be "disabled" but
set through kconfig (based on the selected LSMs).
We should really get this resolved for 2.6.25.
security= suggestion is IMHO more intuitive than lsm=
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
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