From: Rusty Russell <rusty@rustcorp.com.au>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>, "Kasatkin\,
Dmitry" <dmitry.kasatkin@intel.com>
Cc: Kasatkin@ozlabs.org, Kees Cook <keescook@chromium.org>,
David Howells <dhowells@redhat.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: Module xattr signatures
Date: Mon, 08 Oct 2012 10:03:58 +1030 [thread overview]
Message-ID: <874nm5rh5l.fsf@rustcorp.com.au> (raw)
In-Reply-To: <1349457006.20387.41.camel@falcor>
Mimi Zohar <zohar@linux.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@rustcorp.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.
prev parent reply other threads:[~2012-10-08 2:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-05 1:47 Module xattr signatures Rusty Russell
2012-10-05 14:42 ` Kasatkin, Dmitry
2012-10-05 17:10 ` Mimi Zohar
2012-10-07 23:33 ` Rusty Russell [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874nm5rh5l.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=Kasatkin@ozlabs.org \
--cc=dhowells@redhat.com \
--cc=dmitry.kasatkin@intel.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=zohar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox