linux-kernel - Re: RFC: virtualbox tainting.

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:	Thu, 6 Oct 2011 12:58:24 -0700
From:	Greg KH <greg@...ah.com>
To:	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: RFC: virtualbox tainting.

On Thu, Oct 06, 2011 at 03:50:07PM -0400, Dave Jones wrote:
> On Thu, Oct 06, 2011 at 12:44:32PM -0700, Greg Kroah-Hartman wrote:
>  
>  > > diff --git a/kernel/module.c b/kernel/module.c
>  > > index 04379f92..d26c9a3 100644
>  > > --- a/kernel/module.c
>  > > +++ b/kernel/module.c
>  > > @@ -2653,6 +2653,10 @@ static int check_module_license_and_versions(struct module *mod)
>  > >  	if (strcmp(mod->name, "ndiswrapper") == 0)
>  > >  		add_taint(TAINT_PROPRIETARY_MODULE);
>  > >  
>  > > +	/* vbox is garbage. */
>  > > +	if (strcmp(mod->name, "vboxdrv") == 0)
>  > > +		add_taint(TAINT_CRAP);
>  > 
>  > Odds are we should have a list of these types of modules, as I think
>  > there are a few others out there we should mark this way :)
> 
> possibly, though this is by far the leader (for us at least) today.
> 
>  > But anyway, I like this, and I think I'll go add it to the openSUSE
>  > kernels so we can avoid the numerous bug reports we get there as well
>  > for this crappy driver.
>  > 
>  > 	Acked-by: Greg Kroah-Hartman <gregkh@...e.de>
> 
> I feel a bit dirty overloading TAINT_CRAP (even if the name is apropos).
> Should I introduce a TAINT_OUT_OF_TREE perhaps instead ?

We could do that in a "generic" way by setting a "in-tree" flag type
thing for everything that is built from within the kernel build, and
then taint if that flag is not found.

We have that type of logic already in the SUSE enterprise kernels, would
that be something that would make more sense to do here?  That way you
could just ignore any TAINT_OUT_OF_TREE messages which would cover all
of the other modules I was complaining about above?

If so, I could try to make up a patch doing this if you want.

greg k-h
--
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/