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]

Message-ID: <20111006200315.GA25681@redhat.com>
Date:	Thu, 6 Oct 2011 16:03:15 -0400
From:	Dave Jones <davej@...hat.com>
To:	Valdis.Kletnieks@...edu
Cc:	Greg KH <greg@...ah.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: RFC: virtualbox tainting.

On Thu, Oct 06, 2011 at 03:53:42PM -0400, Valdis.Kletnieks@...edu wrote:
 > On Thu, 06 Oct 2011 15:50:07 EDT, Dave Jones said:
 > 
 > > I feel a bit dirty overloading TAINT_CRAP (even if the name is apropos).
 > > Should I introduce a TAINT_OUT_OF_TREE perhaps instead ?
 > 
 > That would fix my biggest issue with the patch - it's a slippery slope.  But if
 > we bite the bullet and go straight to the bottom of the slope with an
 > OUT_OF_TREE taint, I'd be happy with that.
 > 
 > Is there a good way to identify at modprobe time if a module is in-tree or
 > out-of-tree?

Not easily from within the kernel. (and doing it in userspace is pointless,
as out of tree modules could just add themselves to the list of 'clean' modules)

We actually used to do something in RHEL a few years ago where we gpg signed the
modules we were building, for pretty much this reason. (also useful for spotting when
for eg, an IHV replaces ext3.ko with their own version in their preloads).

A bit overkill though compared to just having a hardcoded list of offenders in the kernel.

	Dave

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