Bug: Persisting O_TMPFILE with IMA

Bug: Persisting O_TMPFILE with IMA

[Ignaz Forster]

Hello,

persisting files opened with O_TMPFILE doesn't seem to work on IMA as 
expected: The IMA xattr won't be written. This makes it impossible to 
access the file later.
The following example application, based on the O_TMPFILE example from
	man 2 open
will demonstrate this:


#include <fcntl.h>
#include <unistd.h>
#include <linux/limits.h>
#include <stdio.h>

int main(int argc, char *argv[]) {
	char path[PATH_MAX];
	int fd = open("/tmp", __O_TMPFILE | O_RDWR, S_IRUSR | S_IWUSR);
	write(fd, "test", 4);
	snprintf(path, PATH_MAX, "/proc/self/fd/%d", fd);
	linkat(AT_FDCWD, path, AT_FDCWD, "/tmp/tmpfile_persisted.txt",
			AT_SYMLINK_FOLLOW);
}


(/tmp should not be a tmpfs of course; change to paths to a supported 
file system if necessary.)

This was discovered when trying to understand why IMA is failing on 
overlayfs during truncated copy_up operations (see thread "PROBLEM: IMA 
xattrs not written on overlayfs" from September / October), though this 
is probably a different problem.

Ignaz

Re: Bug: Persisting O_TMPFILE with IMA

[Mimi Zohar]

On Fri, 2018-12-14 at 19:11 +0100, Ignaz Forster wrote:
> Hello,
> 
> persisting files opened with O_TMPFILE doesn't seem to work on IMA as 
> expected: The IMA xattr won't be written. This makes it impossible to 
> access the file later.
> The following example application, based on the O_TMPFILE example from
> 	man 2 open
> will demonstrate this:
> 
> 
> #include <fcntl.h>
> #include <unistd.h>
> #include <linux/limits.h>
> #include <stdio.h>
> 
> int main(int argc, char *argv[]) {
> 	char path[PATH_MAX];
> 	int fd = open("/tmp", __O_TMPFILE | O_RDWR, S_IRUSR | S_IWUSR);
> 	write(fd, "test", 4);
> 	snprintf(path, PATH_MAX, "/proc/self/fd/%d", fd);
> 	linkat(AT_FDCWD, path, AT_FDCWD, "/tmp/tmpfile_persisted.txt",
> 			AT_SYMLINK_FOLLOW);
> }
> 
> 
> (/tmp should not be a tmpfs of course; change to paths to a supported 
> file system if necessary.)
> 
> This was discovered when trying to understand why IMA is failing on 
> overlayfs during truncated copy_up operations (see thread "PROBLEM: IMA 
> xattrs not written on overlayfs" from September / October), though this 
> is probably a different problem.

rootfs is a tmpfs filesystem.  Once CPIO supports xattrs, they can be
included in the initramfs.

Remember the builtin policies - ima_policy=tcb|appraise_tcb - are
there from boot.  They are meant to be replaced with finer grained
policies based on LSM labels, once the LSMs are up and running.

Feel free to replace the builtin IMA policy with one to your liking.

Mimi

Re: Bug: Persisting O_TMPFILE with IMA

[Ignaz Forster]

[-- Attachment #1.1: Type: text/plain, Size: 2175 bytes --]

Mimi Zohar schrieb am 14.12.2018 um 20:01 Uhr:
> On Fri, 2018-12-14 at 19:11 +0100, Ignaz Forster wrote:
>> Hello,
>>
>> persisting files opened with O_TMPFILE doesn't seem to work on IMA as 
>> expected: The IMA xattr won't be written. This makes it impossible to 
>> access the file later.
>> The following example application, based on the O_TMPFILE example from
>> 	man 2 open
>> will demonstrate this:
>>
>>
>> #include <fcntl.h>
>> #include <unistd.h>
>> #include <linux/limits.h>
>> #include <stdio.h>
>>
>> int main(int argc, char *argv[]) {
>> 	char path[PATH_MAX];
>> 	int fd = open("/tmp", __O_TMPFILE | O_RDWR, S_IRUSR | S_IWUSR);
>> 	write(fd, "test", 4);
>> 	snprintf(path, PATH_MAX, "/proc/self/fd/%d", fd);
>> 	linkat(AT_FDCWD, path, AT_FDCWD, "/tmp/tmpfile_persisted.txt",
>> 			AT_SYMLINK_FOLLOW);
>> }
>>
>>
>> (/tmp should not be a tmpfs of course; change to paths to a supported 
>> file system if necessary.)
>>
>> This was discovered when trying to understand why IMA is failing on 
>> overlayfs during truncated copy_up operations (see thread "PROBLEM: IMA 
>> xattrs not written on overlayfs" from September / October), though this 
>> is probably a different problem.
> 
> rootfs is a tmpfs filesystem.  Once CPIO supports xattrs, they can be
> included in the initramfs.
> 
> Remember the builtin policies - ima_policy=tcb|appraise_tcb - are
> there from boot.  They are meant to be replaced with finer grained
> policies based on LSM labels, once the LSMs are up and running.
> 
> Feel free to replace the builtin IMA policy with one to your liking.

I'm not talking about the initrd or the early boot process here - the 
application will fail when compiling and executing it in a fully started 
system. It will just open a temporary file without a name, write something 
into it and save it to "/tmp/tmpfile_persisted.txt", following the example 
for using O_TMPFILE in the open(2) manpage. No IMA hash will be generated 
for the file, making the file inaccessible and thus breaking applications 
relying on this feature of O_TMPFILE (though I assume that's not widely 
used yet).

Ignaz


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Bug: Persisting O_TMPFILE with IMA

[Mimi Zohar]

On Sat, 2018-12-15 at 12:07 +0100, Ignaz Forster wrote:
> Mimi Zohar schrieb am 14.12.2018 um 20:01 Uhr:
> > On Fri, 2018-12-14 at 19:11 +0100, Ignaz Forster wrote:
> >> Hello,
> >>
> >> persisting files opened with O_TMPFILE doesn't seem to work on IMA as 
> >> expected: The IMA xattr won't be written. This makes it impossible to 
> >> access the file later.
> >> The following example application, based on the O_TMPFILE example from
> >> 	man 2 open
> >> will demonstrate this:
> >>
> >>
> >> #include <fcntl.h>
> >> #include <unistd.h>
> >> #include <linux/limits.h>
> >> #include <stdio.h>
> >>
> >> int main(int argc, char *argv[]) {
> >> 	char path[PATH_MAX];
> >> 	int fd = open("/tmp", __O_TMPFILE | O_RDWR, S_IRUSR | S_IWUSR);
> >> 	write(fd, "test", 4);
> >> 	snprintf(path, PATH_MAX, "/proc/self/fd/%d", fd);
> >> 	linkat(AT_FDCWD, path, AT_FDCWD, "/tmp/tmpfile_persisted.txt",
> >> 			AT_SYMLINK_FOLLOW);
> >> }
> >>
> >>
> >> (/tmp should not be a tmpfs of course; change to paths to a supported 
> >> file system if necessary.)

[ snip ]

There is indeed a missing call to ima_file_check() in do_tmpfile(),
but it requires FMODE_CREATED to be set.  Al, is there a reason that
FMODE_CREATED is not set?

Mimi