linux-ima-user — Q&A for users of IMA

Re: [Linux-ima-user] Calculate Template Hash using ruby

[Jens L. <in...@je...>]

Hello Andreas,

Thanks for your help, this solved the problem I had!

Happy New Year to you, the Strongswan team and everbody on the IMA 
mailinglist.

Regards,

Jens

Here is the working ruby script if anybody is interested in it:

#!/usr/bin/env ruby
require 'digest/sha1'
fhash="037d38f6148770b9565ba3f6b532c7794e37e025"
fhashhex = [fhash].pack('H*')
fname0="/sbin/init\x00"
thash="79fa39c792abfd03ba7569e1900d155f993b01e8"
algname="sha1:\00"
hash = Digest::SHA1.hexdigest([fhashhex.length+algname.length].pack('i') 
+ algname  + fhashhex +  [fname0.length].pack('i')  + fname0)
print "\nTest: #{thash==hash} ima #{thash} hash: #{hash} \n"


Am 31.12.2014 um 06:59 schrieb Andreas Steffen:
> Hello Jens,
>
> have a look at our working strongSwan IMA-NG source code:
>
> https://wiki.strongswan.org/projects/strongswan/repository/revisions/master/entry/src/libimcv/pts/components/ita/ita_comp_ima.c#L230 
>
>
> The evident wrong steps that you are making are the following:
>
> - Hash the algorithm name without the ":" separator but
>   include the terminating nul character in your hash (see line 236
>   of the strongSwan source code).
>
> - The file or event name must also be hashed with the terminating
>   nul character included (see line 237 of the strongSwan source code)
>
> Also have a look at the strongSwan parse_validation_uri() function
>
> https://wiki.strongswan.org/projects/strongswan/repository/revisions/master/entry/src/libimcv/pts/components/ita/ita_comp_ima.c#L465 
>
>
> which parses the string <hash algorithm>:<event name> into its two
> components.
>
> I don't know how Ruby computes the hash of the fhash.length and
> fname.length values. Currently the Linux kernel IMA-NG code treats
> the uint32_t lengths as a 4-byte value in host order (see lines 240
> and 244 of the strongSwan source code).
>
> A couple of months ago I proposed on this list to make these two
> length hashes platform-independent by hashing the uint32_t values
> in network order. This would help tremendously if an TNC attestion
> IMC is running on a little-endian platform but the TNC attestion IMV
> deriving the IMA-NG hash from a stored reference file hash is running
> on a big-endian host or vice versa. Unfortunately my patch was not
> accepted into the Linux kernel.
>
> I hope this helps you to arrive at the correct hash values.
>
> Best regards and a Happy New Year!
>
> Andreas
>
> On 31.12.2014 00:48, Jens Lucius wrote:
>> Hello,
>>
>> I am trying to calculate the template hash for ima-ng using ruby but
>> after trying lots of combinations it seems I am not getting the correct
>> hash value.
>>
>> According to documentation the template hash is:
>> template-hash: sha1 hash(filedata-hash length, filedata-hash, pathname
>> length, pathname)
>>
>> So I am trying to re-calculate the following IMA measurement:
>> 10 79fa39c792abfd03ba7569e1900d155f993b01e8 ima-ng
>> sha1:037d38f6148770b9565ba3f6b532c7794e37e025 /sbin/init
>>
>> I would be happy if someone could have a look what I am doing wrong 
>> here.
>>
>> Thanks,
>>
>> Jens Lucius
>>
>>
>> #!/usr/bin/env ruby
>> require 'digest/sha1'
>> fhash="sha1:037d38f6148770b9565ba3f6b532c7794e37e025"
>> fhash2="037d38f6148770b9565ba3f6b532c7794e37e025"
>> thash="79fa39c792abfd03ba7569e1900d155f993b01e8"
>> fname="/sbin/init"
>> hash=Digest::SHA1.hexdigest([fhash.length].pack('i') + "sha1:" +
>> [fhash2].pack('H*') + [fname.length].pack('i') + fname)
>> print "\nTest: #{thash==hash} ima #{thash} hash: #{hash}"
>
> ======================================================================
> Andreas Steffen and...@st...
> strongSwan - the Open Source VPN Solution! www.strongswan.org
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===========================================================[ITA-HSR]==
>

Re: [Linux-ima-user] Calculate Template Hash using ruby

[Andreas S. <and...@st...>]

Oops,
I've just taken a closer look at the parse_validation_uri() code
I wrote in May and saw that the colon character ':' must be
included (e.g. "sha1:") but the following terminating nul character,
too.

Regards, Andreas

On 31.12.2014 06:59, Andreas Steffen wrote:
> - Hash the algorithm name without the ":" separator but
>    include the terminating nul character in your hash (see line 236
>    of the strongSwan source code).
>
> Also have a look at the strongSwan parse_validation_uri() function
>
> https://wiki.strongswan.org/projects/strongswan/repository/revisions/master/entry/src/libimcv/pts/components/ita/ita_comp_ima.c#L465
>
> which parses the string <hash algorithm>:<event name> into its two
> components.
>

======================================================================
Andreas Steffen                         and...@st...
strongSwan - the Open Source VPN Solution!          www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==

Re: [Linux-ima-user] Calculate Template Hash using ruby

[Andreas S. <and...@st...>]

Hello Jens,

have a look at our working strongSwan IMA-NG source code:

https://wiki.strongswan.org/projects/strongswan/repository/revisions/master/entry/src/libimcv/pts/components/ita/ita_comp_ima.c#L230

The evident wrong steps that you are making are the following:

- Hash the algorithm name without the ":" separator but
   include the terminating nul character in your hash (see line 236
   of the strongSwan source code).

- The file or event name must also be hashed with the terminating
   nul character included (see line 237 of the strongSwan source code)

Also have a look at the strongSwan parse_validation_uri() function

https://wiki.strongswan.org/projects/strongswan/repository/revisions/master/entry/src/libimcv/pts/components/ita/ita_comp_ima.c#L465

which parses the string <hash algorithm>:<event name> into its two
components.

I don't know how Ruby computes the hash of the fhash.length and
fname.length values. Currently the Linux kernel IMA-NG code treats
the uint32_t lengths as a 4-byte value in host order (see lines 240
and 244 of the strongSwan source code).

A couple of months ago I proposed on this list to make these two
length hashes platform-independent by hashing the uint32_t values
in network order. This would help tremendously if an TNC attestion
IMC is running on a little-endian platform but the TNC attestion IMV
deriving the IMA-NG hash from a stored reference file hash is running
on a big-endian host or vice versa. Unfortunately my patch was not
accepted into the Linux kernel.

I hope this helps you to arrive at the correct hash values.

Best regards and a Happy New Year!

Andreas

On 31.12.2014 00:48, Jens Lucius wrote:
> Hello,
>
> I am trying to calculate the template hash for ima-ng using ruby but
> after trying lots of combinations it seems I am not getting the correct
> hash value.
>
> According to documentation the template hash is:
> template-hash: sha1 hash(filedata-hash length, filedata-hash, pathname
> length, pathname)
>
> So I am trying to re-calculate the following IMA measurement:
> 10 79fa39c792abfd03ba7569e1900d155f993b01e8 ima-ng
> sha1:037d38f6148770b9565ba3f6b532c7794e37e025 /sbin/init
>
> I would be happy if someone could have a look what I am doing wrong here.
>
> Thanks,
>
> Jens Lucius
>
>
> #!/usr/bin/env ruby
> require 'digest/sha1'
> fhash="sha1:037d38f6148770b9565ba3f6b532c7794e37e025"
> fhash2="037d38f6148770b9565ba3f6b532c7794e37e025"
> thash="79fa39c792abfd03ba7569e1900d155f993b01e8"
> fname="/sbin/init"
> hash=Digest::SHA1.hexdigest([fhash.length].pack('i') + "sha1:" +
> [fhash2].pack('H*') + [fname.length].pack('i') + fname)
> print "\nTest: #{thash==hash} ima #{thash} hash: #{hash}"

======================================================================
Andreas Steffen                         and...@st...
strongSwan - the Open Source VPN Solution!          www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==

Re: [Linux-ima-user] question about IMA-Appraisal

[Mimi Z. <zo...@li...>]

On Wed, 2014-12-31 at 09:35 +0800, jiangdahui wrote:
<snip>
> ok, I'll describe my questions more clearly.
> 1.Is it use some manual operations exclude that boot with
> "ima_appraise = appraise integrity measurements"?

If a kernel is configured and built with IMA_APPRAISE enabled, nothing
is appraised unless an appraisal policy is loaded. Specifying
"ima_appraise_tcb" on the boot command line enables the builtin
appraisal policy.  This policy can be replaced by redirecting the 'cat'
policy output to
/sys/kernel/security/ima/policy/.

> 2.how to test the effect of it, observe the "security.evm" attr?where?

There are two ways that 'security.evm' changes.  The first method, using
evmctl, replaces the existing HMAC value with a file signature.  The
second method occurs as a result of changing any of the protected
security extended attributes (eg. security.selinux, security.SMACK64,
security.ima, security.capability, ...).  

> 3.why the kernel can't boot when using "ima_appraise = enforce".

As explained below, the file system needs to be labeled with
security.evm xattrs appropriately.  Possible reasons for failure to boot
properly are: missing file signature/hash, invalid file signature/hash,
or unknown key.

Mimi

> At 2014-12-30 22:10:37, "Mimi Zohar" <zo...@li...> wrote:
> >On Tue, 2014-12-30 at 17:50 +0800, jiangdahui wrote: 
> >> hi all:
> >
> >> how to verify IMA-Appraisal's effect?change a executable file?but I
> find
> >> it can still run normally? or observe the "security.evm" attr? how?
> >
> >IMA-appraisal enforces local file integrity based on policy (eg.
> >ima_appraise_tcb).  The "good" integrity values are stored as
> extended
> >attributes (xattr), which are compared with the runtime values.
> Before
> >enabling IMA-appraisal, the file system must be labeled.
> >
> >Refer to the linux-ima wiki for more details.
> >
> >Mimi
> >

[Linux-ima-user] Calculate Template Hash using ruby

[Jens L. <in...@je...>]

Hello,

I am trying to calculate the template hash for ima-ng using ruby but 
after trying lots of combinations it seems I am not getting the correct 
hash value.

According to documentation the template hash is:
template-hash: sha1 hash(filedata-hash length, filedata-hash, pathname 
length, pathname)

So I am trying to re-calculate the following IMA measurement:
10 79fa39c792abfd03ba7569e1900d155f993b01e8 ima-ng 
sha1:037d38f6148770b9565ba3f6b532c7794e37e025 /sbin/init

I would be happy if someone could have a look what I am doing wrong here.

Thanks,

Jens Lucius


#!/usr/bin/env ruby
require 'digest/sha1'
fhash="sha1:037d38f6148770b9565ba3f6b532c7794e37e025"
fhash2="037d38f6148770b9565ba3f6b532c7794e37e025"
thash="79fa39c792abfd03ba7569e1900d155f993b01e8"
fname="/sbin/init"
hash=Digest::SHA1.hexdigest([fhash.length].pack('i') + "sha1:" + 
[fhash2].pack('H*') + [fname.length].pack('i') + fname)
print "\nTest: #{thash==hash} ima #{thash} hash: #{hash}"

Re: [Linux-ima-user] question about IMA-Appraisal

[Mimi Z. <zo...@li...>]

On Tue, 2014-12-30 at 17:50 +0800, jiangdahui wrote: 
> hi all:

> how to verify IMA-Appraisal's effect?change a executable file?but I find
> it can still run normally? or observe the "security.evm" attr? how?

IMA-appraisal enforces local file integrity based on policy (eg.
ima_appraise_tcb).  The "good" integrity values are stored as extended
attributes (xattr), which are compared with the runtime values.  Before
enabling IMA-appraisal, the file system must be labeled.

Refer to the linux-ima wiki for more details.

Mimi

[Linux-ima-user] question about IMA-Appraisal(2)

[jiangdahui <jd...@ye...>]

and why the kernel can't boot with the 'ima_appraise=enforce' or leave default?

[Linux-ima-user] question about IMA-Appraisal

[jiangdahui <jd...@ye...>]

hi all:
      how to verify IMA-Appraisal's effect?change a executable file?but I find it can still run normally? or observe the "security.evm" attr? how?




best regards!
   

Re: [Linux-ima-user] Initramfs and IMA Appraisal

[Rob L. <ro...@la...>]

On 12/29/2014 09:20 PM, Mimi Zohar wrote:
> On Mon, 2014-12-29 at 19:55 -0600, Rob Landley wrote: 
>>> Thanks Rob for the explanation.  The problem is that ramfs does not
>>> support extended attributes, while tmpfs does.
>>
>> If you're _using_ initramfs/initmpfs, there's no reason to specify a root=.
> 
> The menu entry looks like:
> linux   /vmlinuz-3.17.0+ root=UUID=94595ff7-0fd4-4ea3-99f2-f7ddf8fbc91f
> ro  ...
> initrd  /initramfs-3.17.0+.img
> 
> Because "root=" is specified, rootfs is not using tmpfs.

Yes. Pilot error.

If you want tmpfs to switch to UUID $THINGY you can do ROOT= and have it
use that. You're asking for something to be interpreted by the kernel
sometimes and passed on to userspace other times and have no side
effects even though it's interpeted by the kernel.

>>> The boot loader could
>>> "measure" (trusted boot) the initramfs, but as the initramfs is
>>> generated on the target system, the initramfs is not signed, preventing
>>> it from being appraised (secure Boot). To close the initramfs integrity
>>> appraisal gap requires verifying the individual initramfs file
>>> signatures, which are stored as extended attributes.
>>
>> Faced with the phrases "trusted boot" and "integrity appraisal", I plead
>> the third.
> 
> Fine.  Bottom line, rootfs needs to support extended attributes.

I added a patch to make it work as tmpfs a year ago. You now know what
trivial configuration mistake you make that's preventing it from
working. If you'd like me to submit a documentation update patch to make
it easier to avoid in future, I can do that.

>> (In the wake of the Snowden infodump,
> 
> All the more reason to allow only those files that are properly signed
> to be read/executed.

Using the infrastructure the NSA provided, which is intentionally so
complicated that "you are not expected to understand this".

Good luck with that.

> Mimi

Rob

Re: [Linux-ima-user] Initramfs and IMA Appraisal

[Mimi Z. <zo...@li...>]

On Mon, 2014-12-29 at 19:55 -0600, Rob Landley wrote: 
> 
> On 12/29/2014 03:46 PM, Mimi Zohar wrote:
> > On Mon, 2014-12-29 at 14:34 -0600, Rob Landley wrote: 
> >> On 12/29/2014 07:45 AM, Mimi Zohar wrote:
> >>> On Thu, 2014-11-27 at 10:15 +0100, Christophe Fillot wrote:
> >>>>>
> >>>>> Are you using an initrd not an initramfs?  According to
> >>>>> Documentation/filesystems/ramfs-rootfs-initramfs.txt, "If
> >>>> CONFIG_TMPFS
> >>>>> is enabled, rootfs will use tmpfs instead of ramfs by default".
> >>>>>
> >>>> Yes, that what I thought too, but it seems that it is not really the 
> >>>> case because of this test:
> >>>>
> >>>>      if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
> >>>>          (!root_fs_names || strstr(root_fs_names, "tmpfs"))) {
> >>>>          err = shmem_init();
> >>>>          is_tmpfs = true;
> >>>>      } else {
> >>>>          err = init_ramfs_fs();
> >>>>      }
> >>>
> >>> [CC'ing Rob Landley, lsm, lkml]
> >>>
> >>> Thanks!  "saved_root_name" is set to the boot command line "root="
> >>> option, which in my case is the UUID.  I'm not sure why real root should
> >>> impact the initramfs tmpfs/ramfs decision.
> >>>
> >>> Unless there is a good explanation, did you want to post a patch to
> >>> remove the test?
> >>
> >> I added support last year, here's the start of the patch series:
> >>
> >>   https://lkml.org/lkml/2013/6/29/101
> >>
> >> The logic is that if you specify a fallback root via root=, then you're
> >> not staying on rootfs (that's what root= _means_, "here is the root
> >> filesystem the kernel is to mount over rootfs"), and thus the extra
> >> infrastructure for tmpfs instead of ramfs is unnecessary.
> > 
> > Thanks Rob for the explanation.  The problem is that ramfs does not
> > support extended attributes, while tmpfs does.
> 
> If you're _using_ initramfs/initmpfs, there's no reason to specify a root=.

The menu entry looks like:
linux   /vmlinuz-3.17.0+ root=UUID=94595ff7-0fd4-4ea3-99f2-f7ddf8fbc91f
ro  ...
initrd  /initramfs-3.17.0+.img

Because "root=" is specified, rootfs is not using tmpfs.

> > The boot loader could
> > "measure" (trusted boot) the initramfs, but as the initramfs is
> > generated on the target system, the initramfs is not signed, preventing
> > it from being appraised (secure Boot). To close the initramfs integrity
> > appraisal gap requires verifying the individual initramfs file
> > signatures, which are stored as extended attributes.
> 
> Faced with the phrases "trusted boot" and "integrity appraisal", I plead
> the third.

Fine.  Bottom line, rootfs needs to support extended attributes.

> (In the wake of the Snowden infodump,

All the more reason to allow only those files that are properly signed
to be read/executed.

Mimi

Re: [Linux-ima-user] Initramfs and IMA Appraisal

[Mimi Z. <zo...@li...>]

On Mon, 2014-12-29 at 18:25 -0800, David Lang wrote: 
> On Mon, 29 Dec 2014, Mimi Zohar wrote:
> 
> > Thanks Rob for the explanation.  The problem is that ramfs does not
> > support extended attributes, while tmpfs does.  The boot loader could
> > "measure" (trusted boot) the initramfs, but as the initramfs is
> > generated on the target system, the initramfs is not signed, preventing
> > it from being appraised (secure Boot). To close the initramfs integrity
> > appraisal gap requires verifying the individual initramfs file
> > signatures, which are stored as extended attributes.
> 
> what's the point of checking the files on the filesystem against signatures 
> stored on the same filesystem? If someone could alter the file contents they can 
> alter the signatures as well.

It's all about limiting which public keys can be used to verify the file
signatures.  As of 3.17, only keys signed by a "trusted" key on the
system keyring may be added to the IMA keyring.

Mimi 

Re: [Linux-ima-user] Initramfs and IMA Appraisal

[David L. <da...@la...>]

On Mon, 29 Dec 2014, Mimi Zohar wrote:

> Thanks Rob for the explanation.  The problem is that ramfs does not
> support extended attributes, while tmpfs does.  The boot loader could
> "measure" (trusted boot) the initramfs, but as the initramfs is
> generated on the target system, the initramfs is not signed, preventing
> it from being appraised (secure Boot). To close the initramfs integrity
> appraisal gap requires verifying the individual initramfs file
> signatures, which are stored as extended attributes.

what's the point of checking the files on the filesystem against signatures 
stored on the same filesystem? If someone could alter the file contents they can 
alter the signatures as well.

David Lang

Re: [Linux-ima-user] Initramfs and IMA Appraisal

[Rob L. <ro...@la...>]

On 12/29/2014 03:46 PM, Mimi Zohar wrote:
> On Mon, 2014-12-29 at 14:34 -0600, Rob Landley wrote: 
>> On 12/29/2014 07:45 AM, Mimi Zohar wrote:
>>> On Thu, 2014-11-27 at 10:15 +0100, Christophe Fillot wrote:
>>>>>
>>>>> Are you using an initrd not an initramfs?  According to
>>>>> Documentation/filesystems/ramfs-rootfs-initramfs.txt, "If
>>>> CONFIG_TMPFS
>>>>> is enabled, rootfs will use tmpfs instead of ramfs by default".
>>>>>
>>>> Yes, that what I thought too, but it seems that it is not really the 
>>>> case because of this test:
>>>>
>>>>      if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
>>>>          (!root_fs_names || strstr(root_fs_names, "tmpfs"))) {
>>>>          err = shmem_init();
>>>>          is_tmpfs = true;
>>>>      } else {
>>>>          err = init_ramfs_fs();
>>>>      }
>>>
>>> [CC'ing Rob Landley, lsm, lkml]
>>>
>>> Thanks!  "saved_root_name" is set to the boot command line "root="
>>> option, which in my case is the UUID.  I'm not sure why real root should
>>> impact the initramfs tmpfs/ramfs decision.
>>>
>>> Unless there is a good explanation, did you want to post a patch to
>>> remove the test?
>>
>> I added support last year, here's the start of the patch series:
>>
>>   https://lkml.org/lkml/2013/6/29/101
>>
>> The logic is that if you specify a fallback root via root=, then you're
>> not staying on rootfs (that's what root= _means_, "here is the root
>> filesystem the kernel is to mount over rootfs"), and thus the extra
>> infrastructure for tmpfs instead of ramfs is unnecessary.
> 
> Thanks Rob for the explanation.  The problem is that ramfs does not
> support extended attributes, while tmpfs does.

If you're _using_ initramfs/initmpfs, there's no reason to specify a root=.

> The boot loader could
> "measure" (trusted boot) the initramfs, but as the initramfs is
> generated on the target system, the initramfs is not signed, preventing
> it from being appraised (secure Boot). To close the initramfs integrity
> appraisal gap requires verifying the individual initramfs file
> signatures, which are stored as extended attributes.

Faced with the phrases "trusted boot" and "integrity appraisal", I plead
the third.

(In the wake of the Snowden infodump, people no longer want to use the
elliptic curve cryptography the NSA designed, but they still happily
base their system configuration on SELinux with a stack of thousands of
rules you just have to take on faith. Possibly they're unaware the NSA
designed and still maintains SELinux? Dunno...)

>> Possibly the documentation needs to elaborate, but I expect what we
>> really need is a CONFIG_VERBOSE_ROOT_SETUP that sticks in a bunch of
>> printfs so the /dev/console output explains what it's doing. ("could not
>> exec /init out of initramfs (errno %d, file %s), falling back to
>> root=\nAdd blather=1 to kernel cmdline to see cpio
>> filenames/permissions.", and so on. Where "actual exec" shows where your
>> dynamic linker is when that's what wasn't there.)
> 
> To add to the confusion
> Documentation/filesystems/ramfs-rootfs-initramfs.txt says, "If
> CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by
> default."  This statement should be modified to reflect the actual code.

Actually I modified the code to reflect the documentation last year. (I
wrote the docs in 2005, the initmpfs code in 2013.)

The rootfs code _does_ use tmpfs by default. Specifying root= disables
it, because it indicates you aren't using ramfs but are requesting the
kernel overmount it with another filesystem before launching PID 1.

That's what root= _means_.

I can add a paragraph describing what root= means and that it's
inappropriate to use it with ramfs in general? (And that root=/dev/ram0
is a nonsensical option despite what some bits of the internet seem to
think.)

> Mimi

Rob

Re: [Linux-ima-user] Initramfs and IMA Appraisal

[Mimi Z. <zo...@li...>]

On Mon, 2014-12-29 at 14:34 -0600, Rob Landley wrote: 
> On 12/29/2014 07:45 AM, Mimi Zohar wrote:
> > On Thu, 2014-11-27 at 10:15 +0100, Christophe Fillot wrote:
> >>>
> >>> Are you using an initrd not an initramfs?  According to
> >>> Documentation/filesystems/ramfs-rootfs-initramfs.txt, "If
> >> CONFIG_TMPFS
> >>> is enabled, rootfs will use tmpfs instead of ramfs by default".
> >>>
> >> Yes, that what I thought too, but it seems that it is not really the 
> >> case because of this test:
> >>
> >>      if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
> >>          (!root_fs_names || strstr(root_fs_names, "tmpfs"))) {
> >>          err = shmem_init();
> >>          is_tmpfs = true;
> >>      } else {
> >>          err = init_ramfs_fs();
> >>      }
> > 
> > [CC'ing Rob Landley, lsm, lkml]
> > 
> > Thanks!  "saved_root_name" is set to the boot command line "root="
> > option, which in my case is the UUID.  I'm not sure why real root should
> > impact the initramfs tmpfs/ramfs decision.
> > 
> > Unless there is a good explanation, did you want to post a patch to
> > remove the test?
> 
> I added support last year, here's the start of the patch series:
> 
>   https://lkml.org/lkml/2013/6/29/101
> 
> The logic is that if you specify a fallback root via root=, then you're
> not staying on rootfs (that's what root= _means_, "here is the root
> filesystem the kernel is to mount over rootfs"), and thus the extra
> infrastructure for tmpfs instead of ramfs is unnecessary.

Thanks Rob for the explanation.  The problem is that ramfs does not
support extended attributes, while tmpfs does.  The boot loader could
"measure" (trusted boot) the initramfs, but as the initramfs is
generated on the target system, the initramfs is not signed, preventing
it from being appraised (secure Boot). To close the initramfs integrity
appraisal gap requires verifying the individual initramfs file
signatures, which are stored as extended attributes.

> I keep encountering people who set root=/dev/ram0 because they think
> that means initrd (it doesn't), and then they feed in a cpio archive
> (that's a third state even before you get to the ramfs/tmpfs
> distinction), and they always want to change the code to make what they
> asked it to do not be crazy...
> 
> Possibly the documentation needs to elaborate, but I expect what we
> really need is a CONFIG_VERBOSE_ROOT_SETUP that sticks in a bunch of
> printfs so the /dev/console output explains what it's doing. ("could not
> exec /init out of initramfs (errno %d, file %s), falling back to
> root=\nAdd blather=1 to kernel cmdline to see cpio
> filenames/permissions.", and so on. Where "actual exec" shows where your
> dynamic linker is when that's what wasn't there.)

To add to the confusion
Documentation/filesystems/ramfs-rootfs-initramfs.txt says, "If
CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by
default."  This statement should be modified to reflect the actual code.

Mimi

Re: [Linux-ima-user] Initramfs and IMA Appraisal

[Rob L. <ro...@la...>]

On 12/29/2014 07:45 AM, Mimi Zohar wrote:
> On Thu, 2014-11-27 at 10:15 +0100, Christophe Fillot wrote:
>>>
>>> Are you using an initrd not an initramfs?  According to
>>> Documentation/filesystems/ramfs-rootfs-initramfs.txt, "If
>> CONFIG_TMPFS
>>> is enabled, rootfs will use tmpfs instead of ramfs by default".
>>>
>> Yes, that what I thought too, but it seems that it is not really the 
>> case because of this test:
>>
>>      if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
>>          (!root_fs_names || strstr(root_fs_names, "tmpfs"))) {
>>          err = shmem_init();
>>          is_tmpfs = true;
>>      } else {
>>          err = init_ramfs_fs();
>>      }
> 
> [CC'ing Rob Landley, lsm, lkml]
> 
> Thanks!  "saved_root_name" is set to the boot command line "root="
> option, which in my case is the UUID.  I'm not sure why real root should
> impact the initramfs tmpfs/ramfs decision.
> 
> Unless there is a good explanation, did you want to post a patch to
> remove the test?

I added support last year, here's the start of the patch series:

  https://lkml.org/lkml/2013/6/29/101

The logic is that if you specify a fallback root via root=, then you're
not staying on rootfs (that's what root= _means_, "here is the root
filesystem the kernel is to mount over rootfs"), and thus the extra
infrastructure for tmpfs instead of ramfs is unnecessary.

I keep encountering people who set root=/dev/ram0 because they think
that means initrd (it doesn't), and then they feed in a cpio archive
(that's a third state even before you get to the ramfs/tmpfs
distinction), and they always want to change the code to make what they
asked it to do not be crazy...

Possibly the documentation needs to elaborate, but I expect what we
really need is a CONFIG_VERBOSE_ROOT_SETUP that sticks in a bunch of
printfs so the /dev/console output explains what it's doing. ("could not
exec /init out of initramfs (errno %d, file %s), falling back to
root=\nAdd blather=1 to kernel cmdline to see cpio
filenames/permissions.", and so on. Where "actual exec" shows where your
dynamic linker is when that's what wasn't there.)

Rob

Re: [Linux-ima-user] Initramfs and IMA Appraisal

[Mimi Z. <zo...@li...>]

On Thu, 2014-11-27 at 10:15 +0100, Christophe Fillot wrote:
> >
> > Are you using an initrd not an initramfs?  According to
> > Documentation/filesystems/ramfs-rootfs-initramfs.txt, "If
> CONFIG_TMPFS
> > is enabled, rootfs will use tmpfs instead of ramfs by default".
> >
> Yes, that what I thought too, but it seems that it is not really the 
> case because of this test:
> 
>      if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
>          (!root_fs_names || strstr(root_fs_names, "tmpfs"))) {
>          err = shmem_init();
>          is_tmpfs = true;
>      } else {
>          err = init_ramfs_fs();
>      }

[CC'ing Rob Landley, lsm, lkml]

Thanks!  "saved_root_name" is set to the boot command line "root="
option, which in my case is the UUID.  I'm not sure why real root should
impact the initramfs tmpfs/ramfs decision.

Unless there is a good explanation, did you want to post a patch to
remove the test?

Mimi

Re: [Linux-ima-user] [RFC] EVM: system independent signatures, non-modifiable signatures

[Mimi Z. <zo...@li...>]

On Fri, 2014-12-05 at 10:30 -0500, Mimi Zohar wrote: 
> On Fri, 2014-12-05 at 12:09 +0200, Dmitry Kasatkin wrote: 
> > On 04/12/14 18:43, Mimi Zohar wrote:
> > > On Thu, 2014-12-04 at 17:02 +0200, Dmitry Kasatkin wrote: 
> > >> On 04/12/14 15:52, Mimi Zohar wrote:
> > >>> System images would now have a combination of existing "normal" and new
> > >>> non-modifiable signatures.  For the existing "normal", wouldn't the new
> > >>> system independent signature, we discussed above, be desirable?  How
> > >>> would they be included?
> > >> Basically approach is to have 3 types of signatures
> > >>
> > >> 1. Normal (sig), system dependent, which includes i_no, fsuuid. They are
> > >> converted to HMAC. They are set during image creation..
> > >>
> > >> 2. System independent signatures (si-sig). They are set at runtime from
> > >> packages and included to the hmac calculation.
> > >>
> > >> 3. Normal, system dependent, but not convertible. They also include
> > >> i_no, fsuui, etc... They are set during image creation..
> > >>
> > >>
> > >> I think there is no need for combination: normal+si-sig
> > >>
> > >> What do you think?
> > > Agreed, but on flashed systems, everything is signed.  Some will now
> > > have the non-modifiable signature, but others won't.  Those that have
> > > the original "normal" signature will be converted to an HMAC.  Without
> > > storing the si-sig somewhere, it won't be available to append to the
> > > HMAC.  So, perhaps we do need the si-sig as a separate xattr after all.
> > >
> > > Mimi
> > >
> > >
> > 
> > I do not understand you a bit.
> > 
> > Yes some will have signatures which will be replaced with hmac, but some
> > not...
> > 
> > For those which replaced with hmac, signature will be gone...
> 
> Right, but there might be some benefit to protect other metadata for
> mutable files.

Forget this option.  The hash is still included in the si-sig.

Mimi

Re: [Linux-ima-user] [RFC] EVM: system independent signatures, non-modifiable signatures

[Mimi Z. <zo...@li...>]

On Fri, 2014-12-05 at 12:09 +0200, Dmitry Kasatkin wrote: 
> On 04/12/14 18:43, Mimi Zohar wrote:
> > On Thu, 2014-12-04 at 17:02 +0200, Dmitry Kasatkin wrote: 
> >> On 04/12/14 15:52, Mimi Zohar wrote:
> >>> System images would now have a combination of existing "normal" and new
> >>> non-modifiable signatures.  For the existing "normal", wouldn't the new
> >>> system independent signature, we discussed above, be desirable?  How
> >>> would they be included?
> >> Basically approach is to have 3 types of signatures
> >>
> >> 1. Normal (sig), system dependent, which includes i_no, fsuuid. They are
> >> converted to HMAC. They are set during image creation..
> >>
> >> 2. System independent signatures (si-sig). They are set at runtime from
> >> packages and included to the hmac calculation.
> >>
> >> 3. Normal, system dependent, but not convertible. They also include
> >> i_no, fsuui, etc... They are set during image creation..
> >>
> >>
> >> I think there is no need for combination: normal+si-sig
> >>
> >> What do you think?
> > Agreed, but on flashed systems, everything is signed.  Some will now
> > have the non-modifiable signature, but others won't.  Those that have
> > the original "normal" signature will be converted to an HMAC.  Without
> > storing the si-sig somewhere, it won't be available to append to the
> > HMAC.  So, perhaps we do need the si-sig as a separate xattr after all.
> >
> > Mimi
> >
> >
> 
> I do not understand you a bit.
> 
> Yes some will have signatures which will be replaced with hmac, but some
> not...
> 
> For those which replaced with hmac, signature will be gone...

Right, but there might be some benefit to protect other metadata for
mutable files.

Mimi

> For those which will not be replaced by hmac, signature will stay.
> 
> There is nothing to append anywhere and store anywhere...
> 
> - Dmitry

Re: [Linux-ima-user] [RFC] EVM: system independent signatures, non-modifiable signatures

[Dmitry K. <d.k...@sa...>]

On 04/12/14 18:43, Mimi Zohar wrote:
> On Thu, 2014-12-04 at 17:02 +0200, Dmitry Kasatkin wrote: 
>> On 04/12/14 15:52, Mimi Zohar wrote:
>>> System images would now have a combination of existing "normal" and new
>>> non-modifiable signatures.  For the existing "normal", wouldn't the new
>>> system independent signature, we discussed above, be desirable?  How
>>> would they be included?
>> Basically approach is to have 3 types of signatures
>>
>> 1. Normal (sig), system dependent, which includes i_no, fsuuid. They are
>> converted to HMAC. They are set during image creation..
>>
>> 2. System independent signatures (si-sig). They are set at runtime from
>> packages and included to the hmac calculation.
>>
>> 3. Normal, system dependent, but not convertible. They also include
>> i_no, fsuui, etc... They are set during image creation..
>>
>>
>> I think there is no need for combination: normal+si-sig
>>
>> What do you think?
> Agreed, but on flashed systems, everything is signed.  Some will now
> have the non-modifiable signature, but others won't.  Those that have
> the original "normal" signature will be converted to an HMAC.  Without
> storing the si-sig somewhere, it won't be available to append to the
> HMAC.  So, perhaps we do need the si-sig as a separate xattr after all.
>
> Mimi
>
>

I do not understand you a bit.

Yes some will have signatures which will be replaced with hmac, but some
not...

For those which replaced with hmac, signature will be gone...

For those which will not be replaced by hmac, signature will stay.

There is nothing to append anywhere and store anywhere...

- Dmitry

Re: [Linux-ima-user] [RFC] EVM: system independent signatures, non-modifiable signatures

[Mimi Z. <zo...@li...>]

On Thu, 2014-12-04 at 17:02 +0200, Dmitry Kasatkin wrote: 
> On 04/12/14 15:52, Mimi Zohar wrote:

> > System images would now have a combination of existing "normal" and new
> > non-modifiable signatures.  For the existing "normal", wouldn't the new
> > system independent signature, we discussed above, be desirable?  How
> > would they be included?
> 
> Basically approach is to have 3 types of signatures
> 
> 1. Normal (sig), system dependent, which includes i_no, fsuuid. They are
> converted to HMAC. They are set during image creation..
> 
> 2. System independent signatures (si-sig). They are set at runtime from
> packages and included to the hmac calculation.
> 
> 3. Normal, system dependent, but not convertible. They also include
> i_no, fsuui, etc... They are set during image creation..
> 
> 
> I think there is no need for combination: normal+si-sig
> 
> What do you think?

Agreed, but on flashed systems, everything is signed.  Some will now
have the non-modifiable signature, but others won't.  Those that have
the original "normal" signature will be converted to an HMAC.  Without
storing the si-sig somewhere, it won't be available to append to the
HMAC.  So, perhaps we do need the si-sig as a separate xattr after all.

Mimi

Re: [Linux-ima-user] [RFC] EVM: system independent signatures, non-modifiable signatures

[Dmitry K. <d.k...@sa...>]

On 04/12/14 15:52, Mimi Zohar wrote:
> On Thu, 2014-12-04 at 10:32 +0200, Dmitry Kasatkin wrote: 
>> On 04/12/14 00:56, Mimi Zohar wrote:
>>> On Wed, 2014-12-03 at 23:44 +0200, Dmitry Kasatkin wrote:
>>>>>> But there may be a different solution for this.
>>>>>> Leave security.evm with HMAC functioning as it is and add new
>>>>> extended
>>>>>> attribute security.evmsig
>>>>>> which will protect attrs and xattrs additionally with signatures.
>>>>> Let's think about this some.
>>>> Actually new xattr type can be used which includes both hmac and
>>>> signature to avoid using additional xattr.
>>>   
>>> Having both the HMAC, which includes the i_ino and i_version, and a
>>> system independent signature type (based on a subset of the HMAC fields)
>>> in a single xattr is a performance improvement.  We would still need a
>>> new type containing just the system independent signature, which could
>>> be included in software packages and archives.
>>>
>>> Mimi
>>>
>> Ok. My "immutable"/non-hmac-convertible signature is your term "system
>> independent signature".
>> Let's further use this term.
> [New subject line]
>
> There are a number of different signatures being discussed.  To
> differentiate this from other ones, let's refer to it as the
> si-signature/sig.
>
>> Yes, system independent signatures will come from packages and archives.
>> evm_inode_post_setxattr() hook can be changed so that setting it to
>> xattr at runtime would append it to HMAC xattr
> Here we're defining a new type to be included in packages/archives.

Ok...

>> or recalculate HMAC if we want to include signature to HMAC. 
> Clarifying here: to include the si-signature in the HMAC.

Ok...

>
>> In such case we do not need "system-independent-only" type.
> To summarize, the "system-independent-only" type is not stored as an
> independent xattr on target systems, but only stored in
> packages/archives.  Not all files will have the si-sig on the
> security.evm HMAC xattr.  Those that do have the si-sig would include it
> in the HMAC calculation.

Right....

>
> Before we go forward, let's discuss the implications.  Any other
> issues/concerns?
> - Who is the consumer of the si-sig?

I posted a patch before: ima: provide appraise_type=evmsig

http://sourceforge.net/p/linux-ima/mailman/message/32987306/

IMA policy can require evmsig (si-sig).
For example, when process is assigned "important" security label or
capability,
we want to make sure that it was signed....


> - How does this affect packages/archive creation?
> - What evmctl changes would be needed?

ima-evm-utils #branch has experimental patch to produce si-sig
(immutable signature there)

>> When we deal with the labeling of the file system image, we could also
>> have normal EVM signature which include i_no, etc, like we have now, but
>> non-replacable with hmac.
> We need a signature type that does not get converted to an HMAC the
> first time it is used.  For backwards compatibility, I don't think we
> want to change the existing signature type, but define a new
> version/type.  (More details needed ...)

Sure, absolutely.

> System images would now have a combination of existing "normal" and new
> non-modifiable signatures.  For the existing "normal", wouldn't the new
> system independent signature, we discussed above, be desirable?  How
> would they be included?

Basically approach is to have 3 types of signatures

1. Normal (sig), system dependent, which includes i_no, fsuuid. They are
converted to HMAC. They are set during image creation..

2. System independent signatures (si-sig). They are set at runtime from
packages and included to the hmac calculation.

3. Normal, system dependent, but not convertible. They also include
i_no, fsuui, etc... They are set during image creation..


I think there is no need for combination: normal+si-sig

What do you think?

Dmitry


> Mimi
>
>

[Linux-ima-user] [RFC] EVM: system independent signatures, non-modifiable signatures

[Mimi Z. <zo...@li...>]

On Thu, 2014-12-04 at 10:32 +0200, Dmitry Kasatkin wrote: 
> On 04/12/14 00:56, Mimi Zohar wrote:
> > On Wed, 2014-12-03 at 23:44 +0200, Dmitry Kasatkin wrote:
> >>>> But there may be a different solution for this.
> >>>> Leave security.evm with HMAC functioning as it is and add new
> >>> extended
> >>>> attribute security.evmsig
> >>>> which will protect attrs and xattrs additionally with signatures.
> >>> Let's think about this some.
> >> Actually new xattr type can be used which includes both hmac and
> >> signature to avoid using additional xattr.
> >   
> > Having both the HMAC, which includes the i_ino and i_version, and a
> > system independent signature type (based on a subset of the HMAC fields)
> > in a single xattr is a performance improvement.  We would still need a
> > new type containing just the system independent signature, which could
> > be included in software packages and archives.
> >
> > Mimi
> >
> 
> Ok. My "immutable"/non-hmac-convertible signature is your term "system
> independent signature".
> Let's further use this term.

[New subject line]

There are a number of different signatures being discussed.  To
differentiate this from other ones, let's refer to it as the
si-signature/sig.

> Yes, system independent signatures will come from packages and archives.
> evm_inode_post_setxattr() hook can be changed so that setting it to
> xattr at runtime would append it to HMAC xattr

Here we're defining a new type to be included in packages/archives.

> or recalculate HMAC if we want to include signature to HMAC. 

Clarifying here: to include the si-signature in the HMAC.

> In such case we do not need "system-independent-only" type.

To summarize, the "system-independent-only" type is not stored as an
independent xattr on target systems, but only stored in
packages/archives.  Not all files will have the si-sig on the
security.evm HMAC xattr.  Those that do have the si-sig would include it
in the HMAC calculation.

Before we go forward, let's discuss the implications.  Any other
issues/concerns?
- Who is the consumer of the si-sig?
- How does this affect packages/archive creation?
- What evmctl changes would be needed?

> When we deal with the labeling of the file system image, we could also
> have normal EVM signature which include i_no, etc, like we have now, but
> non-replacable with hmac.

We need a signature type that does not get converted to an HMAC the
first time it is used.  For backwards compatibility, I don't think we
want to change the existing signature type, but define a new
version/type.  (More details needed ...)

System images would now have a combination of existing "normal" and new
non-modifiable signatures.  For the existing "normal", wouldn't the new
system independent signature, we discussed above, be desirable?  How
would they be included?

Mimi

Re: [Linux-ima-user] Initramfs and IMA Appraisal

[Dmitry K. <d.k...@sa...>]

On 04/12/14 00:56, Mimi Zohar wrote:
> On Wed, 2014-12-03 at 23:44 +0200, Dmitry Kasatkin wrote:
>>>> But there may be a different solution for this.
>>>> Leave security.evm with HMAC functioning as it is and add new
>>> extended
>>>> attribute security.evmsig
>>>> which will protect attrs and xattrs additionally with signatures.
>>> Let's think about this some.
>> Actually new xattr type can be used which includes both hmac and
>> signature to avoid using additional xattr.
>   
> Having both the HMAC, which includes the i_ino and i_version, and a
> system independent signature type (based on a subset of the HMAC fields)
> in a single xattr is a performance improvement.  We would still need a
> new type containing just the system independent signature, which could
> be included in software packages and archives.
>
> Mimi
>

Ok. My "immutable"/non-hmac-convertible signature is your term "system
independent signature".
Let's further use this term.

Yes, system independent signatures will come from packages and archives.
evm_inode_post_setxattr() hook can be changed so that setting it to
xattr at runtime would append it to HMAC xattr or recalculate HMAC if we
want to include signature to HMAC. In such case we do not need
"system-independent-only" type.

When we deal with the labeling of the file system image, we could also
have normal EVM signature which include i_no, etc, like we have now, but
non-replacable with hmac.

- Dmitry

Re: [Linux-ima-user] Initramfs and IMA Appraisal

[Mimi Z. <zo...@li...>]

On Wed, 2014-12-03 at 23:44 +0200, Dmitry Kasatkin wrote:
> >> But there may be a different solution for this.
> >> Leave security.evm with HMAC functioning as it is and add new
> >extended
> >> attribute security.evmsig
> >> which will protect attrs and xattrs additionally with signatures.
> >
> >Let's think about this some.
> 
> Actually new xattr type can be used which includes both hmac and
> signature to avoid using additional xattr.
  
Having both the HMAC, which includes the i_ino and i_version, and a
system independent signature type (based on a subset of the HMAC fields)
in a single xattr is a performance improvement.  We would still need a
new type containing just the system independent signature, which could
be included in software packages and archives.

Mimi

Re: [Linux-ima-user] Initramfs and IMA Appraisal

[Dmitry K. <dmi...@gm...>]

On December 3, 2014 7:41:36 PM EET, Mimi Zohar <zo...@li...> wrote:
>On Wed, 2014-12-03 at 17:14 +0200, Dmitry Kasatkin wrote: 
>> On 03/12/14 16:00, Mimi Zohar wrote:
>> > On Wed, 2014-12-03 at 15:08 +0200, Dmitry Kasatkin wrote: 
>
>> > For "security.ima" immutable implies not only that the extended
>> > attribute does not change, but also that the file data can not
>change.
>> >
>> > For EVM, immutable would imply not only that the "security.evm"
>extended
>> > attribute, as you're suggesting, does not change, but would also
>prevent
>> > any of the other file metadata from changing either.
>> 
>> This is exactly what patchset is doing.
>> > At that point the file data and metadata are immutable.  The next
>step
>> > would be making the file immutable, preventing it from being
>removed
>> > and/or replaced.
>> 
>> This is achieved by setting file immutable bit "chattr +i foo".
>> Immutable bit needs to be protected.
>> I posted patch about it
>> 
>> http://sourceforge.net/p/linux-ima/mailman/message/32893464/
>
>[CC'ing Dave Safford]
>
>Yes, using the immutable bit makes files, well, "immutable". :)  Being
>able to piggy-back on the existing immutable bit would be nice, but
>requiring software updates to first remove the immutable bit, before
>being able to remove them, doesn't seem feasible.
>
>We want the equivalent of the immutable bit, an immutable or "locked"
>flag, which starts out as disabled and is enabled during boot.  Once
>enabled, the flag cannot be disabled.  This would allow software
>packages to be updated, prior to the "locked" flag being set.
>
>> > What are the security implications of removing the i_ino (and
>iversion)
>> > from the HMAC calculation?  What are the risks associated with it?
>> 
>> iversion has no any value in EVM protection as it can be arbitrary
>changed.
>> 
>> i_no is more tricky.
>> It prevents pasting of inode from "other" filesystem which uses the
>> "same" HMAC key.
>> Between systems HMAC key is different...
>
>> From other hand when using signatures, public key is the same.
>> It looks like pasting of inodes from different filesystems are easy.
>
>Or even the same filesystem.
>
>> But we should not forget that file is immutable - data and attrs
>cannot
>> be changed.
>> Signer controls the key and what he signs.
>> Substituting file with another file from the same signer does not
>seem
>> to be a big issue...
>
>Files, signed by trusted parties, are known to have vulnerabilities.

i_no is not unique and can be the same.


>
>> But there may be a different solution for this.
>> Leave security.evm with HMAC functioning as it is and add new
>extended
>> attribute security.evmsig
>> which will protect attrs and xattrs additionally with signatures.
>
>Let's think about this some.

Actually new xattr type can be used which includes both hmac and signature to avoid using additional xattr.

Dmitry

>
>Mimi
>
>
>------------------------------------------------------------------------------
>Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>from Actuate! Instantly Supercharge Your Business Reports and
>Dashboards
>with Interactivity, Sharing, Native Excel Exports, App Integration &
>more
>Get technology previously reserved for billion-dollar corporations,
>FREE
>http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>_______________________________________________
>Linux-ima-user mailing list
>Lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linux-ima-user


- Dmitry