Hi-
I'm continuing to look at NFS support for the Linux Integrity
Measurement Architecture.
When computing an HMAC hash of file attributes, sometimes the
FS UUID is included. For a client to verify that hash, the
server will have to expose that UUID somehow.
Is there currently an NFSv4 attribute that carries the FS UUID?
--
Chuck Lever
On Tue, May 22, 2018 at 08:53:34AM -0700, Chuck Lever wrote:
> Hi-
>
> I'm continuing to look at NFS support for the Linux Integrity
> Measurement Architecture.
>
> When computing an HMAC hash of file attributes, sometimes the
> FS UUID is included. For a client to verify that hash, the
> server will have to expose that UUID somehow.
>
> Is there currently an NFSv4 attribute that carries the FS UUID?
I think the fsid is as close as you get.
Do you need to calculate hashes in exactly the way the server does? If
you're assuming a "dumb server" that just stores signatures without
interpreting them, then maybe not?
--b.
> On May 22, 2018, at 9:07 AM, Bruce Fields <[email protected]> wrote:
>
> On Tue, May 22, 2018 at 08:53:34AM -0700, Chuck Lever wrote:
>> Hi-
>>
>> I'm continuing to look at NFS support for the Linux Integrity
>> Measurement Architecture.
>>
>> When computing an HMAC hash of file attributes, sometimes the
>> FS UUID is included. For a client to verify that hash, the
>> server will have to expose that UUID somehow.
>>
>> Is there currently an NFSv4 attribute that carries the FS UUID?
>
> I think the fsid is as close as you get.
>
> Do you need to calculate hashes in exactly the way the server does? If
> you're assuming a "dumb server" that just stores signatures without
> interpreting them, then maybe not?
The hashes have to be computed the same way everywhere, of course,
whether it's on a client or on the server.
Assuming that NFS were not in the picture, then the EVM hash would
use the raw FS UUID. This is the hash that would be exposed to NFS
clients if that filesystem were suddenly to be exported. So the
NFS clients would need to have the same raw FS UUID in order to
verify the hash. (And I'm actually not sure what benefit there is
to including the FS UUID).
I see two alternatives:
-- Provide a new read-only filesystem attribute that exposes the
FS UUID
-- The FS UUID is optional. We could make it illegal to use the
FS UUID in EVM hashes that will be exposed via NFS
The bigger picture:
- The input set for the hash contains optional items that will have
to be given to remote EVM hash consumers. I think a new attribute
that lists the set of hashed attributes will be necessary.
- The input set can contain security.* xattrs, like security.SMACK64.
These are currently not exposed to NFS clients, but not all files
will have them. Not quite sure how to make that work generally.
--
Chuck Lever
On Tue, May 22, 2018 at 09:17:53AM -0700, Chuck Lever wrote:
>
>
> > On May 22, 2018, at 9:07 AM, Bruce Fields <[email protected]> wrote:
> >
> > On Tue, May 22, 2018 at 08:53:34AM -0700, Chuck Lever wrote:
> >> Hi-
> >>
> >> I'm continuing to look at NFS support for the Linux Integrity
> >> Measurement Architecture.
> >>
> >> When computing an HMAC hash of file attributes, sometimes the
> >> FS UUID is included. For a client to verify that hash, the
> >> server will have to expose that UUID somehow.
> >>
> >> Is there currently an NFSv4 attribute that carries the FS UUID?
> >
> > I think the fsid is as close as you get.
> >
> > Do you need to calculate hashes in exactly the way the server does? If
> > you're assuming a "dumb server" that just stores signatures without
> > interpreting them, then maybe not?
>
> The hashes have to be computed the same way everywhere, of course,
> whether it's on a client or on the server.
>
> Assuming that NFS were not in the picture, then the EVM hash would
> use the raw FS UUID. This is the hash that would be exposed to NFS
> clients if that filesystem were suddenly to be exported. So the
> NFS clients would need to have the same raw FS UUID in order to
> verify the hash. (And I'm actually not sure what benefit there is
> to including the FS UUID).
I guess it prevents you from reusing a signature on an otherwise
identical file on another filesystem?
We'd need to understand what exactly the threats are that IMA is meant
to prevent.
--b.
> I see two alternatives:
>
> -- Provide a new read-only filesystem attribute that exposes the
> FS UUID
>
> -- The FS UUID is optional. We could make it illegal to use the
> FS UUID in EVM hashes that will be exposed via NFS
>
> The bigger picture:
>
> - The input set for the hash contains optional items that will have
> to be given to remote EVM hash consumers. I think a new attribute
> that lists the set of hashed attributes will be necessary.
>
> - The input set can contain security.* xattrs, like security.SMACK64.
> These are currently not exposed to NFS clients, but not all files
> will have them. Not quite sure how to make that work generally.