Menu
▾
▴
linux-ima-user — Q&A for users of IMA
This list is closed, nobody may subscribe to it.
| 2007 |
Jan
|
Feb
(10) |
Mar
(26) |
Apr
(8) |
May
(3) |
Jun
|
Jul
(26) |
Aug
(10) |
Sep
|
Oct
|
Nov
(2) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(13) |
Mar
(4) |
Apr
(3) |
May
(5) |
Jun
|
Jul
(7) |
Aug
(8) |
Sep
(5) |
Oct
(16) |
Nov
|
Dec
(6) |
| 2009 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
(19) |
Jul
(4) |
Aug
|
Sep
(13) |
Oct
(10) |
Nov
(12) |
Dec
(2) |
| 2010 |
Jan
|
Feb
(2) |
Mar
(17) |
Apr
(28) |
May
|
Jun
(17) |
Jul
(11) |
Aug
(12) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
|
Mar
(20) |
Apr
(10) |
May
(1) |
Jun
|
Jul
|
Aug
(15) |
Sep
(14) |
Oct
(2) |
Nov
|
Dec
|
| 2012 |
Jan
(1) |
Feb
(53) |
Mar
(15) |
Apr
(4) |
May
(2) |
Jun
(13) |
Jul
|
Aug
|
Sep
(12) |
Oct
|
Nov
|
Dec
(6) |
| 2013 |
Jan
(7) |
Feb
(8) |
Mar
(4) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
(6) |
Oct
|
Nov
(5) |
Dec
(8) |
| 2014 |
Jan
(17) |
Feb
(24) |
Mar
(8) |
Apr
(7) |
May
(18) |
Jun
(15) |
Jul
(5) |
Aug
(2) |
Sep
(49) |
Oct
(28) |
Nov
(7) |
Dec
(30) |
| 2015 |
Jan
(40) |
Feb
|
Mar
(9) |
Apr
(2) |
May
(9) |
Jun
(31) |
Jul
(33) |
Aug
(5) |
Sep
(20) |
Oct
|
Nov
(3) |
Dec
(12) |
| 2016 |
Jan
(14) |
Feb
(29) |
Mar
(10) |
Apr
(4) |
May
(4) |
Jun
|
Jul
(5) |
Aug
(19) |
Sep
(21) |
Oct
(2) |
Nov
(36) |
Dec
(30) |
| 2017 |
Jan
(101) |
Feb
(12) |
Mar
(7) |
Apr
(2) |
May
(29) |
Jun
(22) |
Jul
(7) |
Aug
(93) |
Sep
(27) |
Oct
(39) |
Nov
|
Dec
|
|
From: Qingping H. <dav...@gm...> - 2011-03-16 17:20:33
|
Hi all, I am currently learning how to make use of ima. After compile the kernel according to the official document, I can now get the measured hash value from ascii_runtime_measurements file. However, I cannot fine tpm0 file in /sys/kernel/security/ directory. Actually I am using tpm-emulator, not a real tpm device. Could that be the cause? Best regards, Hou Qingping |
|
From: Mimi Z. <zo...@li...> - 2010-12-10 13:37:16
|
Following the EVM talk at this year's Linux Security Summit held in conjunction with LinuxCon, a discussion ensued questioning some of the integrity design decisions as implemented in the EVM/IMA-appraisal patch set. A whitepaper "An Overview of the Linux Integrity Subsystem" attempts to address these concerns. (http://downloads.sf.net/project/linux-ima/linux-ima/Integrity_overview.pdf) For anyone interested in the proposed integrity subsystem, linux-ima.sourceforge.net has been updated with new, hopefully, simplified installation directions, patches to use the new Trusted/Encrypted keys, which is now in the security-testing/#next tree, a few bug fixes, and a sample dracut patch to enable EVM in the initramfs. (The patches are against the 2.6.36 stable tree.) thanks, Mimi Zohar David Safford |
|
From: TEH J. Y. <jy...@ya...> - 2010-09-09 08:06:59
|
Test Mail to see if Lin...@li... OK for my mail add.
|
|
From: chloé F. <fou...@gm...> - 2010-09-01 12:22:48
|
Hi, Do you know if it's possible to configure IMA to take a measurement of a specific application when it's running and store this measurement in a specific PCR in order to make possible the unseal operation only if there is this specific application running. What I want to do is making an information available only to a specific application. Thanks for looking Chloé |
|
From: David S. <sa...@wa...> - 2010-08-20 13:50:45
|
> Unfortunately, our target device uses ymfs2 as its file system (android > specific) which does not supports extended attributes/labels. I know > that there is a patch for this used/provided by selinux. But for my > feeling this is in a way not the cleanest solution. > > Is there another way to use IMA for individual files without labels? > > nicolai Currently there is no other way to designate specific files to measure, and I'm not sure how else would you do it. When IMA is deciding whether or not to measure an inode, it has context information (including requesting uid and subject information), and the inode information (including owner and extended attributes). That's all an IMA policy has to make the decision. If you want to be able to measure an arbitrary set of files, the filesystem attributes are the right place to indicate the selection. It is tempting to put the selection into the policy somehow, but there is no good way to do that. You can't put pathnames in the policy, and even if you translated paths into inodes, the result would not be scalable, and would have problems with creating and deleting files. That's functionality that belongs in the filesystem. You could try to use the new fanotify system to push the decision up into a userspace database, but that would require an extension to fanotify, and would likely be quite slow. We are open to suggestions, but I don't see a good way to do selection without labels. dave |
|
From: Nicolai K. <nic...@si...> - 2010-08-20 09:48:19
|
David Safford wrote:
>> Thank you for your quick answer. Could you provide for a short
>> demonstartion using the IMA policies with LSM policies? It would help us
>> a lot to see good examples to get a better understanding on the policy
>> system.
>>
>> Nicolai
>
> Using Smack labels for IMA measurement control.
>
> IMA has a flexible policy language for specifying which files
> are to be measured or not measured. In some cases, a more
> fined grained, or file-by-file control of measurement is desired.
> The IMA policy language can use LSM labels on individual files
> in the policy language for fine grained specifications, but
> this can be complex, particularly with SELinux as the LSM.
>
> Smack provides a very simple way to label files for measurement,
> and the following example shows how to use it this way, using a
> label of 'M' to designate that a file is to be measured.
>
> 1. Configure/compile/install/boot a kernel with IMA and Smack built in.
>
> 2. mount smackfs and securityfs (for IMA):
> - mkdir /smack
> - add the following lines to /etc/fstab:
> smackfs /smack smackfs smackfsdef=* 0 0
> securityfs /sys/kernel/security securityfs defaults 0 0
> - mount /smack; mount /sys/kernel/security
>
> 3. add a Smack policy for "M" (for objects which are to be measured):
> "_ M rwxa"
> The easiest way to do this is to create a file with exactly these
> contents:
> "_ M rwxa"
> and cat this file into /smack/load in an early init script.
> Note that the file must be exactly these 52 bytes
> ('_' 23 spaces, 'M', 23 spaces, "rwxa") without any trailing
> null, newline, or spaces. Alternately you can install the smack
> utilities, and use the program smackload to format and load the rule.
>
> 4. load an IMA policy with the new rule "measure obj_user=M",
> to tell IMA to measure all files with a Smack label of "M"
> This can be combined with the default policy to measure all
> executables and to ignore virtual filesystems:
> # PROC_SUPER_MAGIC
> dont_measure fsmagic=0x9fa0
> # SYSFS_MAGIC
> dont_measure fsmagic=0x62656572
> # DEBUGFS_MAGIC
> dont_measure fsmagic=0x64626720
> # TMPFS_MAGIC
> dont_measure fsmagic=0x01021994
> # SECURITYFS_MAGIC
> dont_measure fsmagic=0x73636673
> measure func=BPRM_CHECK
> measure func=FILE_MMAP mask=MAY_EXEC
> measure func=FILE_CHECK mask=MAY_READ obj_user=M
> The policy is copied into /sys/kernel/security/ima/policy.
> The policy should be loaded just after loading the Smack policy.
>
> 5. label any files you want measured with an 'M' Smack label:
> setfattr -n security.SMACK64 -v M file ...
>
> That's it.
>
> In this mode, everything runs at Smack level "_", and we
> are using Smack just to query Smack's object (file) labels.
>
> Note that in this mode, new files will by default will get a '_'
> label, so if you want new files to be measured, you have to
> explicitly set their labels after they are first created.
>
> dave
Unfortunately, our target device uses ymfs2 as its file system (android
specific) which does not supports extended attributes/labels. I know
that there is a patch for this used/provided by selinux. But for my
feeling this is in a way not the cleanest solution.
Is there another way to use IMA for individual files without labels?
nicolai
|
|
From: David S. <sa...@wa...> - 2010-08-19 20:13:35
|
> Thank you for your quick answer. Could you provide for a short
> demonstartion using the IMA policies with LSM policies? It would help us
> a lot to see good examples to get a better understanding on the policy
> system.
>
> Nicolai
Using Smack labels for IMA measurement control.
IMA has a flexible policy language for specifying which files
are to be measured or not measured. In some cases, a more
fined grained, or file-by-file control of measurement is desired.
The IMA policy language can use LSM labels on individual files
in the policy language for fine grained specifications, but
this can be complex, particularly with SELinux as the LSM.
Smack provides a very simple way to label files for measurement,
and the following example shows how to use it this way, using a
label of 'M' to designate that a file is to be measured.
1. Configure/compile/install/boot a kernel with IMA and Smack built in.
2. mount smackfs and securityfs (for IMA):
- mkdir /smack
- add the following lines to /etc/fstab:
smackfs /smack smackfs smackfsdef=* 0 0
securityfs /sys/kernel/security securityfs defaults 0 0
- mount /smack; mount /sys/kernel/security
3. add a Smack policy for "M" (for objects which are to be measured):
"_ M rwxa"
The easiest way to do this is to create a file with exactly these
contents:
"_ M rwxa"
and cat this file into /smack/load in an early init script.
Note that the file must be exactly these 52 bytes
('_' 23 spaces, 'M', 23 spaces, "rwxa") without any trailing
null, newline, or spaces. Alternately you can install the smack
utilities, and use the program smackload to format and load the rule.
4. load an IMA policy with the new rule "measure obj_user=M",
to tell IMA to measure all files with a Smack label of "M"
This can be combined with the default policy to measure all
executables and to ignore virtual filesystems:
# PROC_SUPER_MAGIC
dont_measure fsmagic=0x9fa0
# SYSFS_MAGIC
dont_measure fsmagic=0x62656572
# DEBUGFS_MAGIC
dont_measure fsmagic=0x64626720
# TMPFS_MAGIC
dont_measure fsmagic=0x01021994
# SECURITYFS_MAGIC
dont_measure fsmagic=0x73636673
measure func=BPRM_CHECK
measure func=FILE_MMAP mask=MAY_EXEC
measure func=FILE_CHECK mask=MAY_READ obj_user=M
The policy is copied into /sys/kernel/security/ima/policy.
The policy should be loaded just after loading the Smack policy.
5. label any files you want measured with an 'M' Smack label:
setfattr -n security.SMACK64 -v M file ...
That's it.
In this mode, everything runs at Smack level "_", and we
are using Smack just to query Smack's object (file) labels.
Note that in this mode, new files will by default will get a '_'
label, so if you want new files to be measured, you have to
explicitly set their labels after they are first created.
dave
|
|
From: Nicolai K. <nic...@si...> - 2010-08-19 13:05:49
|
Mimi Zohar wrote: > On Wed, 2010-08-18 at 16:21 +0200, Nicolai Kuntze wrote: >> Dear all, >> >> within an ongoing research project we have the need to measure specific >> files like configuration files or disk images. Up to now we are using >> the /ima/measurereq file to announce the measurement. >> >> Do to performance restrictions we are not able to move to the >> measurement of all files accessed by a certain user. Unfortunately, I >> can not see how to model the measurement of a set of specific files in >> the given policy language. >> >> Is there an example available? >> >> Best regards, >> Nicolai > > The default measurement policy, which measures everything that could > affect the TCB, can be constrained or replaced with one based on LSM > labels. > > For example, with an SELinux targeted policy, you could define a rule > like 'measure obj_type=etc_t' to measure configuration files and the > equivalent for VMs. > > Or with Smack, you probably could define a new label that is equivalent > to floor '_'. Write 'security.smack' with the new label on those files > you're interested in measuring. Of course, you'd also need some > mechanism to label new files as they're created. > > Mimi > Thank you for your quick answer. Could you provide for a short demonstartion using the IMA policies with LSM policies? It would help us a lot to see good examples to get a better understanding on the policy system. Nicolai |
|
From: Mimi Z. <zo...@li...> - 2010-08-18 22:04:50
|
On Wed, 2010-08-18 at 16:21 +0200, Nicolai Kuntze wrote: > Dear all, > > within an ongoing research project we have the need to measure specific > files like configuration files or disk images. Up to now we are using > the /ima/measurereq file to announce the measurement. > > Do to performance restrictions we are not able to move to the > measurement of all files accessed by a certain user. Unfortunately, I > can not see how to model the measurement of a set of specific files in > the given policy language. > > Is there an example available? > > Best regards, > Nicolai The default measurement policy, which measures everything that could affect the TCB, can be constrained or replaced with one based on LSM labels. For example, with an SELinux targeted policy, you could define a rule like 'measure obj_type=etc_t' to measure configuration files and the equivalent for VMs. Or with Smack, you probably could define a new label that is equivalent to floor '_'. Write 'security.smack' with the new label on those files you're interested in measuring. Of course, you'd also need some mechanism to label new files as they're created. Mimi |
|
From: Nicolai K. <nic...@si...> - 2010-08-18 14:40:38
|
Dear all, within an ongoing research project we have the need to measure specific files like configuration files or disk images. Up to now we are using the /ima/measurereq file to announce the measurement. Do to performance restrictions we are not able to move to the measurement of all files accessed by a certain user. Unfortunately, I can not see how to model the measurement of a set of specific files in the given policy language. Is there an example available? Best regards, Nicolai -- Nicolai Kuntze (Dipl.-Inform.) Department "Secure Mobile Systems (SIMS)" My signature is certified by Fraunhofer Certification Authority: http://pki.fraunhofer.de/FhG-CA-Certs/FhG-CA_v2_cert.der Addr: Fraunhofer-Institute for Secure Information Technology SIT Rheinstrasse 75, 64295 Darmstadt, Germany WWW: http://www.sit.fraunhofer.de Tel: +49-(0)6151/869-276 Fax: +49-(0)6151/869-224 |
|
From: Mimi Z. <zo...@li...> - 2010-08-12 12:23:44
|
On Wed, 2010-08-11 at 10:26 +0500, waqar afridi wrote: > Sorry for late Reply but the package libssl-dev already exists, > reinstalling also didnt solved the Problem, I tried to convert the > openssl-static from rpm to deb but the process failed. Which version of ltp are you using? A problem was reported by Stephen Smalley, which has since been corrected. http://sourceforge.net/mailarchive/forum.php?thread_name=1278180017.7665.16.camel%40subratamodak.linux.ibm.com&forum_name=ltp-list thanks, Mimi |
|
From: waqar a. <afr...@gm...> - 2010-08-11 05:27:09
|
Sorry for late Reply but the package libssl-dev already exists, reinstalling also didnt solved the Problem, I tried to convert the openssl-static from rpm to deb but the process failed. On Wed, Aug 11, 2010 at 4:54 AM, Mimi Zohar <zo...@li...>wrote: > On Mon, 2010-08-09 at 16:04 +0500, waqar afridi wrote: > > Hi List > > > > > > I have compiled ima_boot_aggregate.c from test suite, now when I try > > to run it, it gives the following message > > > > > > # ./ima_boot_aggregate > /sys/kernel/security/ima/binary_runtime_measurements > > > > > > ima_boot_aggregate 1 TCONF : System doesn't have openssl/sha.h > > > > > > here's the Locate Command I ran for sha.h > > > > > > #locate sha.h > > > > > > /root/Desktop/openssl-0.9.8o/crypto/sha/sha.h > > /root/Desktop/openssl-0.9.8o/include/openssl/sha.h > > /usr/include/openssl/sha.h > > /usr/local/ssl/include/openssl/sha.h > > /usr/src/linux-2.6.35/arch/s390/crypto/sha.h > > /usr/src/linux-2.6.35/include/config/crypto/dev/padlock/sha.h > > /usr/src/linux-2.6.35/include/crypto/sha.h > > /usr/src/linux-headers-2.6.28-11/include/crypto/sha.h > > > /usr/src/linux-headers-2.6.28-11-generic/include/config/crypto/dev/padlock/sha.h > > > > > > I have installed openssl from synaptic manager and also from source > > but can't solve this problem > > just in case I am using ubuntu 9.04 > > > > > > Any kind of help will be appreciated. > > > > > > Thanx in advance > > > > -- > > Waqar Afridi > > On Fedora the package is openssl-devel. (You might also need > openssl-static.) It seems, but I haven't tried it, that on Ubuntu you > need libssl-dev. > > Mimi > > > -- Waqar Afridi |
|
From: Mimi Z. <zo...@li...> - 2010-08-10 23:55:07
|
On Mon, 2010-08-09 at 16:04 +0500, waqar afridi wrote: > Hi List > > > I have compiled ima_boot_aggregate.c from test suite, now when I try > to run it, it gives the following message > > > # ./ima_boot_aggregate /sys/kernel/security/ima/binary_runtime_measurements > > > ima_boot_aggregate 1 TCONF : System doesn't have openssl/sha.h > > > here's the Locate Command I ran for sha.h > > > #locate sha.h > > > /root/Desktop/openssl-0.9.8o/crypto/sha/sha.h > /root/Desktop/openssl-0.9.8o/include/openssl/sha.h > /usr/include/openssl/sha.h > /usr/local/ssl/include/openssl/sha.h > /usr/src/linux-2.6.35/arch/s390/crypto/sha.h > /usr/src/linux-2.6.35/include/config/crypto/dev/padlock/sha.h > /usr/src/linux-2.6.35/include/crypto/sha.h > /usr/src/linux-headers-2.6.28-11/include/crypto/sha.h > /usr/src/linux-headers-2.6.28-11-generic/include/config/crypto/dev/padlock/sha.h > > > I have installed openssl from synaptic manager and also from source > but can't solve this problem > just in case I am using ubuntu 9.04 > > > Any kind of help will be appreciated. > > > Thanx in advance > > -- > Waqar Afridi On Fedora the package is openssl-devel. (You might also need openssl-static.) It seems, but I haven't tried it, that on Ubuntu you need libssl-dev. Mimi |
|
From: waqar a. <afr...@gm...> - 2010-08-09 11:05:02
|
Hi List I have compiled *ima_boot_aggregate.c* from test suite, now when I try to run it, it gives the following message # ./ima_boot_aggregate /sys/kernel/security/ima/binary_runtime_measurements *ima_boot_aggregate 1 TCONF : System doesn't have openssl/sha.h* here's the Locate Command I ran for sha.h #locate sha.h /root/Desktop/openssl-0.9.8o/crypto/sha/sha.h /root/Desktop/openssl-0.9.8o/include/openssl/sha.h */usr/include/openssl/sha.h* /usr/local/ssl/include/openssl/sha.h /usr/src/linux-2.6.35/arch/s390/crypto/sha.h /usr/src/linux-2.6.35/include/config/crypto/dev/padlock/sha.h /usr/src/linux-2.6.35/include/crypto/sha.h /usr/src/linux-headers-2.6.28-11/include/crypto/sha.h /usr/src/linux-headers-2.6.28-11-generic/include/config/crypto/dev/padlock/sha.h I have installed openssl from synaptic manager and also from source but can't solve this problem just in case I am using ubuntu 9.04 Any kind of help will be appreciated. Thanx in advance -- Waqar Afridi |
|
From: Mimi Z. <zo...@li...> - 2010-08-02 01:30:15
|
On Sun, 2010-08-01 at 14:19 +0100, chloé Fouquet wrote: > Hi, > > I would like to create an application that can open and edit > documents. Which IMA measurements should I have a look at in order to > know if my access control policy other the documents will be applied > and that the application can be trusted and has not been modified ? > > Cheers, > > Chloé For Mandatory Access Control(MAC) you have a choice of SELinux, Smack, Tomoyo and now, as of last week, AppArmor. Currently, IMA maintains an integrity measurement list (<securityfs>/ima/ascii_runtime_measurements), but does not enforce integrity. You can validate the measurement list and make sure the hash of your application has not changed. The LTP testsuite contains an example of validating the IMA measurement list (<ltp>/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh). The EVM/IMA-appraisal patches, if/when accepted, will add integrity enforcement. Mimi |
|
From: chloé F. <fou...@gm...> - 2010-08-01 13:19:18
|
Hi, I would like to create an application that can open and edit documents. Which IMA measurements should I have a look at in order to know if my access control policy other the documents will be applied and that the application can be trusted and has not been modified ? Cheers, Chloé |
|
From: Mimi Z. <zo...@li...> - 2010-07-14 12:47:39
|
On Wed, 2010-07-14 at 10:34 +0200, Roberto Sassu wrote:
> On 07/14/2010 08:29 AM, Seiji Munetoh wrote:
> > On Wed, Jul 14, 2010 at 2:42 PM, Shaz<sha...@gm...> wrote:
> >
> >>
> >> On Wed, Jul 14, 2010 at 3:08 AM, Seiji Munetoh<sei...@gm...>
> >> wrote:
> >>
> >>> On Thu, Jul 8, 2010 at 10:14 PM, Mimi Zohar<zo...@li...>
> >>> wrote:
> >>>
> >>>> On Tue, 2010-07-06 at 17:08 +0200, Roberto Sassu wrote:
> >>>>
> >>>>> This patch modifies the default policy shipped with IMA, in order to
> >>>>> avoid measurements
> >>>>> of files in the initial ramdisk. Those files can be measured early in
> >>>>> the boot process
> >>>>> by the bootloader.
> >>>>> The patch applies to latest version of the mainline kernel 2.6.35-rc4.
> >>>>>
> >>>> Yes, the initramfs measurements are therefore redundant, as they're
> >>>> already included in the initramfs measurement, but perhaps, as the
> >>>> number of initramfs is very limited and the individual file measurements
> >>>> supplies additional information, it wouldn't hurt to keep the individual
> >>>> file measurements as well. These measurements could potentially help in
> >>>> identifying initramfs changes.
> >>>>
> >>>> Would appreciate other opinions before accepting this change.
> >>>>
> >>> The hash value of the initramfs is unstable since it was generated
> >>> at the time of kernel installation.
> >>> So still I want to check the individual used file in initramfs.
> >>>
> >> If initrd is measured by boot loader then changes to individual files should
> >> not be measured as this IS redundant. Use the new hash of the initrd as an
> >> integrity metric. Why would this not be enough?
> >>
> > This depends on remote verifier.
> > Creating the initramfs is client side task and the hash value of initramfs
> > will vary each clients.
> >
> > For me, validation of current measurements is easier than validation of
> > initramfs. And it seems the overhead of this redundancy is less painful.
> >
> > But some system can validate (or trust) the initramfs measured by IPL.
> > So, I would suggest that add Kconfig option to change the default policy.
If your other suggestion, below, of adding fsmagic info to the
measurement list doesn't suffice, then defining a new command line
option, in addition to 'ima_tcb', shouldn't be a problem.
> > IMHO, if the eventlog contains fsmagic information for each measurements.
> > Verifier can skip the validation of RAMFS measurement easily.
Ok, so this takes us back to the discussion on what should be included
in the ima-nglong template. So far we have the hash algorithm(sha1,
sha256, sha512), the hash digest, filename, uid/gid, and LSM obj/subj
labels. We can add the fsmagic after the uid/gid. Before upstreaming
the template patches, is there anything else? (Remember, the more info
we add, the larger the measurement list becomes, so we shouldn't add
anything superfluously.)
> This is true, the initramfs's digest cannot be validated by a remote
> verifier. But in my opinion there are three main reasons for don't
> include those files in the measurement list.
> First, this is a readonly system and measures don't change in time; so
> if you create the image under a controlled environment and its digest
> doesn't change you can assert it will behave correctly.
A 'controlled environment' might exist for some device types, but not
for others.
> Second, including those measurements may be very confusing for a
> verifier since there may be multiple versions of the same object (the
> initramfs changes very rarely in respect to other files).
Extending the ima-nglong template to include fsmagic, as Seiji
suggested, should resolve this problem.
> Lastly, a pratical use of IMA is to load a custom policy. The better
> place to do that is the initramfs but measurements cannot be taken until
> the policy is loaded. The only way, as Shaz mentioned in a previous
> email, to keep track of all actions made during the boot process is that
> you have the initramfs image measured early by the boot loader.
Yes, nobody is suggesting otherwise. If adding fsmagic doesn't suffice,
then in addition to 'ima_tcb', another command line option could be
defined which doesn't measure initramfs files.
Mimi
|
|
From: Roberto S. <rob...@po...> - 2010-07-14 08:35:05
|
On 07/14/2010 08:29 AM, Seiji Munetoh wrote: > On Wed, Jul 14, 2010 at 2:42 PM, Shaz<sha...@gm...> wrote: > >> >> On Wed, Jul 14, 2010 at 3:08 AM, Seiji Munetoh<sei...@gm...> >> wrote: >> >>> On Thu, Jul 8, 2010 at 10:14 PM, Mimi Zohar<zo...@li...> >>> wrote: >>> >>>> On Tue, 2010-07-06 at 17:08 +0200, Roberto Sassu wrote: >>>> >>>>> This patch modifies the default policy shipped with IMA, in order to >>>>> avoid measurements >>>>> of files in the initial ramdisk. Those files can be measured early in >>>>> the boot process >>>>> by the bootloader. >>>>> The patch applies to latest version of the mainline kernel 2.6.35-rc4. >>>>> >>>> Yes, the initramfs measurements are therefore redundant, as they're >>>> already included in the initramfs measurement, but perhaps, as the >>>> number of initramfs is very limited and the individual file measurements >>>> supplies additional information, it wouldn't hurt to keep the individual >>>> file measurements as well. These measurements could potentially help in >>>> identifying initramfs changes. >>>> >>>> Would appreciate other opinions before accepting this change. >>>> >>> The hash value of the initramfs is unstable since it was generated >>> at the time of kernel installation. >>> So still I want to check the individual used file in initramfs. >>> >> If initrd is measured by boot loader then changes to individual files should >> not be measured as this IS redundant. Use the new hash of the initrd as an >> integrity metric. Why would this not be enough? >> > This depends on remote verifier. > Creating the initramfs is client side task and the hash value of initramfs > will vary each clients. > > For me, validation of current measurements is easier than validation of > initramfs. And it seems the overhead of this redundancy is less painful. > > But some system can validate (or trust) the initramfs measured by IPL. > So, I would suggest that add Kconfig option to change the default policy. > > IMHO, if the eventlog contains fsmagic information for each measurements. > Verifier can skip the validation of RAMFS measurement easily. > > This is true, the initramfs's digest cannot be validated by a remote verifier. But in my opinion there are three main reasons for don't include those files in the measurement list. First, this is a readonly system and measures don't change in time; so if you create the image under a controlled environment and its digest doesn't change you can assert it will behave correctly. Second, including those measurements may be very confusing for a verifier since there may be multiple versions of the same object (the initramfs changes very rarely in respect to other files). Lastly, a pratical use of IMA is to load a custom policy. The better place to do that is the initramfs but measurements cannot be taken until the policy is loaded. The only way, as Shaz mentioned in a previous email, to keep track of all actions made during the boot process is that you have the initramfs image measured early by the boot loader. Roberto > -- > Seiji > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Linux-ima-user mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-user > |
|
From: Seiji M. <sei...@gm...> - 2010-07-14 06:29:21
|
On Wed, Jul 14, 2010 at 2:42 PM, Shaz <sha...@gm...> wrote: > > > On Wed, Jul 14, 2010 at 3:08 AM, Seiji Munetoh <sei...@gm...> > wrote: >> >> On Thu, Jul 8, 2010 at 10:14 PM, Mimi Zohar <zo...@li...> >> wrote: >> > On Tue, 2010-07-06 at 17:08 +0200, Roberto Sassu wrote: >> >> This patch modifies the default policy shipped with IMA, in order to >> >> avoid measurements >> >> of files in the initial ramdisk. Those files can be measured early in >> >> the boot process >> >> by the bootloader. >> >> The patch applies to latest version of the mainline kernel 2.6.35-rc4. >> > >> > Yes, the initramfs measurements are therefore redundant, as they're >> > already included in the initramfs measurement, but perhaps, as the >> > number of initramfs is very limited and the individual file measurements >> > supplies additional information, it wouldn't hurt to keep the individual >> > file measurements as well. These measurements could potentially help in >> > identifying initramfs changes. >> > >> > Would appreciate other opinions before accepting this change. >> >> The hash value of the initramfs is unstable since it was generated >> at the time of kernel installation. >> So still I want to check the individual used file in initramfs. > > If initrd is measured by boot loader then changes to individual files should > not be measured as this IS redundant. Use the new hash of the initrd as an > integrity metric. Why would this not be enough? This depends on remote verifier. Creating the initramfs is client side task and the hash value of initramfs will vary each clients. For me, validation of current measurements is easier than validation of initramfs. And it seems the overhead of this redundancy is less painful. But some system can validate (or trust) the initramfs measured by IPL. So, I would suggest that add Kconfig option to change the default policy. IMHO, if the eventlog contains fsmagic information for each measurements. Verifier can skip the validation of RAMFS measurement easily. -- Seiji |
|
From: Shaz <sha...@gm...> - 2010-07-14 05:42:13
|
On Wed, Jul 14, 2010 at 3:08 AM, Seiji Munetoh <sei...@gm...>wrote: > On Thu, Jul 8, 2010 at 10:14 PM, Mimi Zohar <zo...@li...> > wrote: > > On Tue, 2010-07-06 at 17:08 +0200, Roberto Sassu wrote: > >> This patch modifies the default policy shipped with IMA, in order to > avoid measurements > >> of files in the initial ramdisk. Those files can be measured early in > the boot process > >> by the bootloader. > >> The patch applies to latest version of the mainline kernel 2.6.35-rc4. > > > > Yes, the initramfs measurements are therefore redundant, as they're > > already included in the initramfs measurement, but perhaps, as the > > number of initramfs is very limited and the individual file measurements > > supplies additional information, it wouldn't hurt to keep the individual > > file measurements as well. These measurements could potentially help in > > identifying initramfs changes. > > > > Would appreciate other opinions before accepting this change. > > The hash value of the initramfs is unstable since it was generated > at the time of kernel installation. > So still I want to check the individual used file in initramfs. > If initrd is measured by boot loader then changes to individual files should not be measured as this IS redundant. Use the new hash of the initrd as an integrity metric. Why would this not be enough? -- Shaz |
|
From: Seiji M. <sei...@gm...> - 2010-07-13 22:08:28
|
On Thu, Jul 8, 2010 at 10:14 PM, Mimi Zohar <zo...@li...> wrote:
> On Tue, 2010-07-06 at 17:08 +0200, Roberto Sassu wrote:
>> This patch modifies the default policy shipped with IMA, in order to avoid measurements
>> of files in the initial ramdisk. Those files can be measured early in the boot process
>> by the bootloader.
>> The patch applies to latest version of the mainline kernel 2.6.35-rc4.
>
> Yes, the initramfs measurements are therefore redundant, as they're
> already included in the initramfs measurement, but perhaps, as the
> number of initramfs is very limited and the individual file measurements
> supplies additional information, it wouldn't hurt to keep the individual
> file measurements as well. These measurements could potentially help in
> identifying initramfs changes.
>
> Would appreciate other opinions before accepting this change.
The hash value of the initramfs is unstable since it was generated
at the time of kernel installation.
So still I want to check the individual used file in initramfs.
regards,
--
Seiji
>
> thanks,
>
> Mimi
>
>> Signed-off-by: Roberto Sassu <rob...@po...>
>> ---
>> security/integrity/ima/ima_policy.c | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
>> index aef8c0a..92d8d0e 100644
>> --- a/security/integrity/ima/ima_policy.c
>> +++ b/security/integrity/ima/ima_policy.c
>> @@ -64,6 +64,7 @@ static struct ima_measure_rule_entry default_rules[] = {
>> {.action = DONT_MEASURE,.fsmagic = TMPFS_MAGIC,.flags = IMA_FSMAGIC},
>> {.action = DONT_MEASURE,.fsmagic = SECURITYFS_MAGIC,.flags = IMA_FSMAGIC},
>> {.action = DONT_MEASURE,.fsmagic = SELINUX_MAGIC,.flags = IMA_FSMAGIC},
>> + {.action = DONT_MEASURE,.fsmagic = RAMFS_MAGIC,.flags = IMA_FSMAGIC},
>> {.action = MEASURE,.func = FILE_MMAP,.mask = MAY_EXEC,
>> .flags = IMA_FUNC | IMA_MASK},
>> {.action = MEASURE,.func = BPRM_CHECK,.mask = MAY_EXEC,
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Linux-ima-user mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-ima-user
>
|
|
From: Mimi Z. <zo...@li...> - 2010-07-08 13:14:53
|
On Tue, 2010-07-06 at 17:08 +0200, Roberto Sassu wrote:
> This patch modifies the default policy shipped with IMA, in order to avoid measurements
> of files in the initial ramdisk. Those files can be measured early in the boot process
> by the bootloader.
> The patch applies to latest version of the mainline kernel 2.6.35-rc4.
Yes, the initramfs measurements are therefore redundant, as they're
already included in the initramfs measurement, but perhaps, as the
number of initramfs is very limited and the individual file measurements
supplies additional information, it wouldn't hurt to keep the individual
file measurements as well. These measurements could potentially help in
identifying initramfs changes.
Would appreciate other opinions before accepting this change.
thanks,
Mimi
> Signed-off-by: Roberto Sassu <rob...@po...>
> ---
> security/integrity/ima/ima_policy.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
> index aef8c0a..92d8d0e 100644
> --- a/security/integrity/ima/ima_policy.c
> +++ b/security/integrity/ima/ima_policy.c
> @@ -64,6 +64,7 @@ static struct ima_measure_rule_entry default_rules[] = {
> {.action = DONT_MEASURE,.fsmagic = TMPFS_MAGIC,.flags = IMA_FSMAGIC},
> {.action = DONT_MEASURE,.fsmagic = SECURITYFS_MAGIC,.flags = IMA_FSMAGIC},
> {.action = DONT_MEASURE,.fsmagic = SELINUX_MAGIC,.flags = IMA_FSMAGIC},
> + {.action = DONT_MEASURE,.fsmagic = RAMFS_MAGIC,.flags = IMA_FSMAGIC},
> {.action = MEASURE,.func = FILE_MMAP,.mask = MAY_EXEC,
> .flags = IMA_FUNC | IMA_MASK},
> {.action = MEASURE,.func = BPRM_CHECK,.mask = MAY_EXEC,
|
|
From: Tamleek A. <tam...@gm...> - 2010-07-08 06:25:15
|
On Wed, Jul 7, 2010 at 5:50 PM, chloé Fouquet <fou...@gm...>wrote: > Hi, > > Is there a function that verifies automatically that the measurement log is > right according to the integrity value of the PCR 10 ? (the function will > extend a pcr will all the measurements of the measurement log) > Although verification of the log is done at the challenger end, where PCR value is calculated based on the Measurement Log sent from the attested system, still one can do the same process locally (which does not seem to be of any use). As far as I understand, based ONLY on the PCR 10 value one cannot verify the integrity state of the system if we do not include SML in consideration because even with same stack and applications' set different load sequences will result in different PCR 10 values. > What prevents me to create a measurement log of my choice and to extend a > PCR, whose value is initially 0, with these measures and perform a quote of > this PCR and then send this quote and the measurement log to a person who > want to authenticate me ? Like that I will be able to create any measurement > log even if it doesn't correspond to my computer configuration... > There is a chain of trust right from the HW --> CRTM --> BIOS --> BootLoader --> OS (kernel) and then all the executables etc. loaded upon this stack. That is been added to PCR 10 as boot aggregate in addition to the PCR 0 to 9 which has all the measurements during boot time. So any misconfiguration/manipulation done will be detected as the PCR_QUOTE has all the chain enclosed in it. > > Thanks > > Chloe > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Linux-ima-user mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-user > > -- Tamleek Ali, |
|
From: Shaz <sha...@gm...> - 2010-07-07 13:26:02
|
On Wed, Jul 7, 2010 at 5:50 PM, chloé Fouquet <fou...@gm...>wrote: > Hi, > > Is there a function that verifies automatically that the measurement log is > right according to the integrity value of the PCR 10 ? (the function will > extend a pcr will all the measurements of the measurement log) > > The ima testsuite in LTP demonstrates the verification process. > What prevents me to create a measurement log of my choice and to extend a > PCR, whose value is initially 0, with these measures and perform a quote of > this PCR and then send this quote and the measurement log to a person who > want to authenticate me ? Like that I will be able to create any measurement > log even if it doesn't correspond to my computer configuration... > If the PCR is extended by a trusted subject and in a trusted environment then it has to be trusted! You will not be able to create such a log and extend it to some PCR for authentication purposes in the first place if the platform is trusted. > > Thanks > > Chloe > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Linux-ima-user mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-user > > -- Shaz |
|
From: chloé F. <fou...@gm...> - 2010-07-07 12:51:00
|
Hi, Is there a function that verifies automatically that the measurement log is right according to the integrity value of the PCR 10 ? (the function will extend a pcr will all the measurements of the measurement log) What prevents me to create a measurement log of my choice and to extend a PCR, whose value is initially 0, with these measures and perform a quote of this PCR and then send this quote and the measurement log to a person who want to authenticate me ? Like that I will be able to create any measurement log even if it doesn't correspond to my computer configuration... Thanks Chloe |
32 messages has been excluded from this view by a project administrator.
