linux-kernel - Re: Module xattr signatures

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

Date:	Mon, 08 Oct 2012 10:03:58 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	"Kasatkin\, Dmitry" <dmitry.kasatkin@...el.com>
Cc:	Kasatkin@...abs.org, Kees Cook <keescook@...omium.org>,
	David Howells <dhowells@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Module xattr signatures

Mimi Zohar <zohar@...ux.vnet.ibm.com> writes:
> On Fri, 2012-10-05 at 17:42 +0300, Kasatkin, Dmitry wrote:
>> Hello,
>> 
>> On Fri, Oct 5, 2012 at 4:47 AM, Rusty Russell <rusty@...tcorp.com.au> wrote:
>> >
>> > Hi all,
>> >
>> >         Had a talk with Mimi, and IMA still wants xattr signatures on
>> > modules like they have for other files with EVM.  With Kees' patches now
>> > merged into my modules-wip branch (warning, rebases frequently), this
>> > should be pretty simple.  Dmitry?
>> >
>> 
>> Yes, there is no difference for IMA/EVM what type of file has a
>> signature to verify.
>> It just reads the signature from the xattr. With the module hook it
>> will just do the same
>> for modules as well. It is independent of appended signature verification.
>> The format of signatures is different at the moment.
>
>> >         The question of whether this falls back to appended signatures
>> > if there's no xattr support, or whether we fix cpio depends on whether
>> > someone is prepared to do the latter.  As Mimi points out, AIX, bsd,
>> > solaris all have versions of cpio that support extended attributes, as
>> > does the bsdcpio Debian package, for example.
>> >
>> 
>> As I already said in one of my early mails, I am not sure at all if
>> IMA really needs to verify a signature,
>> if primary mechanism is to use appended signature.
>
> Which is the preferred method is exactly the point. That depends on your
> use case.  For systems with IMA-appraisal already enabled, there would
> not be any reason for the appended signature verification.
>
> Now, with the MODULE_CHECK hook, systems could define an IMA-appraisal
> policy to appraise just kernel modules.
>
> The remaining issue is how to deal with filesystems that don't have
> extended attribute support.  As we've already had this discussion, lets
> summarize the different options:
>
> - don't support them
>
> Not very friendly.
>
> - modify the new syscall to pass the signature and signature length
>
> Kees nixed this idea.
>
> - fall back to appended signature verification
>
> In addition to David Howell's version of the appended signature
> verification, I would like having the existing EVM/IMA-appraisal
> signature format, based on Dmitry's proposed kernel module patches, as
> another option.

Or:

 - Reduce the set of filesystems which don't support xattrs to the empty
   set ;)

Which I prefer...
Cheers,
Rusty.
--
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/